Задача:
Есть товарные строки. Много. От пары миллионов штук и дальше.
Формат хранения: "товар"/"услуга" -> рубрика -> подрубрика -> ... -> наименование_товара -> параметр -> значение.

То есть как таковой товарной строки текста - нет. Всё делится на товары или услуги, в каждой рубрике может быть вложение произвольной глубины подрубрик, в том числе и "похожих". Товар - в основном, имя существительное в ед.ч. и может иметь произвольный набор параметров (в среднем 20-50шт.), в том числе и "исторического вида", меняющих свое значение со временем - например, цена. Для таких значений надо хранить "историю" и возвращать соответствующее дате выборки значение.
Множество параметров определяется наименованием товара. Значение может быть булевым, числовым, перечислимым, текстом или наименованием товара или (под)рубрики. Один товар может входить в несколько разных подрубрик, впрочем подрубрики также могут быть вложены в несколько разных верхнего уровня.

Нужны быстрые операции:
1. выборки "среза" в виде "(подрубрика) - товар - параметры - значения" по заданному набору пар "параметр"-"значение" или только по "значениям";
2. добавления параметров и их значений;
3. перенос товара из одной (под)рубрики в другую;
4. добавления рубрик, товаров и др.. в многопользовательском режиме;
5. Формирование для вывода полнотекстовой строки по заданному набору наименований товаров из его наименования и значений параметров. Здесь нужна реакция в районе 0.5сек для выборки из 25-100 позиций.
6. Требуется логирование/журналирование изменений в данных.

Как реляционное решение вижу создание нескольких таблиц: "рубрики" - nested sets, "товары", "связка товар-рубрика", "параметры", "связка наборы параметров товаров", "значения параметров"... но подозреваю, что работать оно будет медленно, хотя бы потому что основной доступ - это левые джойны по нескольким таблицам, а в ряде случаев - ещё и повторные (значение = товар).

По сути модель данных - иерархическая. Насколько могут подойти нереляционные СУБД типа mumps/Cache, D3... может кто-то может посоветовать что-то ещё?

Заранее благодарен за помощь.

Valeriu,

Пасибки, mumps видел, даже немножко осваивал... вот тоже склоняюсь к ней. Особенно, ежели учесть, что планируется достаточно сложная логика по работе с объектами хранения. Но, если честно - язык М просто пугает. Ладно, было время, когда писал в автокоде... но этож когда было!

Вопрос: если я возьму GT.M или оригинальный mumps, то можно будет, выдернув саму БД в исходниках, основные задачи решать, например на С++, обращаясь к БД как к библиотеке?

Блок А.Н.,

Есть на Мускуле, аналогично нормализованная адресно-поисковая система "Фирмы-отделы-сотрудники-телефоны-адреса-заметки-задачи"... Так вот для таблиц со средним размером в 50-150к записей, среднее время выборки составляет 2.5сек. Это на 2-х процессорном, 4-х ядерном серваке, с мозгами около 8гб и дисковой подсистемой на рейд-0 со скоростью передачи от 180Мбайт в сек... Проблема в том, что практически каждый запрос требует левого объединения (данные в таблицах не полны) от 3-х до 15-и таблиц. Это - труба. В реальности тянет не более 30-и пользователей, а далее сжирает все ресурсы сервака на 100%...

Имея такой опыт, к Мускулю особого доверия - нет.

не нашел как править свой пост.

Там, в примере, запросы поиска данных по условию, например найти фирмы в городе Н, с телефоном отдела снабжения и без заметок за последние 20 дней - ваще выполняются от 30сек... планы запросов вылизаны за полтора года эксплуатации уже "дальше некуда"...

Valeriu, платформа, конечно же *.nix. Если точнее Debian Linux - последняя устойчивая сборка. Сейчас стоит ядро 38.

Flying Dutchman,

Не нашел описания паттерна (мож плохо искал). Как догадываюсь, речь идет о чем-то типа "сущность-параметр-значение", так?
Если так, то опять же подозреваю, что иерархические БД, ваше решение обставят на порядок, хотя бы потому, что они под него "заточены", или нет?

Сложность, которую виже "невооруженным глазом":
1. Рубрика "фотокамеры" -> набор объектов "фотоаппарат" -> с параметром "объектив" -> значение "объектив-х1".
2. Подрубрика "запчасти к фотоаппаратам" -> набор объектов "объектив", в т.ч. "объектив-х1" -> с параметром "светосила" -> значение "от:2.8 до:5,6"
3. Сколько потребуется обращений к БД для ответа на вопрос: найти все товары с параметром "светосила" и значением "4.3"?
3а: Все части схемы "сущность-параметр-значение" хранятся каждое в своей общей таблице? Я так понимаю надо в таблице имен параметров найти параметр "светосила", затем разыскать все его подходящие значения и только потом смотреть к каким товарам они привязаны. Т.е. как миниум джойн на три нехилых таблицы. На самом деле больше.
3б: Для каждого вида значения, а то и параметра заводить отдельную таблицу... джойним небольшие таблички, но предварительно выясняем чего джойнить... хотя, тут возможная сильная оптимизация кешированием...
3в: ?!?

Речь, насколько понял об MS SQL SERVER, так? Позволяет ли он формировать "динамические" запросы (косвенное указание таблиц и/или полей, используемых в запросе)? Так, к примеру, Мускул позволяет только через prepare/execute, что "катастрофически" медленно, хотя бы потому, что каждый раз требуется перекомпиляция. Пробовал даже создавать хранимку, которая генерит относительно постоянные prepare - "пофиг".

