Стоимость и трудозатраты.

делаешь поле properties для всех продуктов и в нем сериализованно хранишь все что тебе нужно. в чем проблема то?

> делаешь поле properties для всех продуктов и в нем сериализованно хранишь все что тебе нужно

конечно - ведь БД никогда не используют для поиска данных

Сложность заключается в том, что заранее неизвестно что за товары там будут.

MongoDB, например, не имеет никакой схемы.

Сколько в деньгах, времени будет стоить такая БД?

в смысле заполнить?

о, ну тогда отдельная табличка вида id|name|value в которой и лежат свойства.

man Semantic Web, OWL, онтологии http://semanticweb.com/relational-database-and-the-semantic-web_b16083

Кстати ощущение такое что месяц назад уже кто-то спрашивал про такую же базу

demmsnt> То есть надо дать возможность определять поля по ходу работы базы.

По-сути это дать возможность создавать таблицы. Ничего сверхъестественного.

> Сколько в деньгах, времени будет стоить такая БД?

это в смысле такое предложение поработать? тогда с ТЗ не все понятно.

Сколько в деньгах, времени будет стоить такая БД?

90% ЛОРа сделает это за неделю и 20000 руб. Ведь на руби а тем более на RoR такое делается пяткой левой ноги

> По-сути это дать возможность создавать таблицы. Ничего сверхъестественного.

На самом деле, просто созданием таблиц не обойдешься - запросы нужно будет переписывать.

Я за предложение isden - у этой техники даже есть свое название в РСУБД: http://en.wikipedia.org/wiki/Entity-attribute-value_model

>делаешь поле properties для всех продуктов и в нем сериализованно хранишь все что тебе нужно. в чем проблема то?

Поиск ручками? Хочется все свойства СУБД использовать.

>в смысле заполнить?

Нет разработка...

>На самом деле, просто созданием таблиц не обойдешься - запросы нужно будет переписывать.

Именно. Только вот создат такое и работать с ним не очень удобно. Да и тут есть ограничение Клиент хочет иметь локальных Windows клиентов у которых данные локально. Я провожу оценку стоимости работ

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

мышью 15 минут http://v8.1c.ru/overview/CharacteristicReg.htm

Я за предложение isden - у этой техники даже есть свое название в РСУБД: http://en.wikipedia.org/wiki/Entity-attribute-value_model

http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=220850&msg=1964295

делаешь еще одну таблицу со свойствами

количество их и конкретно какие они будут можешь или к конкретной номенклатуре привязать или к ассортиментному классификатору

в основной табличке номенклатур название генеришь из полей свойств

в гипермаркете реально используются 70 тыс номенклатур в базе 400 тыс зачем там миллион то?

> На самом деле, просто созданием таблиц не обойдешься - запросы нужно будет переписывать.

автоматом генерировать

Я за предложение isden - у этой техники даже есть свое название в РСУБД

вообще-то это не совсем-то - это разреженная матрица, тут же данные атрибутов есть для всех записей поля, ну и если речь идет о товарах - то тут банальная задача - сортировка по атрибуту, или поиск, для таблицы - это простой запрос по индексированному полю, для атрибутов:

а) при сериализации - парсер + ручная обработка всех записей;
б) при дополнительной таблице с атрибутами - дублирование данных и необходимость введения ключей.

>> На самом деле, просто созданием таблиц не обойдешься - запросы нужно будет переписывать.

автоматом генерировать

Теоретики такие теоретики.

Я за предложение isden - у этой техники даже есть свое название в РСУБД

вообще-то это не совсем-то

А по-моему, именно то.

тут же данные атрибутов есть для всех записей поля

Ы? Тут набор атрибутов не фиксирован, и наверняка должен меняться пользователем.

>Если это будет скажем автомобиль, то у него свои поля. То есть надо дать возможность определять поля по ходу работы базы.

Да тут всё просто.

Если у тебя РСУБД, то три варианта:

1) EAV, выше уже написали. Самый надёжный и проверенный вариант, недостатков хватает. Таблицы разрастутся до огромных размеров, запросы с JOIN-ами итд. Интерфейс и запросогенератор к ней писать не так и сложно, но требуются усилия и знания.

2) Хранить данные в xml, например. Т.е. поле «свойства» будет держать в себе строку xml с свойствми «<prop1>val1</prop1><prop2>val2</prop2>». Тут всё проще в плане работы с ней - нет join-ов и кучи таблиц. Минусы - проблемы с поиском, многие БД умеют искать по xml, но производительность всё равно хуже, чем при честных SELECT-ах.

3) Изменение таблиц на лету. Если надо делать свойство - добавляется колонка. Надо сделать новый тип товара - таблица. Самый хитрый, костыльный и кривой путь, но им можно пользоваться, если ты _уверен_, что изменять структуру БД будут раз в год и совсем немного. При этом очень сильно замучаешься с реализацией. Не используй его.

Как вариант - можно взять не РСУБД. Вариантов множество. Из проблем - надо действительно хорошо всё понимать, иначе оно нормально работать не будет. Если не разбираешься, то лучше не лезь.

