Это нормально, чтобы дублировать значения в SQL

Question

Я не являюсь администратором базы данных, поэтому я не знаком с правильным жаргоном, так что, возможно, название вопроса может немного ввести в заблуждение.

Итак, вещь. У меня есть члены для определенной системы, эти элементы могут быть частью демографического сегмента (любой вид сегмента: любимый цвет кожи, пол, работы и т.д.)

Эти таблицы

SegmentCategory 
ID, Name, Description 

SegmentCategory_segment 
SegmentID, SegmentCategoryID 

Segment 
ID, Name, Description 

MemberSegment 
ID, MemberID, SegmentID 

Так парень который разработал БД, решил убрать все нормальные все, чтобы он поместил пол участника в сегмент, а не в таблицу Участника.

Это нормально? Согласно моей логике, пол, это свойство члена, поэтому оно должно быть на его сущности. Но, делая это, должны быть дублированные данные. (Гендер для члена и пола как сегмент). Однако триггер в таблице Member мог бы исправить это (обновить сегмент при изменении пола)

Необходимо выполнить сканирование 4 таблицы для того, чтобы получить собственность от члена, кажется мне более сложным для меня.

Вопрос в том, прав я или нет? Если да, то как я могу предложить изменения в DBA?

Answer 1

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

У вас может быть запись клиента на две таблицы, например, если некоторые данные доступны или обновляются чаще, чем другие части. Скажите, что вам нужна только половина данных 90% ваших запросов, но не хотите перетаскивать поля varchar (max), которые у вас есть по какой-либо причине.

Сказав это, наличие стола с пол или членом находится на крайнем конце. По моему наивному пониманию вашей ситуации, я чувствую, что вам просто нужен стол для членов с просмотрами сверху для ваших сегментов.

Что касается администратора баз данных, в конечном итоге я представляю, что именно им будет необходимо сохранить целостность данных, поэтому я просто подхожу к ним и скажу «эй, что вы думаете об этом?». Надеюсь, они либо увидят достоинство, либо смогут дать вам основания для их проектных решений.