Горизонтальная база данных и Вертикальная база данных

Question

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

Я нашел несколько ответов для торговых сайтов, где поля не определены:следует использовать вертикальную структуру базы данных.Но я в замешательстве относительно того, что использовать для сайта генеалогического древа.Должен ли я использовать вертикальный или горизонтальный?

Answer 1

Я предполагаю, что вы используете для хранения реляционную базу данных, такую как Mysql, Ms sql, Sqlite, Postgresql или Oracle?

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

Я бы использовал "горизонтальную" таблицу, а не систему entity-attribyte-value (вертикальная таблица).Вертикальные настольные системы, как правило, работают медленно.Они не могут быть должным образом проиндексированы и сбивают с толку оптимизатор запросов.

Это становится другой историей, когда ваши пользователи могут сами определять новые свойства в своих профилях, такие как eye colo (u) r или favorite colo (u) r.Насколько гибкими вы хотите, чтобы эти профили были?

Answer 2

Вертикальные базы данных отлично подходят для детализации и составления отчетов только для чтения.Обычно вы повторно генерируете их за ночь.Их производительность записи обычно очень низкая, однако выбор выполняется в 10-100 раз быстрее.

Типичным сценарием использования вертикальной базы данных является создание отчетов olap, когда вы создаете (ежедневный) снимок данных и затем запускаете к ним запросы.Большая часть преимуществ исходит от запросов, которые запрашивают только относительно небольшое количество полей, напримеркогда вы выбираете только несколько полей из широкой таблицы.Такой запрос запрашивает миллионы записей (например,вычисление суммы / COUNT / AVG) займет всего секунду или две.

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

Answer 3

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

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

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