Поговорите с таблицами в стиле хранилища данных с ActiveRecord? - PullRequest
5 голосов
/ 03 августа 2009

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

Кроме того, я только что прочитал главы 2 (Разработка красивых API) и 3 (Освоение динамического инструментария) Ruby Best Practices .

Теперь я пытаюсь выяснить, как лучше спроектировать часть, извлекающую факты ...

Скажем, у меня есть следующие размеры (существующие модели в приложении):

  • Продукт (содержит средства)
  • Фонд
  • Мера (например, общее удержание, среднее удержание, среднее воздействие)

... и старый добрый универсальный Факт:

  • Факт (дата, значение плюс столбец внешнего ключа NULLable для каждого из моих измерений)

Некоторые аспекты, по которым я был бы признателен за советы:

  • Что может составлять гибкий интерфейс поиска?
  • Что произойдет, если у меня есть факты с обоими значениями NULL (т.е. все или безразлично) и NOT NULL (конкретные) для измерения? Псевдо-значение типа :all? Или должно применяться какое-то соглашение?
  • Как выбрать только подмножество значений измерений? Или исключить подмножество? : только и: исключить?
  • Кто-нибудь имел опыт создания named_scope с этим? Существует очевидная привлекательность возможности связать по одному для каждого интересующего измерения, но становится ли слишком неуклюжим, если мы доберемся до 7 или 8 измерений?

(я знаю, что плагин acts_as_fact считается существующим в той или иной форме (по крайней мере, на RailsConf 2006 был небольшой гудок), но я не смог найти ни кода, ни описания того, как он мог работать .)

Версии: Rails, ActiveRecord 2.1.2, Oracle Enhanced Adapter 1.2.0

РЕДАКТИРОВАТЬ: Я посмотрел на ActiveWarehouse и некоторые оговорки: - в основном филиале не было коммитов с ноября-08 и нет активности вообще с января-09; - учебник датируется 2006 годом, признан устаревшим, и 404 года для меня; - кажется, что он хочет уйти от ActiveRecord - большая часть моего приложения останется в AR, и я думаю, что в настоящее время я хочу решение AR.

Так что я буду держаться подальше от этого, спасибо!

Ответы [ 4 ]

2 голосов
/ 03 августа 2009

Что произойдет, если у меня есть факты с обоими NULL (т. Е. Все или все равно) и НЕ NULL (конкретные) значения для измерение? Псевдо-значение как: все? Или какое-то соглашение должно применяться?

NULL будет ставкой, вводящей в заблуждение, потому что это означает отсутствие ассоциации. Я бы использовал значение типа -1 (если это целое число foreign_key только со значениями> 0).

Как выбрать только подмножество Значения размеров? Или исключить подмножество?

with_scope()

вы также можете переписать функцию поиска

   def self.find(*args)
    if  anything
      with_scope(a_scope) do
         result = super *args
      end
    else
      result = super *args
    end
   end

   def self.a_scope
    {:find => { :conditions => ["person_id  = ?", me] , :readonly => true}}
   end

Кто-нибудь имел опыт работы с создание named_scopes для работы с этот? Там очевидная привлекательность быть в состоянии связать один для каждого измерение интереса, но получается ли слишком неуклюже, если мы доберемся до 7 или 8 размеры?

У нас есть база данных olap с 4 измерениями, и она прекрасно работает. Я думаю, что если вы реализуете некоторые пользовательские методы для active_record, вам будет весело с вашим приложением.

Я также нашел это: http://github.com/aeden/activewarehouse/tree/master

1 голос
/ 04 августа 2009

Я пытался использовать ActiveWarehouse некоторое время назад, прежде чем я начал заниматься другими вещами, поэтому я не могу сказать вам, насколько хорошо это работает, но это что-то, что нужно добавить в ваш список, чтобы проверить , Он имеет генераторы для фактов, измерений и кубов, а также инструментарий ETL.

1 голос
/ 04 августа 2009

есть еще один, который я не использовал, но выглядит хорошо:

http://github.com/wvanbergen/active_olap/tree/master

http://techblog.floorplanner.com/2008/07/29/active-olap-released/


и это для SOLR, который я нашел в Google

http://code.google.com/p/kettle-solr-plugin/

0 голосов
/ 30 сентября 2009

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

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

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

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

Когда я его построю, я вернусь с более подробной информацией ...

...