Оптимальное хранилище данных - тройное хранилище/реляционная база данных/другое?

Я создаю веб-приложение с PHP на сервере Apache.

Приложение содержит множество необязательных данных о лицах. В зависимости от категории человека (один человек может быть во многих категориях), они могут указать данные или нет: домашний адрес (== 5 полей для улицы, города, страны, ...), рабочий адрес ( снова 5 полей), возраст, номер телефона, .... Конечно, приложение также хранит некоторые дополнительные данные (создано, последнее обновление, имя пользователя, пароль, уровень пользователя, ...).

Текущая/устаревшая версия приложения имеет 86 полей в таблице «пользователи» и (в зависимости от категории человека) дополнена дополнительной таблицей с еще 23 полями (связь 1-1).

Все это хранится в базе данных Postgresql.

Мне интересно, лучший ли это способ обработки данных такого типа. Большинство записей имеют (много) пустых полей, что делает базу данных больше, а запросы медленнее. Стоит ли искать другое решение, такое как Triple Store, или я слишком сильно беспокоюсь об этом и должен ли я просто сохранить текущую настройку? Кажется странным и неудобным просто добавлять поля в таблицу для каждой новой цели сайта. С другой стороны, у меня сложилось впечатление, что тройные магазины еще не так распространены. Любые указатели или предложения, как подойти к этому?

Я читал «Программирование семантической сети» Тоби Сегарана и других, но из этой книги у меня сложилось впечатление, что основным преимуществом тройных хранилищ и RDF является обмен информацией через сеть (что не является целью моего приложения). )


php database triplestore
person user410932    schedule 07.09.2011    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Большинство записей имеют (много) пустых полей

Это означает, что ваши данные далеки от нормализации.

Текущая/устаревшая версия приложения имеет 86 полей в таблице «пользователи» и (в зависимости от категории человека) дополнена дополнительной таблицей с еще 23 полями (связь 1-1).

Действительно, да, это очень далеко от нормализации.

Если у вас есть веская причина отойти от того места, где вы сейчас находитесь, то первым шагом будет гораздо лучшая структуризация ваших данных. Даже если вы решите перейти на другой тип СУБД, например. noSQL или объектная БД.

Это не только сэкономит место в вашей СУБД, но и ускорит извлечение данных и уменьшит объем кода, который вам нужно написать (например, вы можете повторно использовать тот же код для поддержки домашнего адреса, что и для поддержки рабочего адреса, если у вас есть одну таблицу для «адреса» с полем, помечающим тип адреса).

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

person symcbean    schedule 07.09.2011
comment
интересно, правы ли вы, что это не нормализовано. Я храню всевозможные данные о человеке (цвет глаз, цвет волос, зарплата, уровень в организации, has_badge, has_companycar, has_... и т. д.). да, вы можете поместить все элементы, которые можно иметь в таблице, и поместить промежуточную таблицу между связыванием пользователя и атрибутов, но я не уверен, что это ускорит запросы (наоборот). - person user410932; 09.09.2011
comment
и хотя я согласен с тем, что наличие атрибутов таблицы для хранения необязательных данных, похоже, движется в направлении тройного хранилища... (где все поля хранятся как атрибуты или объекты, как они это называют) - person user410932; 09.09.2011