|
Производительность и количество FK в таблице
|
|||
---|---|---|---|
#18+
Возможно, надо было спросить в "Проектировании БД", но здесь больше шансов на ответ компетентных людей :) Есть несколько таблиц-справочников Код: sql 1. 2. 3.
и др. и одна общая (аггрегирующая сведения) с данными визитов пациентов в определенные ЛПУ к определенным врачам по определенным причинам и т.д. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9.
Планирую добавить в нее еще пару десятков внешних ключей на подобные таблицы. Чтобы получить минимально полезные сведения приходится городить такую конструкцию Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
Причем, справочники могут быть с блобами. 1. Насколько оправдан такой подход? 2. Есть ли какие-нибудь подводные камни, про которые надо знать? 3. Если мой подход неоптимален, то какую конструкцию можно использовать взамен? ================= Док. Win10 Ultim x64/Deb 10 amd64/Darwin Cocoa(Monterey): FB 3.0.7.33374, Lazarus 2.3.0(trunk); FPC 3.3.1(trunk) ... |
|||
:
Нравится:
Не нравится:
|
|||
09.02.2022, 18:57 |
|
Производительность и количество FK в таблице
|
|||
---|---|---|---|
#18+
Док, выскажу чисто своё мнение. 1. Вовсе не обязательно поля-ссылки на другие таблицы оформлять как FK. Для начала можно оформить как простое поле, например REASON_VISIT_ID. Далее, если выяснится, что по нему требуется поиск, то можно добавить индекс. FK - это сущность опциональная. Если назвать поле REASON_VISIT_ID, то глядя на его название сразу понятно, куда оно ссылается и лишних FK-индексов городить не требуется. В MySQL лет десять не было никаких FK и все прекрасно жили. 2. Вместо того, чтобы городить ненужные FK-индексы в таблице транзакций, гораздо больше пользы реализовать составные индексы, например (ПАЦИЕНТ_ID, DATEVISIT), (ВРАЧ_ID, DATEVISIT), чтобы получить максимально высокую скорость формирования отчётов. 2. Запрос к куче таблиц через INNER JOIN - это лохотрон. Куда надёжнее строить запрос самостоятельно, начиная с таблицы с транзакциями и подключая через LEFT JOIN таблицы-справочники. Это всегда работает максимально быстро (в отличии от INNER JOIN). ... |
|||
:
Нравится:
Не нравится:
|
|||
09.02.2022, 22:42 |
|
Производительность и количество FK в таблице
|
|||
---|---|---|---|
#18+
DmSerнапример (ПАЦИЕНТ_ID, DATEVISIT), (ВРАЧ_ID, DATEVISIT), чтобы получить максимально высокую скорость формирования отчётов. лабуда. такие индексы помогут только для отчетов по конкретному пациенту и конкретному врачу. Потому что составные индексы нормально используются только при поиске на равенство по первым сегментам. Как только первый сегмент сравнивается НЕ на равенство, остальные сегменты идут лесом, поиск по ним невозможен, и такой индекс только затормозит работу из-за своей большей толщины, чем одиночный индекс по конкретному столбцу. DmSerначиная с таблицы с транзакциями и подключая через LEFT JOIN таблицы-справочники. Это всегда работает максимально быстро (в отличии от INNER JOIN). опять ерунда какая-то. При inner join оптимизатор сам хорошо выстраивает таблицы и индексы для выборки. При left join он ничего не может, объединяя таблицы по парам в жестко заданном порядке. Кроме того, использовать left join там где нужен inner - это маразм. Раньше таким страдали всякие ERP для "прибивания плана", независимо от содержимого таблиц. Но те, кто это писал, не думали, что в универсальной ERP распределение данных в таблицах может быть сильно разным. И если в одной конторе план получается нормальным, то в другой конторе для других данных на том же запросе с left join получается задница и тормоза. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.02.2022, 23:02 |
|
Производительность и количество FK в таблице
|
|||
---|---|---|---|
#18+
kdvлабуда. такие индексы помогут только для отчетов по конкретному пациенту и конкретному врачу. Потому что составные индексы нормально используются только при поиске на равенство по первым сегментам. Как только первый сегмент сравнивается НЕ на равенство, остальные сегменты идут лесом, поиск по ним невозможен, и такой индекс только затормозит работу из-за своей большей толщины, чем одиночный индекс по конкретному столбцу. Вероятно, что это и требуется - найти по конкретному врачу (или группе врачей) либо по конкретному пациенту (или группе пациентов). kdvопять ерунда какая-то. При inner join оптимизатор сам хорошо выстраивает таблицы и индексы для выборки. При left join он ничего не может, объединяя таблицы по парам в жестко заданном порядке. Кроме того, использовать left join там где нужен inner - это маразм. Намучался я в своё время с этими inner join. Постоянно у пользователей были проблемы с производительностью (в первую очередь из-за неактуальной статистики). В конце концов переделал все запросы на left join. Не помню ни одного случая, где бы left join (вместо inner join) не подошёл. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.02.2022, 23:28 |
|
Производительность и количество FK в таблице
|
|||
---|---|---|---|
#18+
kdv DmSerначиная с таблицы с транзакциями и подключая через LEFT JOIN таблицы-справочники. Это всегда работает максимально быстро (в отличии от INNER JOIN). опять ерунда какая-то. При inner join оптимизатор сам хорошо выстраивает таблицы и индексы для выборки. При left join он ничего не может, объединяя таблицы по парам в жестко заданном порядке. Кроме того, использовать left join там где нужен inner - это маразм. Ну, во первых, именно тут именно inner - НЕ НУЖЕН. Тут как раз outer по смыслу подходит. А во вторых, раз уж у нас такая ситуация когда мы пошли по ссылке, на которой не навешан FK, то и ссылка может привести к тыкву. И при inner у нас тогда и мастер-запись пропадет. kdv Раньше таким страдали всякие ERP для "прибивания плана", независимо от содержимого таблиц. Но те, кто это писал, не думали, что в универсальной ERP распределение данных в таблицах может быть сильно разным. И если в одной конторе план получается нормальным, то в другой конторе для других данных на том же запросе с left join получается задница и тормоза. Несколько раз напоровшись на ситуацию когда сервер при росте базы пытается "сделать мне лучше" и меняет план на совсем херовый я этих inner боюсь как огня. И всегда когда к данным цепляю справочники, делаю это по outer. Бывают конечно исключения, но они - исключения. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2022, 06:27 |
|
Производительность и количество FK в таблице
|
|||
---|---|---|---|
#18+
И я всегда объявляю в базе FK, это неоднократно спасало от кривых данных или удаления записей с зависимостями. Да, это не совсем бесплатно, но в половине случаев индекс нужен, а в остальных случаях - не так оно и мешает. Зато самодокументированность и корректность данных. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2022, 06:29 |
|
Производительность и количество FK в таблице
|
|||
---|---|---|---|
#18+
В моей микровселенной: У справочников всегда есть первичный ключ с именем ID. Поля-ссылки начинаются с ID_ и далее идет имя таблицы или некоторые другие исторически сложившиеся называния. Код: plsql 1. 2. 3.
... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2022, 06:32 |
|
Производительность и количество FK в таблице
|
|||
---|---|---|---|
#18+
Док Возможно, надо было спросить в "Проектировании БД", но здесь больше шансов на ответ компетентных людей :) Планирую добавить в нее еще пару десятков внешних ключей на подобные таблицы. Чтобы получить минимально полезные сведения приходится городить такую конструкцию ... 1. Насколько оправдан такой подход? 2. Есть ли какие-нибудь подводные камни, про которые надо знать? 3. Если мой подход неоптимален, то какую конструкцию можно использовать взамен? ================= Док. Win10 Ultim x64/Deb 10 amd64/Darwin Cocoa(Monterey): FB 3.0.7.33374, Lazarus 2.3.0(trunk); FPC 3.3.1(trunk) всегда так делаю. иногда еще в таблицу-связку пишу денормализованные данные, т.к. справочники могут поменяться из камней - иногда приходится добавлять нолики, т.к. план может внезапно измениться INNER JOIN TBL_PEOPLE PM ON (JP.FK_PEOPLE = PM.ID+0) ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2022, 09:43 |
|
Производительность и количество FK в таблице
|
|||
---|---|---|---|
#18+
Спасибо за мнения. Т.е. пока резюме такое: * Поменять inner на outer * Добавление FK вместо составных ключей оправдано и оптимальнее всего Все правильно? Планируется этим запросом выборка данных для конкретного пациента, остальное (кто доктор, цель визита и проч) - меняющиеся детали. По ID визита планируется редактирование записи и отправка ее в отчёт ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2022, 10:05 |
|
Производительность и количество FK в таблице
|
|||
---|---|---|---|
#18+
ДокПоменять inner на outer я бы не стал этого делать без острой необходимости. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2022, 10:16 |
|
Производительность и количество FK в таблице
|
|||
---|---|---|---|
#18+
Док,Добавление FK вместо составных ключей оправдано и оптимальнее всего Не всегда. Я бы, например, очень подумал - добавлять или нет FK на маленький справочник, который не планируется расширять. Например, статус заявки: 1-Активная, 2-Отложена, 3-Удалена. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2022, 11:07 |
|
Производительность и количество FK в таблице
|
|||
---|---|---|---|
#18+
Док Есть несколько таблиц-справочников Код: sql 1. 2.
Док Код: sql 1.
Док и одна общая (аггрегирующая сведения) с данными визитов пациентов в определенные ЛПУ к определенным врачам по определенным причинам и т.д. Надо объяснять для чего она вообще нужна, и если нужна, то может несколько? Для хранимых агрегатов нет универсальных правил, увы. В топик призывается Дед. Док Код: sql 1. 2. 3. 4.
2. Планирую добавить в нее еще пару десятков внешних ключей на подобные таблицы. 3. Чтобы получить минимально полезные сведения приходится городить такую конструкцию 4. Причем, справочники могут быть с блобами. 1. ID_ лучше, чем FK_. Хотя это дело вкуса, конечно (если проект на одного - то пофиг). 2. Таблица c десятками внешних ключей должна автоматически вызывать подозрение. Есть исключения - например, таблица, которая напарсила (или ещё откуда-то извлекла) всякое безобразие, которое "плоское" и плохо раскладывается в несколько таблиц (разве что в ширину). 3. Нормальная конструкция. Если, конечно, на каждый чих делать не все 30 джойнов, а только нужные. 4. Выкинь все INNER. Это, конечно, дело вкуса, но таки лучше просто JOIN. Док 1. Насколько оправдан такой подход? 2. Есть ли какие-нибудь подводные камни, про которые надо знать? 3. Если мой подход неоптимален, то какую конструкцию можно использовать взамен? 2. Совпадающие поля в таблицах. Хотя ФБ вроде на них ругается с какой-то версии. Мелочь, а неприятно. Впрочем, если соблюдать гигиену вегда использовать префиксы, то жить можно. 3. См. п.1. :) Для начала я бы не агрегировал всё подряд и добавил только те FK, которые реально нужны. Авось и не понадобятся 30 ссылок. Во-вторых, сложность и громоздкость резко увеличатся, если/когда у тебя вместо одной такой таблицы появится две - например, TBL_AGG и TBL_AGG_DETAILS (потому что даты или несколько записей или просто потому что). ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2022, 11:09 |
|
Производительность и количество FK в таблице
|
|||
---|---|---|---|
#18+
Док * Добавление FK вместо составных ключей оправдано и оптимальнее всего Док Планируется этим запросом выборка данных для конкретного пациента, остальное (кто доктор, цель визита и проч) - меняющиеся детали. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2022, 11:15 |
|
Производительность и количество FK в таблице
|
|||
---|---|---|---|
#18+
pastor иногда еще в таблицу-связку пишу денормализованные данные, т.к. справочники могут поменяться ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2022, 11:16 |
|
Производительность и количество FK в таблице
|
|||
---|---|---|---|
#18+
Гаджимурадов Рустам pastor иногда еще в таблицу-связку пишу денормализованные данные, т.к. справочники могут поменяться Была в прайсе корова рыжая одна. Например, "Каток" а потом стало "Физкультурно-оздоровительное катание для иных категорий граждан" В статистике - одно и то же, а в ОФД уже ушло как ушло. С диагнозами наверняка также. Или хуже. Был кровавый понос, а стало 10 разных категорий по МКБ. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2022, 11:24 |
|
Производительность и количество FK в таблице
|
|||
---|---|---|---|
#18+
pastor> В статистике - одно и то же, а в ОФД уже ушло как ушло. Всё равно не понял. Если справочник периодический, то проблемы нет. Если не периодический, то непонятно как твой подход помогает её решить. Ты же не все поля в таблицу копируешь? > С диагнозами наверняка также. Или хуже. > Был кровавый понос, а стало 10 разных категорий по МКБ. ХЗ, я бы делал новую запись, опционально - со ссылкой на старую, хоть 10 в цепочку. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2022, 11:53 |
|
Производительность и количество FK в таблице
|
|||
---|---|---|---|
#18+
Гаджимурадов Рустам pastor> В статистике - одно и то же, а в ОФД уже ушло как ушло. Всё равно не понял. Если справочник периодический, то проблемы нет. Если не периодический, то непонятно как твой подход помогает её решить. Ты же не все поля в таблицу копируешь? > С диагнозами наверняка также. Или хуже. > Был кровавый понос, а стало 10 разных категорий по МКБ. ХЗ, я бы делал новую запись, опционально - со ссылкой на старую, хоть 10 в цепочку. может быть полное описание расчета проката или парковки например. или стринлист параметров на момент оформления. да что угодно. пробовали делать истории, получение актуальной на момент времени и пр. - гемор. компромисс между простотой пользования и возможностями разбора. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2022, 12:16 |
|
Производительность и количество FK в таблице
|
|||
---|---|---|---|
#18+
pastor Был кровавый понос, а стало 10 разных категорий по МКБ. Хранение строковых данных в основной таблице раздует её слишком, тормозить будет. Замените редактирование справочника созданием дубликата со скрытием старого. У новых записей основной таблицы будет новый вариант, у старых останется старый. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2022, 12:41 |
|
Производительность и количество FK в таблице
|
|||
---|---|---|---|
#18+
ggreggory pastor Был кровавый понос, а стало 10 разных категорий по МКБ. Хранение строковых данных в основной таблице раздует её слишком, тормозить будет. Замените редактирование справочника созданием дубликата со скрытием старого. У новых записей основной таблицы будет новый вариант, у старых останется старый. а мне не жалко. я даже логи запросов /ответов http храню. шоп було. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2022, 13:26 |
|
Производительность и количество FK в таблице
|
|||
---|---|---|---|
#18+
pastor> может быть полное описание расчета проката или парковки например. pastor> или стринлист параметров на момент оформления. да что угодно. Ээээ и сколько (по времени и объемам) это всё безобразие хранится? > пробовали делать истории, получение актуальной на момент времени и пр. - гемор. Это да, нужно вьюхи/ХП плодить. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2022, 13:38 |
|
Производительность и количество FK в таблице
|
|||
---|---|---|---|
#18+
ДокТ.е. пока резюме такое: * Поменять inner на outer * Добавление FK вместо составных ключей оправдано и оптимальнее всего Все правильно? У тебя в запросе условие по полю из справочника. Безмозглое применение п.1 может привести пушного зверька. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2022, 13:40 |
|
Производительность и количество FK в таблице
|
|||
---|---|---|---|
#18+
Гаджимурадов Рустам pastor> может быть полное описание расчета проката или парковки например. pastor> или стринлист параметров на момент оформления. да что угодно. Ээээ и сколько (по времени и объемам) это всё безобразие хранится? > пробовали делать истории, получение актуальной на момент времени и пр. - гемор. Это да, нужно вьюхи/ХП плодить. 5 лет минимум. обычно - лет 10, до 50 гб, но там и фотки и все такое. логи http - год, логи действий пользователей, телеметрия - до ближайшего обновления БД ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2022, 13:58 |
|
Производительность и количество FK в таблице
|
|||
---|---|---|---|
#18+
Гаджимурадов Рустам Выкинь все INNER. Это, конечно, дело вкуса, но таки лучше просто JOIN. Чтобы потом новички и склеротики в гугл лазили успокоить совесть/убедиться, что это одно и то же? Такие сокращения - упыризм чистой воды. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2022, 15:07 |
|
Производительность и количество FK в таблице
|
|||
---|---|---|---|
#18+
YuRock Гаджимурадов Рустам Выкинь все INNER. Это, конечно, дело вкуса, но таки лучше просто JOIN. Такие сокращения - упыризм чистой воды. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2022, 15:23 |
|
|
Start [/forum/topic.php?fid=40&tid=1559828]: |
0ms |
get settings: |
29ms |
get forum list: |
11ms |
check forum access: |
5ms |
check topic access: |
5ms |
track hit: |
68ms |
get topic data: |
26ms |
get forum data: |
4ms |
get page messages: |
2511ms |
get tp. blocked users: |
2ms |
others: | 193ms |
total: | 2854ms |
0 / 0 |