Заметки программера Чему равно дважды два равно четыре?
Revert
Переводим ASDF в ФЫВА и наоборот.
Хорошо!!
Радикальный улучшатель настроения.
Грамота
Покажи всем, насколько ты крут - выпиши себе мега-грамоту!
08.09.2014, 19:06   Статьи » Кодинг - разное

Хинты по проектированию БД

Пункт 0, общий.

При написании БД и/или кода всегда держи в голове, что сопровождать этот код и эту БД будет мэр города Куева, и он знает твой адрес. Другими словами - пиши понятно, используй «говорящие» имена таблиц, полей и переменных, не пренебрегай комментариями. Помни, что одна из заповедей Бусидо Программиста - «Хороший код в комментариях не нуждается» - не более, чем шутка.

Проектирование БД.

1. Таблица должна именоваться не более, чем 10-12 символами, но в то же время её название должно отображать её назначение.
Пояснение. Многие СУБД не поддерживают имена объектов длиной более 30 байт. Таким образом, когда ты будешь создавать внешний ключ на эту таблицу (см. ниже) - можешь и не вместиться.

2. Ключевое поле должно называться ID и никак иначе! Поле, содержащее наименование сущности, описываемой данной таблицей, должно называться CAPTION
Пояснение. Единый принцип именования полей сокращает время на написание запросов и изучение структуры БД. Я думаю, это понятно всем, но указать всё-таки надо. А почему именно CAPTION, а не NAME? См. следующий пункт.

3. Не используй в наименованиях таблиц и полей ключевые слова любого из диалектов SQL - можно налететь на такие грабли, что мама не горюй.
Из практики: проектировщик пытался сделать таблицу, в составе которой было поле NAME. Oracle расплакался, что, мол, не могу выполнить запрос. Проектировщик переписал скрипт - create table TABLE_NAME (ID int, “Name” varchar(100)). Поле Name стало регистрозависимым, и программеры очень удивлялись, почему запрос select ID, NAME from TABLE_NAME падал.
Еще раз: не используй в именах таблиц и полей ключевые слова любого синтаксиса SQL

4. Не забывай про внешние ключи. Не следует рассчитывать на то, что с данной БД будет работать только твоя программа, и уж в ней-то точно будут вводиться только правильные данные. Если делаешь ссылку на другую таблицу - не ленись, создай внешний ключ. Целостность данных - наше всё. Не надо делать помойку из базы данных.

5. Именование полей и самих внешних ключей. Имя поля, которое ссылается на другую таблицу - ИмяТаблицыНаКоторуюСсылаешься_ID, имя внешнего ключа - FK_ИмяТекущейТаблицы_ИмяТаблицыНаКоторуюСсылаешься_ID.
Пояснение. Когда через пол-года тебе придется вернуться к старому проекту, ты не будешь ломать себе голову - что же обозначает поле VAL_TYPE, а будешь точно знать, что поле LIST_TYPES_ID ссылается на поле ID таблицы LIST_TYPES. Ну, и см. пункт ноль.
И теперь ты, наверное, понял, почему не следует давать таблицам слишком длинные имена :)

6. Старайся не работать с таблицами напрямую. Таблица - это только хранилище данных. Для обработки используй прокладки, благо, СУБД предоставляют для этого все возможности. Для просмотра используй вьюхи, для изменения - процедуры. Но делай это с умом. К примеру, в том же Firebird использовать вьюху для выборки (с условием) данных из двух таблиц нерационально - сначала будут выбраны все данные из этих таблиц, а потом уже будут отфильтрованы по тем условиям, которые ты задал. Оцени план запроса, благо, IDE для БД уже давно предоставляют эту возможность.

7. Используй индексы с умом. Уже на этапе проектирования прикинь, в каких полях данные будут наиболее сильно отличатся, и по каким полям чаще будет производиться поиск. Вот на эти поля и ставь индексы. Ставить индексы на все поля таблицы - только зазря грузить сервер БД, а у него и без того работы хватает.

8. Если движок БД позволяет - используй домены, они же - определяемые типы данных. В Interbase/Yaffil/Firebird, в Postgre - такое было, в Oracle, MSSQL, MySQL - не обнаружил :( Но если есть - обязательно используй. Это очень удобно. Пояснений и примеров не будет - это надо попробовать самому.

9. Еще раз. Пиши комментарии! Не стесняйся делать описания таблиц, полей, вьюх и процедур, которые ты создаешь. Сэкономишь кучу времени и другим, и себе (когда через пол-годика вернешься к своему же проекту). Все современные СУБД позволяют это сделать, пользуйся этой возможностью.

10. Пара советов из личного опыта:
10.1. Создай пару таблиц: create table LIST_TYPES(ID int, CAPTION varchar(64)) и create table LISTS (ID int, LIST_TYPES_ID int, CAPTION varchar(256)) со ссылкой на LIST_TYPES , как ты можешь увидеть из скрипта в соответствии с хинтами, выданными ранее. Таким образом ты сможешь сделать кучу плоских справочников, обойдясь всего двумя таблицами. К примеру, в LIST_TYPES у тебя есть такие записи:

IDCAPTION
1Город
2Район
3Улица

Далее, в LISTS у тебя следующее содержимое:

IDLIST_TYPES_IDCAPTION
11Воронеж
21Бушер
32Центральный
42Нируга
52Бандарга
63Кольцовская
73Плехановская
83Лиан

Таким образом, плоские справочники строятся не просто, а очень просто.

10.2. Процедуры добавления-изменения редактирования объединяй в одну. Входные параметры - все поля таблицы, которую ты меняешь, выходные - тип поля, которые у тебя в этой таблице служит идентификатором (ID). Принцип прост, как Джордж Буш-младший: проверяем, есть ли в таблице запись с указанным ID (для новых записей, понятное дело, указываем заведомо отсутствующий ID), если нет - добавляем, если есть - изменяем запись.

Комментарии

Борис 09.09.2014, 10:34 #1
1. не согласен
T_CUSTOMER_TRANSACTION понятней чем T_CUST_TR
10 символов это прошлый век. Сокращать как раз можно в ключах, там пофиг.
2. ID не дискриптивно. Связывать таблицы для ORM например не удобно
T_LIST_CONNECTION(ID, ID) так себе. T_LIST_CONNECTION(ID_LIST, ID_CONNECTION)
3. 👍

Стоит добавить, что с ораклом пришла мода на префикс типов в начале имени
T_TABLE, V_VIEW, ID_INDEX_NAME, S_STRING_VAR, D_CREATED и тд

Добавлние комментов отключено на время переезда

Картинки

Прекрасная игра

Егор и разработка

Когда нет домкрата
Ссылки