Хорошая конструкция таблицы db: одна таблица смешивает различные сущности или отдельную таблицу для каждой сущности

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

Роальд Ван Дорн абсолютно прав. Если у вас есть одна таблица, и Вы ее каким-либо образом расширяете, вы нарушаете Вторая Нормальная Форма. Как сказал Уильям Кент: "вторая нормальная форма нарушается, когда неключевое поле является фактом о подмножестве ключа."Пример Роальда Ван Дорна" телефонные номера для сотрудников " иллюстрирует нарушение.

Уильяма Кента простое руководство по пяти обычным формам в теории реляционных баз данных большая бумага к просмотрите, задавая себе вопрос о дизайне базы данных.

Я скажу, что все ответы выше-1. исправьте приведенный пример в вопросе и 2. правильно почти все время.

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

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

вот пример, который делает мой случай:

предположим, два типа сущностей, корпорация и лицо. Корпорация обычно принадлежит человеку, но иногда корпорация принадлежит другой корпорации.

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

учитывая, что владельцем / родителем корпорации / ребенка может быть либо человек, либо amcorporation, вы можете начать видеть проблему. Напротив, если бы только люди могли владеть корпорациями, ваша таблица ссылок на собственность очень обычна со столбцами: OwnershipID( вид ненужного), CorporationID, PersonID.

вместо этого вам нужно что-то вроде: OwnershipID, CorporationID, OwnerID, OwnerType И так или иначе, вы можете сделать это, но это не будет весело, мягко говоря.

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

аналогично этой "проблеме" зарегистрированным агентом также может быть корпорация, такая как юридическая фирма, CPA или компания по регистрации бизнеса, приводя некоторые типичные примеры. Точно так же, как агент-человек, агент-корпорация действительно не должна иметь свой собственный рекорд. Он должен вернуться к уже существующей записи о своем корпоративном существовании в таблице корпорации. [за исключением того, что я в конечном счете говоря не имейте таблицу корпорации]

Так же, как таблица ссылок, которая соответствовала каждой корпорации ее владельцу(владельцам) любого типа, лица или корпорации, вы мог бы есть таблица ссылок агента: AgentRepresentationID, CorporationID, AgentID, AgentType... но опять же, это было бы уродливо (ИМО), когда вам нужно собрать связанных агентов-некоторые из таблицы Person, некоторые из таблицы Corporation.

поэтому, в этом случае, вы можете посмотрите, как нейтральный тип сущности может быть выгодным. Это было бы примерно так:--4-->

Таблица: EntityAll ключевой столбец: Значением EntityId, EntityType (или EntityTypeID, если вы настаиваете, ссылка, чтобы получить описание), EntityName (существуют проблемы с именами и различными типами... off тема к этому сообщению)

Таблица Ссылок: CorporationOwnership ключевой столбец: OwnershipID (опять же, мой комментарий, что это не обязательно), ChildEntityID (принадлежащий объект; назван "дочерним" для ясность, я бы не назвал это так.) ParentEntityID (родительская сущность)

Таблица Ссылок: AgentRepresentation ключевой столбец: AgentRepresentationID (...Я не скажу этого.), CorporationEntityID (представляемая корпорация), AgentEntityID (из таблицы сущностей, приравнивая к записи, которая является агентом здесь)

хотя вы можете быть в порядке с моей архитектурой, вас должно немного беспокоить имя столбца в таблицах ссылок. Меня это беспокоит. Обычно второй и третий имена столбцов в этих таблицах точно совпадают с именами столбцов, которые вы JOIN в соответствующей таблице каждого объекта (ха-ха, но каждый объект не есть соответствующая таблица, поэтому имена столбцов таблицы ссылок не могут совпадать с именами столбцов источника, поскольку они являются одним и тем же столбцом). Технически это не имеет значения, но это нарушит ваши соглашения об именах, которые должны иметь значение, но недостаточно, чтобы не делать этого.

в случае, если я еще не довез его до дома достаточно хорошо, вот как ты справишься. Вы JOIN таблица EntityAll сама по себе, чтобы получить то, что вам нужно.

Список всех корпусов и их владельцев (в T-SQL):

SELECT Corp.EntityName as CorpName, Owner.EntityName as OwnerName
FROM EntityAll as Corp
JOIN CorporationOwnership as Link on (Corp.EntityID = Link.ChildEntityID)
JOIN EntityAll as Owner on (Link.ParentEntityID = Owner.EntityID)

следовательно, вы сделали бы то же самое, чтобы получить агента, а не владельца(ов).

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

Если вы настаиваете, я ошибаюсь, хотя, дай мне знать. Предложите, как вы создадите мой пример с отдельными таблицами сущностей корпорации и лица. Ура!