Re: Как хранить разнотипные данные?

Насколько я понимаю, речь идет о чем-то типа того, что я делал ещё для
профотоса: есть фотоаппарат/объектив и т.п., у них есть по две сотни
параметров (группирующихся), которые ещё и разнотипные:
строка/число/словарь.

Пусть Серега расскажет, оказалась ли схема жизнеспособной, но для меня
работало так:

таблица 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