iBase.ru Forum

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

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 и в этом случае работать должно всё гораздо быстрее (особенно если таблицы достаточно большие) по сравнению со скоростью выполнения без индексов?

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

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

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

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

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

Хм... То есть ты про Referential Integrity ? Сложный вопрос... Тебе не верить глупо, я не специалист, но при том, что Paradox поддерживает RI (пусть и худо-бедно) я просто никогда не использую эти механизмы... Просто решаю это всё софтверно - при удалении из справочника операция будет запрещена, если есть хотя бы одна ссылка в "рабочих таблицах" например... Знаит в РСУБД всё ж таки эти механизмы лучше задействовать, чем обрабатывать возможные ошибки "вручную" в коде клиента?

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

В связи с этим еще вопрос. Какие на твой взгдяд программы совершенно необходимы для нормальной полноценной работы с тем же FB? Ну кроме самого FB и приложения в котором я делаю клиентскую часть, конечно? Я честно говоря думал что IBExperet'а будет вполне достаточно, тем более для России он бесплатен...

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

я просто никогда не использую эти механизмы

чума... это основы в RDBMS.

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

ты перед ответом почитал-бы таки хелп к IBAnalyst. FK при проверке ссылок видит все версии, в том числе non-committed. Что триггерами что софтверно ты без явного блокирования записей поддержать ссылочную целостность не можешь в принципе.

Знаит в РСУБД всё ж таки эти механизмы лучше задействовать, чем обрабатывать возможные ошибки "вручную" в коде клиента?

еще раз "чума". для того клиент-сервер и сделан, чтобы не париться с попытками контроля целостности на клиентской стороне.
Но, разумеется, ошибки такого рода, приходящие с сервера, надо обрабатывать на клиенте, хотя бы для того чтобы клиенту показать вразумительное сообщение, а не violation of foreigh key.

Так что, срочно читай что-нибудь по проектированию БД в RDBMS. Можно Дейта.

Какие на твой взгдяд программы совершенно необходимы для нормальной полноценной работы с тем же FB? Ну кроме самого FB и приложения в котором я делаю клиентскую часть, конечно? Smile Я честно говоря думал что IBExperet'а будет вполне достаточно, тем более для России он бесплатен...

безобразие какое то. ты еще скажи, что gbak-ом из командной строки не умеешь пользоваться. Или что IBAnalyst 1.95 платный. И так далее...
Неужели ни разу мысль не шевельнулась IBA поставить? Или "впервые слышу"? Инструменту уж три года как...

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 впервые слышу, хоть он и три года уже как, но я же говорю - я еще "чайник", только начинаю с РСУБД работать, многое непривычно, хотя кое-что уже почитал...

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

8-изд. Скачал в электронном виде.

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

kdv писал(а):

8-изд. Скачал в электронном виде.

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

30 с лишком метров. Могу ссылку дать, только там регистриться надо

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

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

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

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

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

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

В FB2 - более чем реально.

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

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

В FB2 - более чем реально.

Понятно, значит пора задумываться о переходе с 1.5.3 на двойку...

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

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

Отстал я видимо от жизни, по старой памяти в новую базу влепил COLLATE PXW_CYRL