Ключевых полей может быть несколько - так называемые состваные ключи. Поэтому только id - уже не подойдет. В целом почитайте о Нормальных формах (НФ) для БД. 3-я нормальнай форма вполне подойдет для большой части проектируемых баз. Но если вы все же желаете попридираться то можно использовать форму Бойса-Кодда. Кроме того у вас ничего не написано про методы индексирования. Напрмер в большинстве случаев оптимальным будет использовать B-деревья.
На вотте запрещена даже к упоминанию. Сленг порицается модераторами и контингентом.
Ты лучше сам зугугли - прямо на нее и попадешь. Шапка из фольги и марлевая повязка рекомендуются. ;-)
Да я в курсе... Просто с нынешней работой достаточно одного ID (там такое иногда увидеть приходятся, что ни в сказке сказать, ни носом почуять). Вот, пытаюсь продвинуть хоть какие-то правила разработки.
> Кроме того у вас ничего не написано про методы индексирования. Напрмер в большинстве случаев оптимальным будет использовать B-деревья.
Нельзя ли привести перечень параметров команды CREATE INDEX для указания метода индексирования? /me инженер-системотехник по АСОиУ, знаю всё, но неглубоко!!! Потому и интересуюсь.
Заплыв в обсуждения статей - исключительно в ОЗК, и только с изолирующим противогазом с чОрными стеклами, чтобы не ослепнуть от ярчайшего накала ПравдыЪ!!!
Ну, если в двух словах - не надо даже своим приложением лезть в данные. Следует разделять логику работы приложения и работы с данными. Приложение должно только постучаться к БД и сказать - "вот, хочу получать такие данные" или "хочу поменять такие данные". А уж как их получать или менять - пусть с этим разбирается БД
> 3-я нормальнай форма вполне подойдет для большой части проектируемых баз. Но если вы все же желаете попридираться то можно использовать форму Бойса-Кодда.
Нормальные формы эт конечно удобно и красиво. Но ждать выполнения запроса с 3-5 join'ами на таблицах с сотнями тысяч записей несколько грустно.
>2. Ключевое поле должно называться ID и никак иначе! Поле, содержащее наименование сущности, описываемой данной таблицей, должно называться CAPTION
>Пояснение. Единый принцип именования полей сокращает время на написание запросов и изучение структуры БД. Я думаю, это понятно всем, но указать всё-таки надо. А почему именно CAPTION, а не NAME? См. следующий пункт.
В запросах с иннер джойнами потом возможны проблемы. Плюс, если использовать например CustomerID а не ID в случае связи двух таблиц, имена полей в главной и дочерней таблице будут совпадать (CustomerID ), что опять же облегчит понимание и написание запроса.
>4. Не забывай про внешние ключи. Не следует рассчитывать на то, что с данной БД будет работать только твоя программа, и уж в ней-то точно будут вводиться только правильные данные. Если делаешь ссылку на другую таблицу - не ленись, создай внешний ключ. Целостность данных - наше всё. Не надо делать помойку из базы данных.
Помимо внешних ключей ещё надо не забывать создавать индексы по этим полям в дочерних таблицах, что существенно ускорит джойн.
> Ну, если в двух словах - не надо даже своим приложением лезть в [таблицы напрямую INSERTами и UPDATEми].
Да я это понял, и целиком и полностью согласен. У тебя в п.6 отсутствует "не" в первом предложении. Поэтому получились взаимоисключающие параграфы. Должно быть как-то так:
> 6. Старайся [не] работать с таблицами напрямую.
Я бы изложил п.6 следующим образом.
6. Приложение не должно использовать операции для работы непосредственно с таблицами (TABLE). Вместо этого, выборка данных из БД должна осуществляться приложением только из представлений (VIEW), а обновление данных должно выполняться путём вызова встроенных процедур БД.
Одна беда, не все СУБД поддерживают встроенные процедуры. Вот SQLite, например, не поддерживает, и для него п.6 выполнить не получится :(
> Плюс, если использовать например CustomerID а не ID в случае связи двух таблиц, имена полей в главной и дочерней таблице будут совпадать (CustomerID ), что опять же облегчит понимание и написание запроса.
1. Алиасы рулят
2. В таблице, на которую ссылаешься (в нашем случае - CUSTOMERS) ключевое поле зовется ID
from ORDERS O
left join CUSTOMERS C on (O.CUSTOMER_ID = C.ID)
Потому что каждая таблица содержит один объект (единственное число) инфологической модели, но несколько (множественное число) экземпляров этого объекта, по одному экземпляру в одной строке таблицы.
> У тебя в п.6 отсутствует "не" в первом предложении.
Уже подсказали, уже исправил, но всё равно - спасибо.
> Одна беда, не все СУБД поддерживают встроенные процедуры. Вот SQLite, например, не поддерживает, и для него п.6 выполнить не получится :(
Обрати внимание на структуру тех двух таблиц, которые приведены в примере: LISTS содержит информацию, сходную по структуре, но разную по содержанию. Т.е., в LISTS могут содержаться как списочные данные об адресах, так и о породах кроликов в Новой Зеландии - всё зависит от LIST_TYPES_ID
> from ORDERS O
> left join CUSTOMERS C on (O.CUSTOMER_ID = C.ID)
А потом ты вставишь в этот запрос ещё одну таблицу D, в которой тоже есть поле ID, в результате правки перепутаешь C.ID и D.ID в отношении ON и будешь долго тупить на пустой результат выполнения запроса.
А вот если в С и D имена полей ID будут разными, то конструкция O.CUSTOMER_ID = D.DERIVATIVE_ID (например) чётко укажет тебе на источник ошибки. Более того, тебе даже в голову не придёт такое написать. А если ты напишешь C.DERIVATIVE_ID, тебе на эту твою ошибку укажет уже СУБД, как на отсутствие поля DERIVATIVE_ID в таблице CUSTOMERS.
Начинал я (ну, и до сих пор в своих личных проектах юзаю - почти первая любовь 60) Interbase/Firebird. Там была шикарная IDE - IBExpert называется, возможно, встречал. В ней можно было посмотреть зависимости для каждой таблицы. На кого эта таблица ссылается, кто ссылается на неё...
Потом занялся ораклом. В конторе, где я трудился, использовался PL/SQL Developer Express. Конечно, мог многое, но не так, как я привык. Пришлось написать своё. В самопальной фиговинке - опять отдавались все зависимости.
Затем - MS SQL. Использовал MSSQL Manager. Он тоже выдавал зависимости. Жить было еще можно.
А вот сейчас юзаю MySQL. Ненавижу эту недоСУБД уже давно, но наиболее плотно с ней пришлось заняться вот прямо сейчас.
Подскажи мне, вдруг я чего-то не знаю - как выяснить с первого взгляда, на какую таблицу ссылается поле DERIVATIVE_ID, если нет таблицы DERIATIVE?
То есть ЧеготоItem - это экземпляр сущности Чегото. Таблица, представляющая совокупность (коллекцию, множество) всех экземпляров объекта, так называться не может. Именем ЧеготоItem можно, например, назвать курсор во встроенной процедуре, который будет пробегать в цикле по всем записям таблицы Чегото.
> Индексы по полям, по которым выполняется join, уже не помогают?
Без них вообще страшно. Особенно когда там двойное - тройное вложение. Типа документ - клиент - адрес. А в некоторых документах у меня энтих клиентов 3.
Сейчас, сейчас