Дизайн базы данных для исторического агрегирования - PullRequest
Новая
       14

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

2 голосов
/ 20 декабря 2011

Я пытаюсь решить, какой дизайн хранилища данных будет лучшим.Он будет использоваться для поиска исторических средних цен различных товаров в разные периоды времени с помощью поиска по типу Google.Например, какова была средняя цена акции А в этом месяце 3, 6 и 1 год назад?Проблема в том, что у меня нет имени элемента, который я могу использовать, у меня есть поля описания об элементе.

Это означает, что я не могу объединять элементы в представления, поскольку один и тот же элемент может быть перечислен 20 раз каждый с разными описаниями, поэтому я должен на лету выполнить полнотекстовый поиск в поле описания, захватитьцена, где дата вставки <3 месяца назад.Затем найдите среднее значение этого.</p>

Так что мой лучший выбор - иметь все в одном столе, например: 

            MAIN
----------------------------
ID | Description | Price | Date

или много столов: 

    DESCRIPTION
------------------
ID | Description | 


   PRICE
---------
ID | PRICE

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

Ответы [ 2 ]

0 голосов
/ 22 декабря 2011

Как предположил Джоэл, вариант 2, вероятно, предоставит вам больше гибкости. Я бы предложил включить в каждую таблицу дополнительные даты для медленного изменения размеров. Описания и другие атрибуты данного предмета могут со временем меняться.

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

    DESCRIPTION
---------------------------------------------------
ID | Description | Effective Date | Expiration Date


   PRICE
-----------------------------------------------------------
ID | Location ID | Price | Effective Date | Expiration Date
0 голосов
/ 20 декабря 2011

Я бы сказал вариант 2 ... сохранить детали верхнего уровня в таблице "description". И исторические данные в таблице «цена» (хотя и с добавленным полем «Дата» для захвата временного значения)

...