2009-12-02 6 views
6

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

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

ответ

8

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

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

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

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

+0

Я использую sql server 2008. и пользователю не разрешено добавлять новые свойства. – Radhi

0

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

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

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

3

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

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

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