Как правильно хранить родственные отношения?

Question

[Рогатый Бафомет]

Товарищи дорогие, разверните меня, пожалуйста, в правильном направлении и дайте хорошего пинка. Ситуация: есть база, в ней таблица, каждая запись - информация по одному человеку (первичный ключ - id). Необходимо пройти по ней, выявить и сохранить родственников. Критерии отбора определены, вопрос только про сохранение связей между записями одной таблицы. Что-то никак не соображу, как это правильнее сделать - так, чтобы если А родственник Б, то и Б автоматически будет роднёй А. По идее, мы здесь ведём речь о графах? Может быть, эти связи тогда вообще не в реляционной БД хранить? Буду благодарен за любой совет (в том числе RTFM, если будет ссылка на FM). Всем бобра.

Comments

[Oxoron]

Я в свое время создавал таблицу "родственные связи". Столбцы Первый_Родственник_Ид и Второй_Родственник_Ид являлись сложным ключом. Плюс скрипт, который при прогоне основной таблицы заполнял "родственные связи".

[Рогатый Бафомет]

Oxoron: Ага, это первое, о чём я подумал. А у вас большая база была? По скорости оно нормально отрабатывало?

[Oxoron]

База мелкой была. Чисто учебная задача, что-то связанное с тривиумом генетики. По идее, если родственные отношения сложные, родственные связи не разрываются, и инфа по связям нужна часто, и родственников у особи немного (o(1)) - нормальный вариант.
Тут бы конкретно на задачку посмотреть: как высчитывается связь и предполагаемый размер данных.

[Рогатый Бафомет]

Oxoron: Что ж, проверю на практике для начала такой вариант. Спасибо за совет)

Answer 1

[Saboteur]

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

Answer 2

[mayorovp]

Насколько я понимаю, ваша задача - хранение неориентированного графа. Причем основная сложность - в его неориентированности:

Что-то никак не соображу, как это правильнее сделать - так, чтобы если А родственник Б, то и Б автоматически будет роднёй А.

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

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

Правда, оба варианта выглядят не очень красиво. Но тут у меня есть встречный вопрос - а почему, собственно, отношения родства вдруг стали симметричными? Базовых отношений всего два - "родитель-ребенок" и "супруги". Причем только первое отношение относится к кровному родству - и оно является несимметричным. Второе же отношение, вероятно, рассматривать вообще не стоит - из-за его нехороших свойств (к примеру, оно приводит к нетранзитивности родства - так, бывший муж и текущий муж не являются родственниками). Все остальные родственные отношения однозначно выводятся из базовых.

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

Comments

[Рогатый Бафомет]

Я понимаю, о чём вы говорите, но в данном случае нам неизвестна степень родства - то есть просто абстрактный "родственник". По-видимому, учитываться будет только первый уровень, как раз чтобы избежать родства между двумя мужьями) Спасибо за наводку)

Answer 3

[Igor Kalashnikov]

добавьте в табличку колонку: parent_id в котором будет сохранен id родителя.

я такие штуки иерархическими запросами обрабатывал (использовал Oracle)
docs.oracle.com/cd/B19306_01/server.102/b14200/que...

но можно и более обычными инструментами.

Comments

[Oxoron]

Если родителей двое, и родственники считаются до колена n, на больших БД будет тяжело без индексов по новым столбцам. Это если связи типа родитель-ребенок. Могут быть отчимы, приемные родители, или какое множественное наследование.
Для одиночной простой связи Ваш вариант точно рабочий.

[Igor Kalashnikov]

Oxoron: да, согласен, я несколько сузил задачу.
Тогда, усложняем, и имхо хороший вариант давать связать с другой таблицей с отношением(мама;папа), что в принципе уже обсуждается выше.