Наиболее распространённые и серьёзные ошибки при проектировании (моделировании) баз данных

Никакая Информационная Система не обходится без базы данных, которая является вообще основой некоторых проектов. Мало одной хорошо спрограммированной и спроектированной оболочки. Хорошая оболочка под АИС с хранилищем данных стоит порядка 10000 долларов США, но в это же время само хранилище может стоить и сотни тысяч.
Это было лирическим отступлением, а теперь сама суть…

Многие ошибочно полагают, что накидав простенькую модель в CASE средстве наподобие ERWin’а, на этом работа заканчивается, и они глубоко заблуждаются. Есть логическая модель, есть физическая модель, и вот тут то и возникают ошибки. Если вы делаете модель под MySQL, то вы делаете модель на английском языке, так и для MS Access не стоит делать названия полей на русском языке! Так же ни в коем случае НЕЛЬЗЯ делать пробелы в названиях полей таблиц или же в названиях самих таблиц! Вместо пробела ставьте _ и не ошибётесь, так как на вас меньше будут грешить при разработке программной оболочки. Также не стоит делать поля, которые казалось бы, должны иметь целочисленный тип ставить им тип integer. Это касается телефонных номеров и прочих полей, схожих по значению. Сделайте лучше поле типа String и в дальнейшем вы сможете избежать некоторых проблем, например с кодом города, кодом страны, если используется + и так далее.

Вот ещё что на мой взгляд, является грубой ошибкой, так это то, что некоторые делают связь с одной таблицей через три и более. То есть чтобы добраться до 1ой таблицы нужно связаться с ещё тремя таблицами и только после этого получить значение той что нужно. При программировании запрос получается очень сложным, и для дальнейшей оптимизации с целью ускорения работы программы придётся переделывать как базу, так и программу.

Так же не следует ошибочно полагать, что можно обойтись только одной Subject Area (Main). Желательно, но не обязательно, если вы хотите довольно читабельную модель, и тем более если не планируете сами разрабатывать программную оболочку, то готовьтесь заплатить больше или вообще иметь программу такую, как сделана модель, так как не каждый программист будет дорабатывать ваши углы и шероховатости, до идеально гладкой поверхности.
На этом пока и остановлюсь. Будут ещё вопросы или если встречусь с ещё одной кривой моделью и базой, то возможно напишу продолжение.

P.S. Всегда следите за связями. Если вы хотите чтобы в списке контактов был не 1 контакт, а множество контактов, то и не нужно делать связь через одно место… удачной разработки ??