Вопрос по PK и индексам в общем

Запросы, планы, оптимизация запросов, ...

Модераторы: kdv, CyberMax

Ответить
Kotъ-Begemotъ
Сообщения: 250
Зарегистрирован: 25 июл 2007, 21:33

Вопрос по PK и индексам в общем

Сообщение Kotъ-Begemotъ » 06 сен 2007, 00:11

Снова извиняюсь за множество вопросов, но надо ж "расти над собой" :)

1. Вопрос по Primary Key. У меня в проекте используется куча небольших "вспомогательных" таблиц. Например при каком-то действии с таблицей, ну пусть будет Customers в специальную таблицу CustEvent записывается всего два поля - CustomerID (Integer) и EvenTime (TimeStamp) чтобы потом отследить Event'ы данного Customer'а, если таковые имели место. Так вот, в подобных таблицах я обхожусь вообще без Primary Key. Правильно ли это? Даст ли введение уникального столбца CustEventID Integer Primary Key мне что-то? Второй вопрос по индексам. Нужно ли создавать индекс по CustomerID если в дальнейшем я буду делать выборку из какой-то большой таблицы и этой CustEvent по CustomerID? При том, что CustEvent заведомо небольшая (максимум сотни записей) или в этом случае индекс зря будет жрать свой хлеб (то есть дисковое пространство и память)?

2. Далее про индексы. Если есть таблицы Customer и Orders, причём в обеих есть CustomerID и периодически запрашивается список всех покупок данного клиента, насколько я понимаю, необходимо для этих таблиц создать индексы по CustomerID и в этом случае работать должно всё гораздо быстрее (особенно если таблицы достаточно большие) по сравнению со скоростью выполнения без индексов?

И вообще может посоветуете хорошую подробную статью(и) по данным вопросам? Чем подробнее тем лучше... Заранее спасибо.

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Сообщение kdv » 06 сен 2007, 00:22

хреновые вопросы, особенно на ночь. начну со второго.
Если таблицы Customers и Orders связаны по CustomerID, то Orders.CustomerID - это стольбец связи. Т.е. по нему должен быть создан FK указывающий на Customers.CustomerID. А если не создан, значит профукал в проектировании, и логическая целостность может быть элементарно нарушена. Т.е. модель такой БД можно считать дефектной.

Так вот. Раз FK создан, значит и индекс будет создан.

теперь к первому вопросу. Да. Если FK с большущей таблицы ссылается на очень маленький справочник, то такой индекс (по FK) содержит много дубликатов. И поиск по нему будет ... эээ... в большинстве случаев неэффективным.
Такие индексы можно увидеть как "плохие" в IBAnalyst. Там же, в справке по IBAnalyst, в разделе "Дополнительные вопросы и ответы" можно прочитать, как бороться с таким FK если справочная таблица почти не модифицируется.

Kotъ-Begemotъ
Сообщения: 250
Зарегистрирован: 25 июл 2007, 21:33

Сообщение Kotъ-Begemotъ » 06 сен 2007, 00:33

kdv писал(а):хреновые вопросы, особенно на ночь. начну со второго.
Если таблицы Customers и Orders связаны по CustomerID, то Orders.CustomerID - это стольбец связи. Т.е. по нему должен быть создан FK указывающий на Customers.CustomerID. А если не создан, значит профукал в проектировании, и логическая целостность может быть элементарно нарушена. Т.е. модель такой БД можно считать дефектной.
Так вот. Раз FK создан, значит и индекс будет создан.
Хм... То есть ты про Referential Integrity ? Сложный вопрос... Тебе не верить глупо, я не специалист, но при том, что Paradox поддерживает RI (пусть и худо-бедно) я просто никогда не использую эти механизмы... Просто решаю это всё софтверно - при удалении из справочника операция будет запрещена, если есть хотя бы одна ссылка в "рабочих таблицах" например... Знаит в РСУБД всё ж таки эти механизмы лучше задействовать, чем обрабатывать возможные ошибки "вручную" в коде клиента?
kdv писал(а):теперь к первому вопросу. Да. Если FK с большущей таблицы ссылается на очень маленький справочник, то такой индекс (по FK) содержит много дубликатов. И поиск по нему будет ... эээ... в большинстве случаев неэффективным.
Такие индексы можно увидеть как "плохие" в IBAnalyst. Там же, в справке по IBAnalyst, в разделе "Дополнительные вопросы и ответы" можно прочитать, как бороться с таким FK если справочная таблица почти не модифицируется.
В связи с этим еще вопрос. Какие на твой взгдяд программы совершенно необходимы для нормальной полноценной работы с тем же FB? Ну кроме самого FB и приложения в котором я делаю клиентскую часть, конечно? :) Я честно говоря думал что IBExperet'а будет вполне достаточно, тем более для России он бесплатен...

