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

Не слушай, что тебе советуют всякие MongoDB и пр. Это все не ACID хранилища. Бери РСУБД и пробуй разные варианты. Могу подсказать такой вариант: возьми DB2 Express и пробуй хранить все поля в XML. Пробуй EVA на постгресе.

Вариант с ALTER-ами забудь - он загнет работающую базу раком.

> возьми DB2 Express и пробуй хранить все поля в XML

а покажи ка, как ты выведешь, например, стулья отсортированные по их материалу( дерево, металл, пластик )?

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

У тебя задача хранить документы. Для этого существуют документ-ориентированные решения - MongoDB, например.
Используй MongoDB и не слушай никого, кто советует тебе какое-нибудь старьё или написать свою БД с нуля.

> Используй MongoDB

есть какие-то вменяемые бенчмарки для него, написанные не его фанатами или авторами ес-но? на добавление/удаление/поиск и т.д.

Альтер заблочит таблицу. Если таблица довольно большая, то придется подождать :) Это все в лучшем случае. Если бд будет под нагрузкой может и сдохнуть.

В случае монго все равно придется велосипедить некий аналог ACID самому.

Да хз, не знаю что с удобством. Просто в свое время работал с db2 и часто на талкивался на похвалу работы его с xml.

> Альтер заблочит таблицу. Если таблица довольно большая, то придется подождать :)

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

Если бд будет под нагрузкой может и сдохнуть.

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

я пока нашел только:

http://openhood.com/images/charts/2010-07-24-mongo-versus-sqlite.png

но там явно автор даже не знает про то, что возможно выполнить для sqlite:

PRAGMA synchronous = 0;

после чего многие операции выполняемые «паком» будут просто реактивны, по дефолту sqlite часто флушится, что конечно влияет, например, на 1000 вставок подряд

Это все не ACID хранилища

А на кой ему ACID? У него данные в БД на windows-компьютере будут одновременно 30 пользователей модифицировать? Нет, один пользователь и то читать. Так что acid не в дугу

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

какого «админа БД» если предполагается что прога будет устанавливаться на клиентские компы с Windows XP? За каждым админа закреплять?

Просто в свое время работал с db2

А как она вообще? лучше postgres/mysql? как замена подходит?

Если ты не доверяешь бенчмаркам фанатов и авторов, то тебя ни что не переубедит. Попробуй сам провести, заодно и других недоверчивых убедишь в использовании MongoDB.

> Если ты не доверяешь бенчмаркам фанатов и авторов, то тебя ни что не переубедит

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

Попробуй сам провести, заодно и других недоверчивых убедишь в использовании MongoDB.

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

> только почему-то удаления и обновления данных нет

а нет - извиняюсь, там просто очень маленькие значения, с осью сливаются, ну так вообще замечательно, где-то на уровне sqlite с отключенным флушем

Погугли немного, найдёшь не мало сторонних.
Я сам встречал огромное число, но сейчас просто лень их снова искать.

Если кратко, БД документ-ориентированная во всех смыслах: запись не такая быстрая, но чтение очень и очень даже, даже используя MapReduce. Есть проблема с захлёбыванием БД в случае беспорядочных чтений/записей одновременно, в соотношении 1:1.

Ты как, для чего вообще интересуешься? Интересно именно применение «вообще» или для требовательных, высоконагруженных систем? Требуется ли масштабирование? Вертикальное или горизонтальное?
Вообще, MongoDB просто неописуема хороша при масштабировании. В одиночных проектах MongoDB выдаёт очень хорошие результаты, лучше SQL, но если нужно использовать БД для логгинга или иной информации, которая часто будет обновляться и её будет сильно больше, чем человек будет успевать читать, то MongoDB сильно проиграет, как и SQL.

> Ты как, для чего вообще интересуешься?

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

