Схема базы данных для отслеживания случайных настроек на сайте для маркетинга - PullRequest
Новая
       35

Схема базы данных для отслеживания случайных настроек на сайте для маркетинга

2 голосов
/ 01 октября 2008

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

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

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

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

Есть предложения?

Ответы [ 2 ]

3 голосов
/ 09 марта 2009

Хорошо, это очень сложно. Я хочу сказать, что причина в том, что вы просите о двух вещах:

  • упрощенная схема репозитория, так что вы можете хранить различные данные и динамически изменять то, что будет сохранено позже
  • исправлена ​​схема базы данных, позволяющая эффективно запрашивать данные

Решение будет компромиссным. Вы должны это понять.

Предположим, у вас есть таблица User: 

+----------------
| User
+----------------
| UserId (PK)
| ...
+----------------

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

+----------------
| CustomProperty
+----------------
| PropId (PK)
| UserId (FK)
| Data of type memo/binary/...
+----------------

Преимущество заключается в том, что вы (бизнес-логика) владеете схемой. Это одновременно недостаток данного решения. Еще одним ОГРОМНЫМ недостатком является то, что запрос / фильтрация будет ЧРЕЗВЫЧАЙНО сложным и МЕДЛЕННЫМ!

2) Таблица на имущество Другим решением является создание специальной таблицы для каждого свойства (домашней страницы и т. Д.). Эта таблица будет содержать значение для каждого пользователя (отношение FK к таблице User). 

+----------------
| HomePage
+----------------
| HomePageId (PK)
| UserId (FK)
| Value of type string
+----------------

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

3) Таблица CustomProperty В этом решении у вас есть одна таблица, содержащая все пользовательские свойства. 

+----------------
| CustomPropertyEnum
+----------------
| PropertyId (PK)
| Name of type string
+----------------

+----------------
| CustomProperty
+----------------
| PropId (PK)
| PropertyId (FK)
| UserId (FK)
| Value of type string
+----------------

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

Выбери для себя. Я бы выбрал от 2 до 3 в зависимости от вашей рабочей нагрузки (скорее всего 3, потому что это проще).

1 голос
/ 23 июля 2014

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

...