> Теоретики такие теоретики.

ура, меня впервые обвинили в том, что я теоретик

А по-моему, именно то.

ваше мнение очень ценно

Ы? Тут набор атрибутов не фиксирован, и наверняка должен меняться пользователем.

протрите очки, я написал - «данные атрибутов», набор полей с атрибутами __для полей__, которые умеют нормальные СУБД на уровне движка, в данном случае и гораздо универсальней и удобней

Минусы - проблемы с поиском, многие БД умеют искать по xml, но производительность всё равно хуже, чем при честных SELECT-ах.

http://exist.sourceforge.net/
http://sedna.sourceforge.net
http://nativexmldatabase.com/2011/01/21/namevalue-pairs-a-pretty-bad-idea-in-...

>> А по-моему, именно то.

ваше мнение очень ценно

Как и твое.

А есть тесты, где сравнивается на крупной базе xml и EAV? А то на словах xml с xpath и правда выглядят красиво, но как оно при нагрузке?

>> ваше мнение очень ценно

Как и твое.

приятно конечно, но вы явно просто из вежливости это написали, мне до вас далеко

>мышью 15 минут http://v8.1c.ru/overview/CharacteristicReg.htm

Не, не это не пойдет. Во первых я не говорю о правке структуры БД. Это вообще говоря операция опасная и требующая перестройки внутренних данных самой БД. Действительно я тоже представляю себе схему в которой есть таблица типов. Есть таблица аттрибутов типов. И есть таблицы в которых указан ID объекта и его тип И таблицы в которых хранятся уже значения конкретного атрибута конкретного объекта.

Вот только запросы по такому крошеву у меня вызывают шевеление волос на спине.

И еще 1С и 1 млн объектов?

Я сейчас написал для бенчмарка прототип такой БД с сториджем в беркли ДБ. На 1 млн записей поиск всех объектов удовлетворяющих условию 18 секунд. Поиск первого (там цикл с перебором) 0.002 секунды.

Но я боюсь подвязываться на работу которую не до конца могу оценить. Мне кажется тот-же Постгрес или Интербейз на обычной виндовом компе такие запросы в таком крошеве будет делать часы.

>Ы? Тут набор атрибутов не фиксирован, и наверняка должен меняться пользователем.

Да Именно. Например мы никогда не торговали насосами, а тут закупили их и у них есть характеристика - развиваемое давление в атмосферах.

Зачем миллион? У нас очень много товаров. Очень. Может и 10 миллионов будет.

> Да Именно. Например мы никогда не торговали насосами, а тут закупили их и у них есть характеристика - развиваемое давление в атмосферах.

еще один плюс для полей - поле можно задать любого типа: блоб, картинка, double, строка etc., для фиксированной таблицы с атрибутами это будет отдельный геморрой, да и на поле можно добавлять какие угодно атрибуты - комментарий, подпись для пользователя, формат вывода и т.д., и хранится это будет не в отдельной пользовательской таблице, а самой СУБД, т.е. не надо будет делать руками лишнюю работу

Руки за такое отрывать.

Есть таблица аттрибутов типов. И есть таблицы в которых указан ID объекта и его тип И таблицы в которых хранятся уже значения конкретного атрибута конкретного объекта

на том же sql.ru over 9000 холиваров на тему EAV vs все остальное. Серебряной пули они вроде не предложили

> Руки за такое отрывать.

руки надо отрывать за нагромождения всякого рода конструкций и связей на ровном месте, из-за чего все потом рассыпается и тормозит, а при росте еще и превращается в монструозную конструкцию с десятками подпорок

А обязательно нужна SQL БД? Чем не устраивают всякие документ-ориентированные не-sql варианты?

поясняю как это могло бы выглядеть:

Данные в БД:

[Схема "Товары"]
   [Таблица "Насосы"]
      [Поле "Наименование"]
      [Поле "Изображение"]
      [Поле "Модель"]
   [/Таблица "Насосы"]
   [Таблица "Мебель"]
      [Поле "Наименование"]
      [Поле "Изображение"]
      [Поле "Производитель"]
   [/Таблица "Насосы"]
[/Схема "Товары"]

и все, вроде как смотрится очевидно и легко может быть потом конвертировано

Выполняемые действия:

- получить список категорий товаров - SHOW TABLES
- добавить/удалить новую категорию - CREATE/DROP TABLE
- получить список атрибутов товара - SHOW COLUMNS FROM TABLE
- добавить/удалить атрибут - ALTER TABLE 
- получить список товаров - SELECT * FROM [таблица] ORDER BY [атрибут]
- добавить/удалить товар - INSERT/DELETE

тоже вроде как ничего сложного, и легко реализуется в коде, как бы всем критикам предлагается показать как будет выглядеть их БД и реализованы данные действия, мне ж тоже интересно посмотреть на правильное решение

> Во первых я не говорю о правке структуры БД.

в справочник добавляется всего один атрибут.

есть таблица типов. Есть таблица аттрибутов типов

