MasterZivСоответственно, либо у вас есть блокировки, либо у вас есть wormhole-ы и
несериализуемые транзакции. И то, и другое, в общем, не обязательно плохо.

Мне тут кто-то подсказывал, что применяемый там механизм называется оптимистической блокировкой.

MasterZiv> Второй момент, касается задач, на которые ориентирована СУБД. Сейчас в мире
> приходит понимание того, что классический реляционный подход не всегда идет на
> пользу решаемых задач, посему начали придумывать всяческие отхождения от
> стандарта: in-memory, с поколоночным хранением, вообще объектно-ориентированные.
> Раз они существуют, значит это кому-нибудь нужно?

Вы видимо слабо понимаете, о чём говорите. Ни одно из вышеперечисленных вами
"нововведений" не противоречит ни стандратру (ANSI SQL), ни реляционному подходу.

Ээээ... вы сейчас про БД Викты или про перечисленные мною примеры?
Если про Викту - отсутствие жестко заданной структуры таблиц по-моему никак не вписывается в реляционную модель.
Если про примеры - нарушение принципа ACID в in-memory - прямое нарушение стандарта ANSI SQL, а объектно-ориентированная БД вообще к реляционной отношения не имеет... Разве нет? Ну, про поколоночную... соглашусь пожалуй, - только структура хранения самих данных отличается.

MasterZiv> клиент-сервер. Но есть ощущение, что она гибче, и легче позволяет решать
> некоторые задачи. В основном учетные: когда у вас не много пользователей (30
> бухгалтеров - это и правда много) и при этом довольно много всевозможных сложных
> рассчетов. А структуры данных приходится строить такие, что черт ногу сломит.
> Вот где-то здесь она и начинает играть, по моим ощущениям.

А думаете обычные реляционные СУБД такие задачи не решают ?
Или плохо их решают ?

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

> К примеру, насколько я понимаю ситуацию, за счет того, что у них нет жесткого
> описания структуры атрибутов в таблице, они создают одну таблицу, к примеру, для
> каталога товаров, и пихают в нее все что только душе заблогарассудится: колбаса,
> значит колбаса, автомобиль, значит автомобиль. И никих вам EAV и наследуемых
> таблиц... В итоге, максимальное кол-во таблиц которое им приходилось решать для
> конкретной учетной задачи - 200.

Оптимизировать количество таблиц в реляционной СУБД -- это конечно достоойнейшая
задача. (это сарказм, если ещё кто не понял).

Обычно гораздо меньше. В других подобных
> системах, как я понимаю, они считаются тысячами.

Ну и что в этом плохого ? Кол-во таблиц вообще-то диктуется тем, какие данные
обрабатываются и какие предметные области охватываются деятельностью данной БД.
Чем шире охват, тем больше таблиц. Ничего плохого в том, что их много, нет.
У нас в БД их напр. более 2 тысяч.

Ну вот смотрите что получается: у вас много таблиц, соответственно, много связей между ними. Соответственно - чтобы вытянуть нужные вам данные вам довольно часто приходится делать сложные запросы, содержащие кучу джойнов между таблицами, а то и вложенных запросов. Это все усложняет обработку. Если все напихано в одну таблицу - по идее - структура упрощается, а соответственно - и запросы тоже. Разве нет?
Второй момент: если вы не используете грязное чтение, то при формировании сложных запросов вы начинаете блокировать работу тех, кто хочет записать данные, которые вы читаете, и влетаете в проблему блокировок в итоге (я сейчас не deadlock имею в виду, а просто тормоза). Раве нет?
Чем сложнее создаваемая структура и чем более навороченные отчеты приходится мутить - тем актуальнее проблема, - даже если объем данных в общем-то не очень большой. Где-то так.

MasterZivOn 29.08.2011 4:31, .ЛП wrote:
> что подаётся как архитектурные особенности и плюсы - вызывает тихое шевеление
> волос на голове.

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

О! и я про то! Спасибо большое! Приятно услышать такое именно от вас, - я довольно регулярно читаю ваши посты в других топиках и уважаю ваш профессионализм.