У меня есть таблица Person в которой хранятся тривиальные данные не требующие связей. В один момент заказчик захотел добавить в приложение огромную кучу персональных данных для некоторых людей. То есть будут люди у которых появится дополнительная инфа, а есть те у которых этой инфы не будет. Я решил создать таблицу AdditionalDataTable где в качестве первичного ключа внешний ключ на Person, а остальные столбцы хранят внешние ключи на таблицы с дополнительной информацией. Скажите, с точки зрения проивзодительности такая архитектура допустима или лучше продумать другое решение? Связи в дополнительных таблицах и есть разные и один ко многим и один к одному.
> Скажите, с точки зрения проивзодительности такая архитектура допустима или лучше продумать другое решение? Сразу — не бывает "абстрактной" производительности, бывает только для каких-то задач ([классов] запросов). > Если не делать эту AdditionalDataTable, тогда для некоторых людей придётся писать нули А в AdditionalDataTable у Вас NULL не будет?
Раз добавляется "куча данных" и вопрос про производительность, то да, хранить их в отдельной таблице обычно эффективнее, чем в общей для всего. Насчёт необходимости нескольких отдельных таблиц вопрос спорный и зависит от того, как оно будет обновляться, выбираться, проверяться, возможно ли наличие одних данных без других. В целом противопоказаний нет, но некоторый оверхед на джойнах может получиться (если таблиц много).
Обсуждают сегодня