Хм, более интересно было бы почитать про шаблоны СУБД. На примерах решения
1) Дополнительные атрибуты. Пример: есть таблица клиентов с полями id, birthday, firstName, secondName, sex, email. В процессе эксплуатации для небольшой части клиентов возникает необходимость добавить доп реквизиты: должность, степень знания english и т.п.
Alter-ить таблицу не всегда допустимо и тут возможны варианты:
1.1) Создаем табличку с полями idClient, NameFeature:Text, valString, valDateTime, valNumber — где в поле с именем нужного типа прописываем значение.
1.2) Создаем табличку с полями idClient, feature1, feature2… (еще как вариант добавить имя таблицы отдельной колонкой — но в одном месте все держать свои минусы)
1.3) Варианты с доп. полем в таблице, заполненным в виде «feature2=..., feature3=», JSON, XML-типах и т. п. еще более ужасны в связи с отходом от реляционности.
Плюс 1.1 — один раз создали и наполняем любыми доп атрибутами, минусы — размер, поиск инфы по клиенту чуть сложней
Плюсы 1.2 — проще строить запросы, минусы — альтерить и следить за этим + размер еще больше распухнуть может
2) Модификация данных по времени. Требуется в запросах выдавать данные с привязкой ко времени.
Клиенты могут менять secondname(смена фамилии), email…
При подобных изменениях в связанную таблицу кидать новое(в основной оно не меняется) или старое (т.е логируем) значение?
Если еще далее делать выносить данные в отдельные архивные таблицы (не выдавливать из БД совсем) — OldClients, то запросы с поиском по всем данным еще более усложнятся (Какой ORM умеет?). Клиенты тут для примера(как таблицы, для которой нельзя делать простые вставки/удаления для данного случая, так как на данные есть внешние ссылки), в реале приходится выносить в old-таблицы с данными по активности (где записей на порядке больше).
1) Дополнительные атрибуты. Пример: есть таблица клиентов с полями id, birthday, firstName, secondName, sex, email. В процессе эксплуатации для небольшой части клиентов возникает необходимость добавить доп реквизиты: должность, степень знания english и т.п.
Alter-ить таблицу не всегда допустимо и тут возможны варианты:
1.1) Создаем табличку с полями idClient, NameFeature:Text, valString, valDateTime, valNumber — где в поле с именем нужного типа прописываем значение.
1.2) Создаем табличку с полями idClient, feature1, feature2… (еще как вариант добавить имя таблицы отдельной колонкой — но в одном месте все держать свои минусы)
1.3) Варианты с доп. полем в таблице, заполненным в виде «feature2=..., feature3=», JSON, XML-типах и т. п. еще более ужасны в связи с отходом от реляционности.
Плюс 1.1 — один раз создали и наполняем любыми доп атрибутами, минусы — размер, поиск инфы по клиенту чуть сложней
Плюсы 1.2 — проще строить запросы, минусы — альтерить и следить за этим + размер еще больше распухнуть может
2) Модификация данных по времени. Требуется в запросах выдавать данные с привязкой ко времени.
Клиенты могут менять secondname(смена фамилии), email…
При подобных изменениях в связанную таблицу кидать новое(в основной оно не меняется) или старое (т.е логируем) значение?
Если еще далее делать выносить данные в отдельные архивные таблицы (не выдавливать из БД совсем) — OldClients, то запросы с поиском по всем данным еще более усложнятся (Какой ORM умеет?). Клиенты тут для примера(как таблицы, для которой нельзя делать простые вставки/удаления для данного случая, так как на данные есть внешние ссылки), в реале приходится выносить в old-таблицы с данными по активности (где записей на порядке больше).
Опять свои плюсы/минусы.