ЗЫ. За вопросы на ночь прошу прощения, просто я - существо ночное. В данный момент фрилансерничаю можно сказать, поэтому ночью как раз самое рабочее время - ни мне никто не мешает, ни я никому...

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Сообщение kdv » 06 сен 2007, 01:24

я просто никогда не использую эти механизмы
чума... это основы в RDBMS.
Просто решаю это всё софтверно - при удалении из справочника операция будет запрещена, если есть хотя бы одна ссылка в "рабочих таблицах"
ты перед ответом почитал-бы таки хелп к IBAnalyst. FK при проверке ссылок видит все версии, в том числе non-committed. Что триггерами что софтверно ты без явного блокирования записей поддержать ссылочную целостность не можешь в принципе.
Знаит в РСУБД всё ж таки эти механизмы лучше задействовать, чем обрабатывать возможные ошибки "вручную" в коде клиента?
еще раз "чума". для того клиент-сервер и сделан, чтобы не париться с попытками контроля целостности на клиентской стороне.
Но, разумеется, ошибки такого рода, приходящие с сервера, надо обрабатывать на клиенте, хотя бы для того чтобы клиенту показать вразумительное сообщение, а не violation of foreigh key.

Так что, срочно читай что-нибудь по проектированию БД в RDBMS. Можно Дейта.
Какие на твой взгдяд программы совершенно необходимы для нормальной полноценной работы с тем же FB? Ну кроме самого FB и приложения в котором я делаю клиентскую часть, конечно? Smile Я честно говоря думал что IBExperet'а будет вполне достаточно, тем более для России он бесплатен...
безобразие какое то. :) ты еще скажи, что gbak-ом из командной строки не умеешь пользоваться. Или что IBAnalyst 1.95 платный. И так далее...
Неужели ни разу мысль не шевельнулась IBA поставить? Или "впервые слышу"? Инструменту уж три года как...

Kotъ-Begemotъ
Сообщения: 250
Зарегистрирован: 25 июл 2007, 21:33

Сообщение Kotъ-Begemotъ » 06 сен 2007, 01:57

kdv писал(а):
я просто никогда не использую эти механизмы
чума... это основы в RDBMS.
Нутк я ж с RDBMS собственно только и начинаю работать... До этого только так - баловался. А Paradox всё же не RDBMS никак...

Просто решаю это всё софтверно - при удалении из справочника операция будет запрещена, если есть хотя бы одна ссылка в "рабочих таблицах"

ты перед ответом почитал-бы таки хелп к IBAnalyst. FK при проверке ссылок видит все версии, в том числе non-committed. Что триггерами что софтверно ты без явного блокирования записей поддержать ссылочную целостность не можешь в принципе.
Скачал уже, сейчас займусь прочтением...
Знаит в РСУБД всё ж таки эти механизмы лучше задействовать, чем обрабатывать возможные ошибки "вручную" в коде клиента?

еще раз "чума". для того клиент-сервер и сделан, чтобы не париться с попытками контроля целостности на клиентской стороне.
Но, разумеется, ошибки такого рода, приходящие с сервера, надо обрабатывать на клиенте, хотя бы для того чтобы клиенту показать вразумительное сообщение, а не violation of foreigh key.
Ну в принципе да, но сильно зависит от клиента. Ведь вполне возможна ситуация, когда просто всилу особенностей клиента невозможен подобный конфликт, согласись. У меня всё-таки не совсем классическая задача, и вероятность прямых конфликтов пользователей пытающихся редактировать одну и ту же запись крайне низка в принципе. Тут больше взаимодействие - изменения внесённые одним видят другие, и так далее, чем конкуренция.
Так что, срочно читай что-нибудь по проектированию БД в RDBMS. Можно Дейта.
Не помнишь полного названия труда? Я конечно по автору поищу...
Не надо, нашёл. Крис Дейт "Введение в системы баз данных", 8-изд. Скачал в электронном виде.
Какие на твой взгдяд программы совершенно необходимы для нормальной полноценной работы с тем же FB? Ну кроме самого FB и приложения в котором я делаю клиентскую часть, конечно? Smile Я честно говоря думал что IBExperet'а будет вполне достаточно, тем более для России он бесплатен...

безобразие какое то. :) ты еще скажи, что gbak-ом из командной строки не умеешь пользоваться. Или что IBAnalyst 1.95 платный. И так далее...
Неужели ни разу мысль не шевельнулась IBA поставить? Или "впервые слышу"? Инструменту уж три года как...
Погоди вроде подобные gbak утилиты входят в FB? А я про дополнительные говорил... Про Analyst впервые слышу, хоть он и три года уже как, но я же говорю - я еще "чайник", только начинаю с РСУБД работать, многое непривычно, хотя кое-что уже почитал...