там всего одна таблица, в которой ссылка на Объект («Кисть вятка»), ссылка на таблицу/типданных Свойство («Список размеров» или «Поставщик» или просто «Число») и собственно Значение (содержимое которого интерпретирцется в зависимости от свойства).

запрашивается там влёгкую, оно даже экранную форму сгенерит.

напр в http://www.forum.mista.ru/topic.php?id=482881 типовой запрос в 4 строки

И еще 1С и 1 млн объектов?

отработает быстро, если не делать большой вложенности аля Товар.Поставщик.Договор.НаДуту.блабла в условиях запроса что так любят делать неопытные 1Сники

[offtopic] Расскажи, что это за 1 млн. позиций?

Только что посмотрел на любимом http://books.ru: 181152 товаров. [/offtopic]

Расскажи, что это за 1 млн. позиций?

Amazon.рф же

достаточно на каждую новую поставку заводить новую номенклатурную позицию )))
аптечная сеть в городе на 40к населения сделает это за пару лет

>руки надо отрывать за нагромождения всякого рода конструкций и связей на ровном месте, из-за чего все потом рассыпается и тормозит, а при росте еще и превращается в монструозную конструкцию с десятками подпорок

Так потому и спрашиваю. Я просто не видел рабочй БД с такими объемами

>А обязательно нужна SQL БД? Чем не устраивают всякие документ-ориентированные не-sql варианты?

Не обязательно. Но есть крутое ограничение связанное с тем, что на компьютере (Windows да да) клиента это должно запускаться в 1 клик в идеале без установки или хотяб тупой сетап.

Я лично на сервере какойнибудь токио кабинет пригядел. А для клиента написал самопал на беркли. Но я ведь не велосипедист. Вот и спрашиваю. Пока я хочу слышать все варианты.

>отработает быстро, если не делать большой вложенности аля Товар.Поставщик.Договор.НаДуту.блабла в условиях запроса что так любят делать неопытные 1Сники

Это странно я слышал, что 1С медлителен. Ну ладно. Я просто не 1С пейсатель и не думаю что буду. Другой вариант а такое самому тяжко написать?

> Это странно я слышал, что 1С медлителен

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

Другой вариант а такое самому тяжко написать?

мой скромный опыт подсказывает что в любом случае поддержка превратится в ад

>Но есть крутое ограничение связанное с тем, что на компьютере (Windows да да) клиента это должно запускаться в 1 клик в идеале без установки или хотяб тупой сетап.

Сетап можно написать самому, если очень хочется.

Я лично на сервере какойнибудь токио кабинет пригядел. А для клиента написал самопал на беркли. Но я ведь не велосипедист. Вот и спрашиваю. Пока я хочу слышать все варианты.

Так система будет серверная, или на клиенте тоже БД? На сервере не должно быть проблем с установкой любой БД.

> - добавить/удалить новую категорию - CREATE/DROP TABLE

- добавить/удалить атрибут - ALTER TABLE

Мощно. Осталось только найти СУБД, которая умеет откатывать создание, изменение и удаление таблиц и админа БД, который согласится выдать права на эти операции кому-то, кроме себя.

А почему никто не говорит про CouchDB или MongoDB?

Кстати, для таки вещей подошел бы LDAP, но тогда придется писать много схем к нему, что не очень эффективно и противоречит идеологии.

>- добавить/удалить атрибут - ALTER TABLE

А ты в курсе, что на крупных базах ALTER TABLE может отрабатывать очень долго? А пользователи в это время на обязательный перерыв выйдут?

Но есть крутое ограничение связанное с тем, что на компьютере (Windows да да) клиента это должно запускаться в 1 клик в идеале без установки или хотяб тупой сетап.

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

Я бы смотрел в сторону http://wiki.apache.org/cassandra/DataModel или http://www.mongodb.org/display/DOCS/Schema+Design.

Как вариант можно загнать все похожее на EAV-атрибуты в http://wiki.apache.org/lucene-java/FrontPage

Уже предложенная кем-то идея заюзать онтологии - нужно, помогает правильно посмотреть на задачу, но не решает вопрос с хранилищем.

Стоит столько сколько могут заплатить..., в какой форме, и в каком виде нужен результат. Что-то можно сделать за месяц, для продакшн-юзабельности потребуется 3-6.

Кто будет платить PM'у и QA, кто пишет доки и производит приёмку? Если все делает один чел (с уходом которого все с начала), то наверное от 200 рублей. Если по продуктовому процессу, то наверное от 1000 рублей.

> А ты в курсе, что на крупных базах ALTER TABLE может отрабатывать очень долго? А пользователи в это время на обязательный перерыв выйдут?

разве что с кривыми СУБД или массой линков - операция эта на самом деле очень простая, единственно что может тормозить ее - связи, которых тут нет

> Мощно. Осталось только найти СУБД, которая умеет откатывать создание, изменение и удаление таблиц

инкрементальный бэкап, это если нужно откатываться по дате

и админа БД, который согласится выдать права на эти операции кому-то, кроме себя.

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