Нельзя безусловно считать «один ко многим» лучше, чем «многие ко многим». Сначала определяют бизнес-правило: может ли один объект быть связан сразу с несколькими объектами с другой стороны?
Для простой модели номер можно хранить прямо в связи driverphone вместе с driverid и типом. Отдельная сущность phone полезна, когда у номера есть собственные свойства и независимое переиспользование.
Исправление ошибочно записанного номера и реальная смена номера — разные события. В первом случае корректируют неверный факт с аудитом, во втором создают новый период действия связи.
Историю можно вести версиями строк, журналом изменений или отдельной исторической таблицей. Выбор зависит от того, нужно ли восстановить состояние на дату или только узнать, кто что изменил.
Сам номер телефона не подходит как уникальный ключ связи, если он может относиться к разным водителям и типам. Используйте отдельный ID записи и бизнес-ограничение на допустимые повторы.
Даты действия номера для конкретного водителя хранят в записи связи «водитель—телефон». Они характеризуют назначение номера, а не саму строку телефонного номера.
Сравнение реляционных и нереляционных БД реляционные БД хранят сведения в таблицах с фиксированной схемой для формирования запросов применяют SQL поддерживают свойства ACID (атомарность, согласованность, изоляция,…
ускорение чтения за счёт сокращения числа JOIN рост производительности запросов применение в аналитике и OLAP-системах кэширование предварительно рассчитанных агрегатов увеличение избыточности и риска рассогласования…
Основные виды первичных ключей уникальное значение, однозначно идентифицирующее запись в таблице базы данных естественный ключ (natural key) — формируется на основе имеющихся атрибутов, например ИНН суррогатный ключ…