Можете ли пояснить достигнутые результаты: скорость выборок/ пользователей / железо?

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

Winnipuh,

Это не задача "Склад". Хотя последний может быть частью задачи.
Задача - хранить подробные, структруированные описания товаров с возможностью перестройки описаний.
В частности, пары "параметр"-"значение" могут быть "нетипизованы", т.е. не иметь описания параметра. Например,
"Кирпич, М-125", "Кирпич М-75, желтый", "Кирпич М-100, силикатный", и т.д. В какой-то момент надо уметь создать парметр "Марка кирпича" и объединить значения "М-75", "М-100", "М-125"... логика выделения "кандидатов" - в тестовом варианте, худо-бедно есть. Вопрос как хранить сами данные.

К предыдущему примеру: требуется найти не только базовые объекты "объектив", но и все комплекты, куда он входит. В данном примере "фотокамеру", хотя в описании её параметров в прямом виде параметра "светосила" - нет.

Arhat109,

Народ, вот ещё накопал: Mongo DB - насколько может подойти, и как шустра? Вроде тоже чего-то типа key : value...

Flying DutchmanТакую задачу я решил в прошлом году при помощи SQL Server 2008. Для хранения параметров товаров был использован паттерн EAV.

Ау, автор! Ну очень интересны хоть какие-то подробности! Так решил, или просто попиарил? ;)

Flying Dutchman, Вау!

Агромное спасибо, +5 Вам в Карму.

Всё стало на свои места. Особенный респект за ссылку на описание паттерна.
Все-таки MUMPS рулит. Пошел разворачивать дистриб повторно и вникать тщательнее.

P.S. Ваше решение на реляционных таблицах - мне полностью понятно, у самого примерно такое же есть как тестовый пример, о чем здесь уже указывал. Просто не знал что это "паттерн". Оно хорошо для инет-магазина, но совершенно не канает для моей задачи. Кстати, метаданные можно хранить в сильно урезанном виде, если иметь доступ к описанию метаданных самой СУБД. Я большую часть описаний выгребал из метатаблиц Мускуля... какой там тип, кто и с кем связан...

Попробуйте в Вашей структуре завести вложенные ссылки на товары или рубрики как варианты значений параметров.
Например, как описывал во втором примере с фотокамерой.

То есть, необходимо по полученной первичной выборке рекурсивно обращаться в базу за уточнением (потому что "объект") да ещё и несколько раз по все расширяющемуся списку критериев.

Даже имея динамический SQL - ваша база - ляжет. Про Мускул с его prepare/execute - я ваще молчу.

DPH3, возможно Вы правы. К сожалению у меня практический опыт работы в БД это: Foxpro (DOS), Clipper (там же и очень немножко), Access 97 (много и долго несколько проектов в т.ч. развесистая СРМ на более 150 таблиц с журналированием, складом и бухучетом), Paradox 4.5 DOS и MySQl с 5.1, ну ещё небольшие правки готовой БД на Interbase (изучать пришлось на ходу по мере правок). Очень немножко смотрел Mumps, но больше в сторону исходников - пытался понять как движок работает с блоками данных и можно ли его "встроить куда-либо отдельно".

То есть с коммерческими базами типа Оракула или поделок от мелкософта - понятно не работал. Был когда-то приобретен платный офис с акссесс, вот с ним и игрался долгое время. :)

Задача, не коммерческая (по крайней мере пока), поэтому смотрю только в сторону бесплатных вариантов. А поскольку мои старые лицензированные 98 окошки уже давненько не поддерживаются, то перешел на Линукс.

В "общем виде" задача как раз и формулируется очень кратко "построить базу всего" :)

Если подробнее, то особенности писал выше: строим понятие "строка прайса", собирая его из отдельных параметров, начиная с наименования товара: "фотоаппарат" + "объектив" + "светосила" + "от" 2.8 + "до" 11 + "цена" + "оптовая" + "на 01/01/2001" + 1 + "рубль".

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

Архитектурно, всё просто... но пробная версия на мускуле - ложится при первом же уровне рекурсии... а их частенько поболее... 3-5 - это нормально: фотоаппарат марки "sx120is" имеет в комплектности объектив, который состоит из 11 линз, одна из которых имеет значение параметра "материал" = "пластмассовая". Это не позволяет добавить такой товар в выборку по запросу "найти все фотокамеры со стеклянными линзами". И "докопаться" до этого вывода можно только пройдя все рекурсии в описаниях. :(

Или, в версии на Аксесс решалась такая задача: Материнка имеет параметр "socket" со значением - "s-478". При выборе такой материнки, для списка допустимых процессоров надо было выбрать только те, которые имеют аналогичное значение такого же параметра. Это было в основе интерфейса для сборки компов "девочками-продавцами", которые легко надували щеки а-ля "эксперт". :)

akalend+1 за MongoDb
довольно шустрая

мы используем шардинг товаров в MySQL

Бегло ознакомился с туториалом. Прикольно. Многое решается за счет архитектуры этой СУБД. Но вот что смутило:
1. Формат хранения json: насколько это приемлемо по скорости "распознавания" в выборках?
2. Вычисления над числовыми типами. Например оценка попадания в диапазон "от..до", или приведение зависимых единиц измерений (граммы в градусы :) ) при выборках. Ну например есть типовое значение "мешок" == 50кг. Например товар "гречка в мешках, на складе 100шт." Справится ли оно "на лету" с поиском по условию "найти гречку в объеме 3тн"?

Может быть есть какое-то описание по "нагрузочным" характеристикам в реальных проектах?