Dimitry Sibiryakov
Заслуженный разработчик
Сообщения: 1436
Зарегистрирован: 15 сен 2005, 09:05

Сообщение Dimitry Sibiryakov » 06 сен 2007, 08:58

Аксиоматика:
"Вода - мокрая, жизнь - дерьмо, у таблицы - первичный ключ." (с) не помню чей. Возможно даже Деда.

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Сообщение kdv » 06 сен 2007, 09:28

8-изд. Скачал в электронном виде.
с трудом верится, чтобы книга такого объема была в электронном виде.
там под 1000 страниц мелким шрифтом...

Kotъ-Begemotъ
Сообщения: 250
Зарегистрирован: 25 июл 2007, 21:33

Сообщение Kotъ-Begemotъ » 06 сен 2007, 20:44

kdv писал(а):
8-изд. Скачал в электронном виде.
с трудом верится, чтобы книга такого объема была в электронном виде.
там под 1000 страниц мелким шрифтом...
30 с лишком метров. Могу ссылку дать, только там регистриться надо :)

Kotъ-Begemotъ
Сообщения: 250
Зарегистрирован: 25 июл 2007, 21:33

Сообщение Kotъ-Begemotъ » 06 сен 2007, 20:46

Dimitry Sibiryakov писал(а):Аксиоматика:
"Вода - мокрая, жизнь - дерьмо, у таблицы - первичный ключ." (с) не помню чей. Возможно даже Деда.
То есть это правильно даже для случаев когда в таблице записи могут быть неуникальны? То есть вводить "суррогатный" ID заполняемый, скажем не по генератору только для того, чтобы был PK? Ну в принципе не вопрос ввести PK. Как говорится - надо, так надо... :)

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Сообщение kdv » 06 сен 2007, 22:04

для таблиц-логов первичный ключ необязателен, что является исключением из правил.

golkanavt
Сообщения: 82
Зарегистрирован: 10 янв 2006, 13:57

Сообщение golkanavt » 28 сен 2007, 18:07

Подниму эту тему, т.к. имеется схожий вопрос. Как и в смежной теме про BLOB в ХП, речь идет о перегоне MS SQL базы под Firebird. Реально ли сделать комплексный ПК по нескольким строковым полям (в оригинале varchar(128), я ужал до 64) или же все упрется в невозможность создания индекса для этого ключа из-за длины полей?

WildSery
Заслуженный разработчик
Сообщения: 1738
Зарегистрирован: 05 июн 2006, 16:19

Сообщение WildSery » 28 сен 2007, 18:17

PK по строковым полям обычно не делают.

hvlad
Разработчик Firebird
Сообщения: 1244
Зарегистрирован: 21 мар 2005, 10:48

Сообщение hvlad » 28 сен 2007, 18:30

golkanavt писал(а):Подниму эту тему, т.к. имеется схожий вопрос. Как и в смежной теме про BLOB в ХП, речь идет о перегоне MS SQL базы под Firebird. Реально ли сделать комплексный ПК по нескольким строковым полям (в оригинале varchar(128), я ужал до 64) или же все упрется в невозможность создания индекса для этого ключа из-за длины полей?
В FB2 - более чем реально.

golkanavt
Сообщения: 82
Зарегистрирован: 10 янв 2006, 13:57

Сообщение golkanavt » 28 сен 2007, 18:33

PK по строковым полям обычно не делают.
Прекрасно это понимаю и одобряю, но данный случай не вписывается в общепризнанные каноны. База должна быть именно такой, какой ее спланировали разработчики Sybase.
В FB2 - более чем реально.
Понятно, значит пора задумываться о переходе с 1.5.3 на двойку...

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Сообщение kdv » 28 сен 2007, 18:55

если не пудрить мозг создавая строковый столбец с collate, то и 254 символа в ключ влезут. 64 - это если collate приписать не win1251.
а в 1.5 это без надобности. да и вообще...
www.ibase.ru/devinfo/ibrusfaq.htm

golkanavt
Сообщения: 82
Зарегистрирован: 10 янв 2006, 13:57

Сообщение golkanavt » 28 сен 2007, 19:36

если не пудрить мозг создавая строковый столбец с collate, то и 254 символа в ключ влезут. 64 - это если collate приписать не win1251.
а в 1.5 это без надобности
Отстал я видимо от жизни, по старой памяти в новую базу влепил COLLATE PXW_CYRL

Ответить