Начиная с дизайна @Minras (+1), у меня будет
MEMBERS
MemberId
Name
Details
RELATIONS
FromMemberId
ToMemberId
RelationType
Но вместо ограничения проверки я бы добавил третью таблицу:
RELATIONTYPE
RelationType
Description
FromLabel
ToLabel
с RelationType, являющимся целым числом, а «Метки» являются символьными данными. Отношение является «направленным», в том смысле, что вам нужно обратить пристальное внимание на то, какой член «От», а какой «на» (но это не так важно для «ненаправленных» отношений, таких как «пошел в старшую школу»). все вместе"). Этот дизайн позволит вам:
- Определите отношения между людьми с несколькими ярлыками, например,
A is father of B
и B is son of A
.
- Добавить новые отношения, если, когда и при необходимости
Очевидно, что вы либо будете иметь реляционную целостность во всем через внешние ключи или все, что у вас есть, или у вас будет крушение поезда, ожидающее наступления.
Это не решает вопрос о том, как однозначно и однозначно идентифицировать участников с одинаковыми именами. Для этого вам необходимо либо указать атрибут идентификации, используемый людьми в реальном мире для решения таких ситуаций (идентификатор студента? Номер социального страхования?), Либо ввести артефакт, специфичный для вашего приложения (например, логин + пароль). ).