Дизайн базы данных NO SQL

Question

В качестве учебного проекта я пытаюсь создать приложение на Семейном древе в Azure.

Первый шаг - база данных, я планирую использовать хранилище таблиц.

Как будет выглядеть дизайн хранилища таблиц для приложения Семейное древо?

У меня есть пара решений.

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

Answer 1

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

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

Answer 2

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

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

Answer 3

Мой первый вопрос: как вы планируете получить доступ к информации?Подумайте о структурировании данных, как вам нужно получить к ним доступ.Не стесняйтесь нарушать правила нормализации, которые нас кормили последние 20 лет.Охватите избыточные специализированные модели.Также продумайте все сразу и подумайте об использовании параллельных запросов.если данные хранятся в нескольких местоположениях, следуйте за каждым местоположением одновременно и агрегируйте результаты.

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