Лучшая структура данных для этих отношений - PullRequest
1 голос
/ 11 июня 2010

У меня есть вопрос о базе данных «стиль».

Мне нужен способ хранения учетных записей пользователей.Некоторые пользователи «владеют» другими учетными записями (суб-аккаунтами).Однако не все учетные записи пользователей принадлежат, только некоторые.

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

TABLE accounts (
 ID 
 ownerID -> ID
 name
)

... даже если будут некоторыеЗначения NULL в столбце ownerID для учетных записей, у которых нет владельца.

Или стилистически предпочтительнее иметь две таблицы, например так.

TABLE accounts (
 ID 
 name
)

TABLE ownedAccounts (
 accountID -> accounts(ID)
 ownerID -> accounts(ID)
)

Спасибо за совет.

Ответы [ 2 ]

2 голосов
/ 11 июня 2010

Я бы держал таблицы отдельно.

Самостоятельные внешние ключи могут причинить много боли при обновлении / удалении.

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

0 голосов
/ 11 июня 2010

2-й выбор самый лучший.

С теоретической точки зрения это регрессия отношения «n-to-m» (или «многие-ко-многим»), где таблицы сторон «n» и «m» объединены в одну уникальную «учетную запись». 'table, и где таблица' OwnedAccount 'является таблицей связывания.

Использование этой модели позволит вам без проблем реализовать правила целостности данных на уровне сервера. В дополнение к аргументам #mdma, это также значительно упростит запросы и отчеты. В этой модели также могут быть реализованы дополнительные «расширения» правил владения (несколько владельцев для одной учетной записи, каскадное владение).

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...