Из плюсов - по выбранным аттрибутам, если у них тип - число, можно
вести быстрый поиск на вхождение в диапазон.
У меня разница в том, что существует около двадцатка категорий
продуктов, между которыми типы аттрибутов почти не пересекаются,
поэтому MtM я не стал делать, и значения аттрибутов тоже нормализовать
не стал. Имеется следующий плюс.
Решается DataMapper'ом примерно так, вечером как раз пробовать буду:
query = Product.all(:name.like => params[name])
params[:feature].each do |feature_type_id, value|
ft = FeatureType.get feature_type_id
if ft.value_type == :digital
query = query and Feature.all(:feature_type => ft, :digital_value
=> value).product
elsif ft.value_type == :string
...
end
end
On Jul 27, 2:44 am, Max Lapshin <max.laps...@gmail.com> wrote:
> Насколько я понимаю, речь идет о чем-то типа того, что я делал ещё для
> профотоса: есть фотоаппарат/объектив и т.п., у них есть по две сотни
> параметров (группирующихся), которые ещё и разнотипные:
> строка/число/словарь.
>
> Пусть Серега расскажет, оказалась ли схема жизнеспособной, но для меня
> работало так:
>
> таблица devices -- тут хранятся экземпляры устройств. Разделение по
> полю kind, потому что для товаров STI был лишним -- никакого разделения
> логики нет.
> таблица attributes -- тут хранятся типы свойств. Например: title =
> "Диафрагма мин.", name = "aperture_min", prop_type = "n"
> В ней как раз писался тип значения: число, строка и т.п.
> таблица attribute_dictionaries: attribute_id, attribute_title, attribute_value
>
> таблица device_attributes: attribute_id, device_id, value_s (string),
> value_n(numeric), value_d(attribute_dictionary_id) и сюда же
> кешировалось поле prop_type
> Обратите внимание на то, что в этой таблице хранится три разных value,
> интерпретация которых зависит от значения в attributes.
> Это хорошо, правильно, и работает, потому что на value_n можно
> наложить индекс. Хранить всё в text -- очень, очень, очень плохая идея.
>
> Дальше понятно: вытаскиваем device, тянем его device_attributes,
> джойним с attributes и по необходимости attribute_dictionaries
>
> Сложно? Соразмерно сложности предметной области. Это всё оказалось
> очень удобно в перспективе, когда можно было интерпретатором
> специального языка вида:
>
> aperture_min:[2,6]
> kind: camera
> price:[15000,23000]
>
> выбрать пристойные мыльницы с хорошим объективом.
>
> Такая конструкция чрезвычайно удобна для редактирования и поиска. В
> несравненное количество раз удобнее, чем хранение JSON/YAML. Говорят,
> что так же удобно в MSSQL можно положить XML, заботать XPATH в
> реализации MS и получить то же самое. Но зачем, если это ровно та
> задача, под которую создавался SQL?
>
> Есть одна проблема: вытаскивание этих данных мучительно. Я её решил не
> самым лучшим образом: создал постгресовые типы и одним большим
> апдейтом заливал все данные одного девайса в поле cached_attributes в
> постгресовом представлении. Это было очень удобно в том смысле, что
> один UPDATE где-то на 5-10 секунд заливал кеш всей базы данных в поля.
> После этого парсил хранящееся представление и вытаскивал в нужном виде
> поле attributes, пригодное для рендеринга в шаблоне.
>
> Это решение плохо тем, что ни рельсы, ни datamapper, ни какой ещё
> другой ORM на руби, оказались совершенно бессильны перед кастомным
> типом данных в БД. В итоге засунуть этот кеш в тесты оказалось
> невозможно.
> Наверное, будет работать существенно более ресурсоёмкий способ с
> генерацией такого кеша на уровне руби: когда поправилось поле,
> аггрегируем все поля и заливаем их в один большой блоб. Но по этому
> блобу искать не получится, для этого есть прекрасно работающая таблица
> devise_attributes
>
> После всего этого я попытался залить такую структуру в mongodb.
> Собственно говоря, получил ровно тот же JSON-кеш, но без возможности
> поиска и выборки.
--
--
Данное сообщение отправлено Вам, так как Вы являетесь подписчиком группы "RubyOnRails to russian" на группах Google.
FAQ группы находится по адресу: http://ru.wikibooks.org/wiki/RubyFAQ
Для того, чтобы отправить сообщение в эту группу, пошлите его по адресу
ror2ru@googlegroups.com
Чтобы отменить подписку на эту группу, отправьте сообщение по адресу: ror2ru-unsubscribe@googlegroups.com
Дополнительные варианты находятся на странице группы http://groups.google.com/group/ror2ru?hl=ru
Комментариев нет:
Отправить комментарий