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

Question

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

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

Answer 1

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

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

Я бы использовал «горизонтальную» таблицу, а не систему значений атрибута сущности (вертикальная таблица). Вертикальные столы имеют тенденцию быть медленными. Они не могут быть правильно проиндексированы и сбивают с толку оптимизатора запросов.

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

Answer 2

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

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

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

Answer 3

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

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

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