Шаблоны базы данных для разделения больших иерархических наборов данных

Question

Существуют ли наилучшие правила / шаблоны или общие рекомендации для разделения больших объемов иерархических данных?

Подумайте, скажем, о базе данных всех людей в данной стране и о том, кто с кем работал. Думая о единицах "человек" в отдельности, если нужно хранить большое количество данных о каждом человеке, то естественным подходом, по-видимому, является разделение населения на несколько горизонтальных разделов. Однако отношения (кто с кем работал) могли (и будут) пересекаются. Кластеризация этих отношений (т. Е. Использование работодателя, например, в качестве ключа раздела для минимизации перекрестных ссылок) со временем не будет жизнеспособным, поскольку данные становятся все более и более сшитыми. Такая кластеризация также приведет к несбалансированным разделам, которые будут препятствовать масштабируемости.

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

Спасибо.

Answer 1

Кажется, у вас есть три проблемы:

1. Хранение данных о сотруднике (исключая отношения / иерархию)
2. Иерархия между работодателем и сотрудником (которая может меняться со временем)
3. История работы сотрудника с сотрудником (опять же, меняющаяся со временем)

Для решения каждого по очереди:

1. Данные о сотрудниках: они могут быть разделены, с уникальным идентификатором, с альтернативным ключом для фамилии + имена и дата рождения. Либо раздел с равномерным распределением по идентификатору, либо другая информация, такая как область / регион (хотя это будет означать, что некоторые разделы будут горячее других)

2. Иерархия работодателя / сотрудника: необходима вторичная таблица для определения этого, позволяющая вносить изменения во времени. например. Employee id, Employer id, start date, end date и набирается employee id + employer id и обратно employer id + employee id. Я рекомендую прочитать следующее: http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back, возможно, есть идеи, которые хорошо подходят для размера ваших данных.

3. История работы сотрудника / сотрудника. Требуется еще одна вспомогательная таблица, очень похожая на # 2, с перекрестными ссылками на сотрудников и временем их совместной работы. например. employee1 id, employee2 id, start date, end date, который индексируется каждым из идентификаторов как минимум.

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