На вскидку, вот:
http://sergeitsar.blogspot.com/2011/01/mongodb-vs-clustrix-comparison-part-1....
http://devdazed.com/post/2737860983/mongo-vs-redis-the-increment-battle
http://www.thebitsource.com/featured-posts/introduction-to-mongodb/

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

Очень достойная БД. Очень крутой диалект SQL, хорошо документирована. Ну фичастая такая коммерческая СУБД.

Платная версия однозначно лучше и постгреса и мускуля, т.к. имеет хорошие средства обеспечения надежности (синхронная репликация, вообще фича не очень то востребованая, но там где надо, например при обработке финансовой информации, другого выбора нету). Собственно под линукс самый лучший выбор из коммерческих СУБД. MSSQL - только под форточками, Oracle слишком дорогой и сложный. А вот DB2 самое то.

Дык редис это KV тупой, не? В нем и запросов то никаких сложных не сделать.

> Альтер заблочит таблицу. Если таблица довольно большая, то придется подождать :) Это все в лучшем случае. Если бд будет под нагрузкой может и сдохнуть.

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

вот для примера:
alter table t add z text;
ALTER TABLE
Time: 1000,585 ms

1 секунда, таблица с тремя полями и миллионом строк.

Для такой задачи я бы использовал иерархическую БД. Напр., InterSystems Caché отлично подходит, или Advanced Pick (не знаю жив ли этот монстр еще).

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

К сожалению по условию задачи клиент может работать автономно. Тоесть БД на клиенте надо. Я понимаю, что это в разы все усложняет, но это не обсуждается, так дано. Но пока я и про сервер послушаю.

Про упоминания ACID.

На самом деле процесс можно разбить на 2 этапа.

1) Этап заполнение базы, он делается на отдельной базе или компьютере или как-то так. Если можно потом объединять базы, то вообще красота.

2) Этап работы с базой. Тут только чтение. И много много поиска по разным атрибутам и совокупностям.

Поэтому ACID тут не главное

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

Ну, я имею в виду больше не банки которые «могут заплатить», а всякие наши конторы «Шарашмонтаж»™, которые жмутся на бабки и поэтому тулят себя всякие убожества вроде mysql. при этом все равно у них нет серваков с больше чем 2Гб памяти и 4 сокетами для процессоров, т.е. спокойно в требования db2-c-express укладываются

ipdcuro.tcavs.ru

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

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

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

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

А когда вам нужно откатить транзакцию вы устраиваете «инкрементальный бэкап»? Сурово.

> А когда вам нужно откатить транзакцию вы устраиваете «инкрементальный бэкап»? Сурово.

а вы собираетесь запихивать ALTER TABLE с другими операциями в одну транзакцию? зачем?

> какого «админа БД» если предполагается что прога будет устанавливаться на клиентские компы с Windows XP? За каждым админа закреплять?

А. Ну тогда действительно можно всё что угодно делать. Правда этото бедлам нужно будет как-то синхронизировать. Или синхронизировать не надо? У заказчика не торговая сеть а горстка убогих лавок никак друг с другом не связанных?

> а вы собираетесь запихивать ALTER TABLE с другими операциями в одну транзакцию? зачем?

Я пока ещё ничего не собираюсь. Я лишь обозначил несколько ограничений вашего решения.

Существующие nosql-решения это уже умеют, не? Ты хочешь придумать свой nosql с блекджеком? Или гуй для реляционки, который будет давать бухгалтер-френдли изменение схемы, типа 1С? =)

> Я пока ещё ничего не собираюсь. Я лишь обозначил несколько ограничений вашего решения.

PostgreSQL поддерживает практически все команды DDL внутри транзакции и может их отменять.

Круто. В оракле такого нет.

> Круто. В оракле такого нет.

позор им, даже sqlite умеет откатывать ALTER/DROP TABLE :) хотя там есть свои ограничения

А в халявной версии дб2 все равно нет средств репликации. Так что я бы в таком случае смотрел бы на постгрес. Вот мускуль новый, 5.5 который, вроде тоже очень многообещающий. Никто не смотрел на него?