|
Производительность и количество FK в таблице
|
|||
---|---|---|---|
#18+
Гаджимурадов Рустам, все ПК ведут на расширяемые в процессе внесения данных справочники. Если в поле ограниченное количество значений, я просто перечисляю их возможные значения в комменте к полю, куда смотрю, когда на клиенте список выбора формирую Касаемо названий ID...FK - дело привычки. Касаемо количества ФК... Как я понял, если не тащить их всех в запрос, то некритично. Собссно, табличка просто "собирает" в одну кучу ссылки на разнородные сведения. Dimitry Sibiryakov, Дим, ты же знаешь - я тупой гуманитарий. И полунамеков не понимаю. Расшифруй, плз ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2022, 15:54 |
|
Производительность и количество FK в таблице
|
|||
---|---|---|---|
#18+
Док Касаемо количества ФК... Как я понял, если не тащить их всех в запрос, то некритично. Собссно, табличка просто "собирает" в одну кучу ссылки на разнородные сведения. не надо пытаться "оптимизировать" сильно ЗАРАНЕЕ. FK - средство для гарантированного обеспечения целостности данных. зачем же от него отказываться? когда-то, когда деревья были большими, а оптимизатор IB/FB был достаточно тупой, он при виде пары PK-FK впадал в экстаз и тут же пихал соответствующие индексы в PLAN. и пофигу ему было, что план таким образом не всегда получался эффективным. но много воды утекло с тех пор... оптимизатор уже не тот. нет в нём юношеского огня и задора... ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2022, 16:07 |
|
Производительность и количество FK в таблице
|
|||
---|---|---|---|
#18+
ДокДим, ты же знаешь - я тупой гуманитарий. И полунамеков не понимаю. Расшифруй, плз Так уточни какое именно слово тебе непонятно чтобы я знал какую часть http://www.ibase.ru/dataaccesspaths/ тебе цитировать. Левым джоином ты отсечёшь возможность использования индекса для фильтрации и получишь гигантский natural scan со всеми вытекающими тормозами. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2022, 16:09 |
|
Производительность и количество FK в таблице
|
|||
---|---|---|---|
#18+
Док, слушай сюда. У любой штуки есть и про и контра. Нет абсолютного зла и абсолютного добра. И эти про и контра надо иметь в виду применительно к своей конкретной задаче и принимать осмысленное решение. Так вот, касательно FK на короткие справочники, вопрос про иннеры с аутерами поднимем чуть позже, пока считаем, что живём с иннерами. С точки зрения целостности FK - это триггер, видящий за счёт использования индекса больше, чем твой триггер, работающий в контексте уровня изоляции твоей транзакции. Поэтому он и не даст тебе сослаться на удалённую в справочнике запись или запись, ID которой был изменён, независимо от того, когда это произошло - до старта твоей транзакции или после и закоммичено оно или нет. Аналогично такой же триггер на справочнике не даст удалить позицию или изменить её ID если есть даже незакоммиченные ссылки в содержательных таблицах. Отсюда следует, что если удаления или изменения ID в справочнике не предусмотрены бизнес-логикой, то в этом и только в этом случае FK не особо и нужен, его вполне можно заменить твоими триггерами на содержательной таблице. Что при этом про. На содержательной таблице из 100500 записей нет херового индекса с 5 значениями. Вред от него двоякий. Не, даже троякий. Во-первых, по мере роста таблицы его херовость в смысле затрат на перестройку при вставках-удалениях-модифицированиях (последнее - например, изменение статуса записи, стадии существования от необслуженной совсем через инстанции рассмотрения к завершению обслуживания). Но это так, тормозишки, на твоих объёмах ты их скорей всего и не заметишь. Настоящие тормоза ты заметишь на ресторе, при построении этого индекса целиком, это во-вторых. В-третьих, если в селективном запросе на эту ссылку наложено условие, оптимизатор может этот индекс и подцепить, независимо от иннер или аутер. Просто при иннере он его может подцепить и при наложении условия на поле в справочнике и построить перебор от справочника. Вот это в-третьих имеет свои про и контра. Если распределение значений в этом поле более-менее равномерное, ты получишь серьёзные тормоза. Если же, как в случае статуса, через годик работы в таблице из 100500 записей 100000 закрытых и 500 в работе, то запрос, отбирающий эти 500 на этот индекс не нарадуется, что есть про. А вот наоборот - заплачешь горючими слезами. Контра в том, что надо об этом помнить и гасить в этом случае ноликами. За иннеры-аутеры. При современном развитии печатного дела на Западе вероятность использования оптимизатором в таких простых случаях херового индекса имхо невелика. На полуторке - да, в полный рост. Должен отметить, что в моей практике, тоиссь, на примерно миллионе сконструированных запросов, раз 5 был случай, когда оптимизатор действительно сложный запрос на иннерах выворачивал даже не через жопу, а через три, причём слоновьих, так что у меня просто глаза на лоб лезли, и при этом результат получался в разы лучше чем у меня при всём моём глубокомудрии в составлении явных планов Но обычно всё-таки наоборот. Напоминаю - речь о полуторке. При запросе-ёлке, тоиссь, соединениях со справочниками одной ведущей таблицы, в общем, похрен, что иннер, что аутер. В случае чего иннер направить легко можно ноликами. А вот если этот запрос впоследствии берётся как основа или компонент действительно сложного с аутерами в смысловой части, то наступить на грабли просто нефиг делать. За композиты. Это мощное оружие, которое может быть как созидательным, так и разрушительным. Если все его сегменты по отдельности херовые, то к нему относится всё, что относится к херовому односегментному индексу. И построение долгоиграющее, и обслуживание нагрузочное, и оптимизатор не особо склонен его подхватывать и результат использования сильно зависит от распределения значений в сегментах, плюс условия на ведущие сегменты должны быть на равенство. Короче, смысл в нём фактически может быть для одного конкретного запроса. И не дай бог его оптимизатор подхватит для другого. Поэтому их обычно усиливают высокоселективным, а то и уникальным сегментом. Если этот сегмент ведущий, то всё чики-пуки, но тогда выгода от него проценты - меньше и быстрее загружаются страницы чем при использовании раздельных индексов на те же сегменты в нужном порядке. А если его прилепляют на жопу для обмана оптимизатора, то опять упираемся в экстремальную выгоду за счёт распределения значений в первом сегменте для запросов, отбирающих антипик распределения и дикие тормоза для остальных, тоиссь memento +0, а то оптимизатор будет его тыкать куда ни пОпадя. За периодические справочники. Это когда в нём не опечатку надо исправить, что должно подействовать на результаты всех запросов. Поскольку формированием содержательных записей обычно занимается гомо боле-мене сапиенс, тоиссь, смотрит на содержимое справочника и тыкает в нужную строчку, имхо проще всего вопрос решается включением в структуру записи справочника диапазоном дат действия и инсёртом новой записи в справочник. Попадание даты документа при формировании в диапазон несложно и проконтролировать. А поскольку по сути несколько записей в справочнике на самом деле есть одна сущность, скажем, организация название меняет, вопрос статистики и прочих агрегатов решается дополнительной таблицей 1:n для группирования в запросах. Но это уже всё имхо. Так вот, Док, уложи сии измышления в личную христа матию и применяй к своим конкретным обстоятельствам, что тебе полезно в каком случае, а что вредно. Тоиссь, не лепи по канонам и чьим-то мнениям, а думай вперёд, Ма-ма, ма-ма, что мы будем делать... ыыы... Ма-ма, ма-ма, как мы будем жить... кууу... ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2022, 16:22 |
|
Производительность и количество FK в таблице
|
|||
---|---|---|---|
#18+
Старый плюшевый мишкаВо-первых, по мере роста таблицы его херовость в смысле затрат на перестройку при вставках-удалениях-модифицированиях (последнее - например, изменение статуса записи, стадии существования от необслуженной совсем через инстанции рассмотрения к завершению обслуживания). Насколько мне изменяет мой склероз, как минимум в тройке индекс не трогается вообще если в записи индексированное поле не изменялось. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2022, 16:32 |
|
Производительность и количество FK в таблице
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov Насколько мне изменяет мой склероз, как минимум в тройке индекс не трогается вообще если в записи индексированное поле не изменялось. Так тут же речь об индексированном - статус есть ссылка на справочник. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2022, 16:38 |
|
Производительность и количество FK в таблице
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov, оно вроде как отродясь так было в ФБ ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2022, 17:17 |
|
Производительность и количество FK в таблице
|
|||
---|---|---|---|
#18+
Старый плюшевый мишка, спасибо. Читал, как увлекательный роман на языке, в котором некоторые слова знакомы Вобщем, вынес для себя пока одно: оставлю, как есть, потом буду посмотреть. Про упомянутые выше DS Левым джоином ты отсечёшь возможность использования индекса для фильтрации и получишь гигантский natural scan со всеми вытекающими тормозами. траблы я уже в курсе, ибо на нынешней базе после 40000 записей появились ощутимые тормоза. Что и сподвигло меня искать другие варианты построения базы. При нынешней структуре (из стартового топика 22432072 ) птичка показывает такой план Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.
Т.е. неиндексированные чтения все равно есть. Поэтому возник еще вопрос. А если такую структуру Код: plaintext
переделать на Код: plaintext 1.
без изменения структуры T2, будет разница? ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2022, 18:25 |
|
Производительность и количество FK в таблице
|
|||
---|---|---|---|
#18+
Ну вот, Дед в топик засаммонился (за что ему спасибо), сказку на ночь спел, а про хранимые агрегаты не рассказал. Незачёт! Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2022, 18:38 |
|
Производительность и количество FK в таблице
|
|||
---|---|---|---|
#18+
Док Код: sql 1.
... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2022, 18:38 |
|
Производительность и количество FK в таблице
|
|||
---|---|---|---|
#18+
Нет предела совершенству! P.S. Может это на пустой БД... P.S.S. Хотя миллионов записей там всё равно никогда не набежит. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2022, 18:40 |
|
Производительность и количество FK в таблице
|
|||
---|---|---|---|
#18+
ДокПри нынешней структуре (из стартового топика птичка показывает такой план Или статистика индексов не пересчитана или запрос не тот или что-то сильно окривело. Первичной таблицей того запроса должна быть PV с индексом по PV.ID, ибо по нему идёт фильтрация во where. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2022, 18:45 |
|
Производительность и количество FK в таблице
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov, еще раз: закрыл-открыл IBE запрос-план-статистика Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
Код: sql 1. 2. 3.
Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
Мимопроходящий и что ты хочешь тут оптимизировать?! я просто спросил :) Вобщем, спасибо всем за мысли и участие. Примерно, как быть, я понял ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2022, 19:26 |
|
Производительность и количество FK в таблице
|
|||
---|---|---|---|
#18+
Мимопроходящий YuRock пропущено... Чтобы потом новички и склеротики в гугл лазили успокоить совесть/убедиться, что это одно и то же? Такие сокращения - упыризм чистой воды. OUTER - бесполезное слово. LEFT INNER писать нельзя. Потому - нет, не пишу, т.к. это как раз очевидно. Ivan_Pisarevsky всегда пишу кляузу "as" при указании алиаса для поля Я тоже. Кажется, где-то без этого было нельзя, точно не помню. Плюс, это явный конец выражения - объявление названия. Без AS получается абракадабра типа NAME SOMENAME ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2022, 19:40 |
|
Производительность и количество FK в таблице
|
|||
---|---|---|---|
#18+
YuRockLEFT INNER писать нельзя. В оракуле - можно. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2022, 19:48 |
|
Производительность и количество FK в таблице
|
|||
---|---|---|---|
#18+
DS> YuRock > LEFT INNER писать нельзя. > > В оракуле - можно. Серьёзно что ли? P.S. Лень проверять. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
11.02.2022, 16:07 |
|
Производительность и количество FK в таблице
|
|||
---|---|---|---|
#18+
https://dbfiddle.uk/?rdbms=oracle_21&fiddle=84b7f664df4882b05a4615bc3552567e Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
11.02.2022, 16:17 |
|
|
Start [/forum/topic.php?fid=40&tid=1559828&gotolast=1]: |
0ms |
get settings: |
0ms |
get forum list: |
8ms |
check forum access: |
0ms |
check topic access: |
0ms |
track hit: |
40ms |
get topic data: |
6ms |
get forum data: |
1ms |
get page messages: |
25ms |
update_topic_read_status (1559828): 11.02.2022 16:24:46: |
0ms |
get tp. blocked users: |
0ms |
get online users: |
14ms |
check new: |
1ms |
others: | 87ms |
total: | 182ms |
0 / 0 |