|
Действия ...
Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
02.09.2014, 19:30
|
|||
|---|---|---|---|
|
|||
Вопрос о view! |
|||
|
#18+
Собственно, вопрос, не оч уяснил из статей. Есть огромная таблица, делаем view из нее с каким-нить условием, вьюха вышла в 100 раз меньше. Теперь делаем 2 запроса, 1ин непосредственно в таблицу с 2мя условиями(1но копирует условие по которому создавалась вьюха, и еще какой-нить) ,2ой во вьюху - только со вторым условием. Скорость выборки одинакова? или нет? непонимаю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
02.09.2014, 19:55
|
|||
|---|---|---|---|
Вопрос о view! |
|||
|
#18+
scy, Ну так померяй и увидишь. Если коротко то вьюха это лишь представление, т.е. динамический запрос а не отдельная таблица. Таким образом от перемены мест ... скорость неизменится. Надеюсь вы поняли. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
02.09.2014, 21:26
|
|||
|---|---|---|---|
Вопрос о view! |
|||
|
#18+
scy, теоретически (то есть при идеальной реализации сервера) должна быть одинакова. На практике различные "неидеальности" могут привести к тому, что в некоторых ситуациях скорость будет кардинально разной, причём как в ту, так и в другую сторону. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
03.09.2014, 10:38
|
|||
|---|---|---|---|
Вопрос о view! |
|||
|
#18+
softwarerscy, теоретически (то есть при идеальной реализации сервера) должна быть одинакова. На практике различные "неидеальности" могут привести к тому, что в некоторых ситуациях скорость будет кардинально разной, причём как в ту, так и в другую сторону.+500. Если вьюха индексированная, то возможен выигрыш. Главная польза вьюхи - многократное использование ее конструкции, упрощающие код. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
03.09.2014, 13:30
|
|||
|---|---|---|---|
|
|||
Вопрос о view! |
|||
|
#18+
scyСобственно, вопрос, не оч уяснил из статей. Есть огромная таблица, делаем view из нее с каким-нить условием, вьюха вышла в 100 раз меньше. Теперь делаем 2 запроса, 1ин непосредственно в таблицу с 2мя условиями(1но копирует условие по которому создавалась вьюха, и еще какой-нить) ,2ой во вьюху - только со вторым условием. Скорость выборки одинакова? или нет? непонимаю. посмотри планы выполнения. Там ответ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
03.09.2014, 13:54
|
|||
|---|---|---|---|
|
|||
Вопрос о view! |
|||
|
#18+
Всем спасибо за ответы. Но некая неясность все таки осталась. а) Если вьюха индексированная, то возможен выигрыш. -> тоесть мы можем проиндексировать лишь необходимый нам кусок родительской таблицы? Оо - чет мне кажеться вы меня путаете(хотя было бы сладко) б) вьюха = динамический запрос -> все обращение к ней - эквивалентны логическому & - между условиями? - и тогда как писал "LSV " - выигрыш только в упрощении кода? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
03.09.2014, 14:01
|
|||
|---|---|---|---|
|
|||
Вопрос о view! |
|||
|
#18+
scyа) Если вьюха индексированная, то возможен выигрыш. -> тоесть мы можем проиндексировать лишь необходимый нам кусок родительской таблицы? Оо - чет мне кажеться вы меня путаете(хотя было бы сладко) То что после "->" - никак не связано с тем что до. Создать indexed view - не значит "проиндексировать кусок родительстой таблицы", это отдельный обьект scyб) вьюха = динамический запрос -> все обращение к ней - эквивалентны логическому & - между условиями? - и тогда как писал "LSV " - выигрыш только в упрощении кода? Потенциальных "выигрышей" много - инкапсуляция, права доступа, etc. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
03.09.2014, 14:51
|
|||
|---|---|---|---|
Вопрос о view! |
|||
|
#18+
On 03.09.2014 11:38, LSV wrote: > +500. Если вьюха индексированная, то возможен выигрыш. > Главная польза вьюхи - многократное использование ее конструкции, > упрощающие код. Выигрыша от обычного VIEW быть не может, в лучшем случае -- та же производительность, что и при подстановке текста VIEW в запрос. Выигрыш от VIEW возможен только, если это -- т.н. материализованный VIEW (некоторые СУБД поддерживают). Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
03.09.2014, 14:55
|
|||
|---|---|---|---|
Вопрос о view! |
|||
|
#18+
On 03.09.2014 14:54, scy wrote: > а) Если вьюха индексированная, то возможен выигрыш. Невозможен. -> тоесть мы можем > проиндексировать лишь необходимый нам кусок родительской таблицы? Оо - Нет, это невозможно. > б) вьюха = динамический запрос -> все обращение к ней - эквивалентны > логическому & - между условиями? - и тогда как писал "LSV " - выигрыш > только в упрощении кода? Э... да, и в возможности его повторно использовать. Но ввиду того, что VIEW достаточно часто вводят использующих его программистов и/или оптимизатор СУБД в глубокий ступор, реально VIEW в серьёзных СУБД практически не используют. Заметь, я не отговариваю тебя использовать VIEW, в каких-то конкретных случаях его использование может быть вполне себе оправдано и будет работать как надо. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
03.09.2014, 15:04
|
|||
|---|---|---|---|
Вопрос о view! |
|||
|
#18+
MasterZivВыигрыш от VIEW возможен только, если это -- т.н. материализованный VIEW (некоторые СУБД поддерживают).MasterZiv> а) Если вьюха индексированная, то возможен выигрыш. Невозможен.А если индексированная материализованная VIEW, то что будет? :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
03.09.2014, 15:16
|
|||
|---|---|---|---|
Вопрос о view! |
|||
|
#18+
scyВсем спасибо за ответы. Но некая неясность все таки осталась. а) Если вьюха индексированная, то возможен выигрыш. -> тоесть мы можем проиндексировать лишь необходимый нам кусок родительской таблицы? Оо - чет мне кажеться вы меня путаете(хотя было бы сладко) б) вьюха = динамический запрос -> все обращение к ней - эквивалентны логическому & - между условиями? - и тогда как писал "LSV " - выигрыш только в упрощении кода? По первому пункту - отделите мух от котлет и сформулируйте вопрос боле понятно. По индекс вьюхе - да, будет быстрее. Но это умеют только некоторые СУБД. В реально больших БД практически невстречал. Насчет индекса кусков - бред какой-то, даже нехочу комментировать ... По второму - да, по сути все сводится к этому. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
03.09.2014, 15:20
|
|||
|---|---|---|---|
Вопрос о view! |
|||
|
#18+
Злой БобрНасчет индекса кусков - бред какой-то, даже нехочу комментировать ...Не такой уж и бред, если не привязывать его к VIEW. Мне в Oracle XE приходилось создать индекс по части таблицы с той целью, чтобы работать с "горячей" частью большой таблицы в условиях ограниченной памяти. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
03.09.2014, 15:28
|
|||
|---|---|---|---|
|
|||
Вопрос о view! |
|||
|
#18+
miksoftМне в Oracle XE приходилось создать индекс по части таблицы с той целью, чтобы работать с "горячей" частью большой таблицы в условиях ограниченной памяти.Эдакое ручное партиционирование? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
03.09.2014, 15:32
|
|||
|---|---|---|---|
Вопрос о view! |
|||
|
#18+
Infernal V. RavenmiksoftМне в Oracle XE приходилось создать индекс по части таблицы с той целью, чтобы работать с "горячей" частью большой таблицы в условиях ограниченной памяти.Эдакое ручное партиционирование?Ну да, типа того. Правда, партиций было всего две и быстрый доступ был только у одной из них. Технически, это можно повторить несколько раз для разных условий, но "в условиях ограниченной памяти" это вряд ли будет эффективно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
03.09.2014, 15:37
|
|||
|---|---|---|---|
|
|||
Вопрос о view! |
|||
|
#18+
miksoftПравда, партиций было всего две и быстрый доступ был только у одной из них.А как было реализовано? Предполагаю, что использовалось что-то типа флага 1 - актуальные данные, 0 - неактуальные, или дата. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
03.09.2014, 15:41
|
|||
|---|---|---|---|
Вопрос о view! |
|||
|
#18+
Infernal V. RavenmiksoftПравда, партиций было всего две и быстрый доступ был только у одной из них.А как было реализовано? Предполагаю, что использовалось что-то типа флага 1 - актуальные данные, 0 - неактуальные, или дата.Конкретно у нас была комбинация полей. Был построен FBI-индекс по выражению, которое для "горячих" записей давало значение нужного поля, а для "холодных" записей давало NULL. Конечно же, это потребовало переписать все запросы, где использовалось это условие. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
start [/forum/topic.php?fid=32&tablet=1&tid=1540810]: |
0ms |
get settings: |
10ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
165ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
55ms |
get tp. blocked users: |
2ms |
| others: | 15ms |
| total: | 285ms |
| 0 / 0 |
Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...
