Советы при проектировании БД. 2

Хоть и сказал, что вчера опубликую еще одну статью, но — поленился. Все-таки лень — вещь не всегда хорошая. Вчера проленился и не опубликовал статью. Но сегодня надо себя заставить и дописать вторую часть про советы при проектировании структуры баз данных.

Напомню, что эти советы — основаны на моем опыте. Можно их не воспринимать всерьез, но я считаю, что это очень полезные советы. Если бы я их соблюдал пару лет назад — то было бы намного лучше, чем происходит сейчас. Так что все-таки советую их учитывать при работе.

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

Обязательно проставляйте альтернативные ключи (если у вас стоит суррогатный первичный ключ, чаще всего — цифровой, то все-равно нужно найти такую совокупность атрибутов в вашей таблице, которая будет уникальна. Необходимо это для того, чтобы даже при желании невозможно было ввести одинаковые данные. А уж по случайности — и того чаще получается ввод одинаковых данных в таблицу);

Сразу проставляйте внешние ключи (опять же — для большей надежности данных в таблицах. Если у вас будут стоять внешние ключи — то в таблицу нельзя будет ввести что-либо другое (кроме значения из связанной таблицы), И проставлять внешние ключи нужно до того, как вы начнете базу заполнять, а то потом сложно будет все менять. Конечно же, нужно давать названия для внешних ключей понятными. Как вариант — первое слово в названии — это название основной таблицы, второе слово — название таблицы, из которой должны браться данные);

Одинаковые имена ключевых полей (в частности советую чтобы имя поля в таблице было таким же, как и связанное с ним поле в другой таблице, по которому вы внешний ключ делаете. Я пока не встречал редакторов баз данных, которые принуждали бы использовать одинаковые имена. Обычно — можно задать любое имя. В связи с этим — могут получиться недоразумения, когда имя поля одно, а имя поля в связанной с ним таблице — другое. И приходится потом вспоминать что к чему в этой связи).

Сегодня меня время поджимает, так что на этом я закончу. В следующей (третьей) статье я дорасскажу о том, что еще не сказал. И закончу данную серию на этом. Советы все эти проверены на собственном опыте, так что лично я их придерживаюсь при проектировании.

Кстати, когда делал курсовик для человека из университета, он (помимо курсовика) интересовался у меня о том, кто может осуществить вывоз промышленного мусора с хорошими ценами. В тот момент я этого не знал, но недавно узнал. Компания ОлимпЭкоТранс осуществляет такую работу. Так что если надо и читаешь эти строки — переходи по ссылке выше и заказывай работу.