сохраняющиеся динамические свойства и запрос - PullRequest
0 голосов
/ 04 марта 2010

У меня есть требование для реализации базы контактов. Эта база данных контактов является особой, так как пользователь должен иметь возможность динамически (во время выполнения) добавлять свойства, которые он / она хочет отслеживать в контакте. Некоторые из этих свойств имеют тип string, другие числа и даты. Некоторые свойства имеют предопределенные значения, другие являются свободными полями и т. Д. Пользователь хочет иметь возможность быстро и легко запрашивать такую ​​структуру. База данных должна легко обрабатывать 500 000 контактов, каждый из которых имеет около 10 свойств.

Это приводит к тому, что динамическая модель свойств имеет класс Contact с динамическими свойствами.

class Contact{

private Map<DynamicProperty, Collection<DynamicValue> values> propertiesAndValues;

//other userfull methods

}

Вопрос в том, как я могу сохранить такую ​​структуру в «некоторой базе данных» - это не обязательно должна быть СУБД, чтобы я мог легко выражать запросы, такие как

Получить все контакты, чье имя начинается с Мартина, они принадлежат компании с размером 5000 или меньше, упорядочить по времени, когда этот контакт был вставлен в базу данных, только первые 100 результатов (предоставьте нумерацию страниц), где каждый из этих сегментов соответствует динамическое свойство.

Мне нужно:

  • фильтрация - равенство, частичное равенство (больше, меньше для целых чисел, дат) и, возможно, агрегация - но в этом нет необходимости
  • сортировка
  • 1017 * пагинация *

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

contact(id serial pk,....);

dynamic_property(dp_id serial pk, ...);

--only one of the values is not empty
dynamic_property_value(dpv_id serial pk, dynamic_property_fk int, value_integer int, date_value timestamp, text_value text);

contact_properties(pav_id serial pk, contact_id_fk int, dynamic_propert_fk int);

property_and_its_value(pav_id_fk int, dpv_id int);

Рассматриваю следующие варианты:

  • хранить контакты в RDBMS и использовать Lucene для запросов - есть ли что-нибудь, что может помочь с этим?
  • Сохранение динамических свойств в виде XML и сохранение их в rdbms и использование поддержки xpath - к сожалению, для 500000 контактов это выглядит довольно медленно
  • использовать другую базу данных - Mango DB или Jackrabbit для хранения этой информации

В какую сторону вы пойдете и почему?

Ответы [ 3 ]

1 голос
/ 04 марта 2010

В Википедии есть отличная статья о Моделировании Entity-Attribute-Value , которое представляет собой метод моделирования данных для представления объектов с произвольными свойствами. Обычно он используется для клинических данных, но может также применяться к вашей ситуации.

0 голосов
/ 05 марта 2010
  1. Вы можете попробовать другие виды баз данных, такие как CouchDB, который является базой данных, ориентированной на документы, и распространяется
  2. Если вы хотите тупое решение, для своей таблицы контактов вы можете добавить около 50 столбцов, таких как STRING_COLUMN1, STRING_COLUMN2 ... до 10, DATE_COLUMN1..DATE_COLUMN10. У вас есть другой столбец ОПИСАНИЕ. Поэтому, если у строки есть имя, которое является строкой, STRING_COLUMN1 хранит значение вашего имени, а значением столбца DESCRIPTION будет «STRING_COLUMN1-NAME». В этом случае запросы могут быть немного сложнее. Я знаю, что многие пуристы смеются над этим, но я видел подобное требование, решаемое таким образом в одном из приложений:)
0 голосов
/ 04 марта 2010

Рассматривали ли вы использовать Lucene для ваших запросов?Возможно, вам не помешает просто использовать Lucene и сохранить все свои данные в индексе.Хотя я бы не рекомендовал использовать Lucene в качестве единственного хранилища персистентности.

В качестве альтернативы, вы можете использовать Lucene вместе с СУБД и использовать что-то вроде Compass .

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...