Cane Cat FisherПо поводу формата хранения, и разруливания блокировок, эту систему можно назвать "версионник, возведенный в абсолют", со всеми достоинствами и недостатками.

Версионник - да, похоже. А можно поподробнее о недостатках?

Cane Cat FisherНо практика показала, что чаще всего требования эти растут. И проблемой является именно задача расширения систем "в разы". Поэтому и придумали SQL-сервера - они масштабируются легче, позволяют накрыть более широкий диапазон задач - от быстрого (ну, в разумных пределах :) сбора телеметрии, до огромных неторопливых хранилищ аналитики.

Частично с вами соглашусь, но сегодня все-таки начинает наблюдаться и обратная тенденция: начали выплывать альтернативные стандартным реляционным базам решения. Я об этом уже говорила выше.

Cane Cat FisherКонечно, если бы под каждый род задач разрабатывалась особая, "заточенная" СУБД, возможно, она в каких-то моментах оказалась бы выигрышнее, чему универсальные. Но это очень дорогой и ненадежный путь.

Согласна в контексте "под каждую отдельную задачу". Но вот если попытаться выделить классы задач?

Cane Cat FisherПоэтому, я бы предположил, что в таком неторопливом режиме, на 30 бухгалтеров, можно было бы сделать систему практически на любой платформе. Аналогичные задачи - вариантную структуру записей, и т.д. - решить другими, но вполне работоспособными способами. А если те же усилия, что пошли на разработку своей системы, пустить на оптимизацию системы на SQL - результат был бы ничуть не хуже, а, уверен, лучше, и главное - перспективнее.
Вообще, я бы посоветовал, сейчас не прикручивать к этому делу SQL, а срочно перевести этот фреймворк (за который авторам честь и хвала), на работу с нормальным SQL - сервером.

Вот этот момент я как раз обсуждала с разработчиками именно прикладной части. То есть я реально задавала вопрос: может дело в том, как написана прикладная задача и в том, что у истоков создания системы стоял очень грамотный бухгалтер с математическим образованием? Но они почему-то уверены, что дело не только в этом. Что важны и прикладная и системная части и без такой системной многие особенности прикладной у них бы не получились.

У них, к примеру, есть такой режим песочницы. Он используется и бухгалтерами и при отладке комплекса. Если перевести станцию в локальный режим работы, то вам в теории ничего не мешает начать кромсать данные в базе как вам заблогарассудится - типа - эксперименты проводить. Вы можете этим часами заниматься. А потом просто сказать что-то типа undo и система у вас вернется в начальное состояние. В теории - так же просто делать и пошаговый undo и на заданный момент времени. Как вот эту, например фичу реализовать в стандартном реляционнике, вот без такого потокового метода записи - я не представляю, - накладные расходы слишком большими будут.

Насчет переноса на стандартный SQL-сервер. У них связь реализована. Т.е. есть API для цепляния и к обычному серверу. Но для реализации прикладных задач они этим не пользуются - говорят неудобно. Используют связку только если интеграция нужна.

Edd.Dragon,
Спасибо конечно, но я не разработчик :) Просто разработчики - мои очень близкие знакомые и я несколько лет так или иначе слушала про их систему всякие байки. Сейчас есть шанс все это раскрутить более серьезно. Вот я и оцениваю перспективы.

Vladimir Baskakov,
Так летает уже. Только в предыдущей версии, которая по некоторым характеристикам морально устарела, но база там именно такая как описана. А в предыдущей версии полный учет предприятия - как в 1C. В новой пока только зарплата.

Vladimir Baskakov,
Нет, там не стартап. Контора работает с 90х годов и обслуживается силами ээ... 2.5 программистов (в разные годы по-разному, но среднее число примерно такое). При этом они всех своих клиентов успевают поддерживать и вовремся выпускать все изменения в законодательстве, которые за эти годы имели место быть. Говорят что все это благодаря только гибкости фреймворка.

Gluk (Kazan)интересующаяся_мнениемУ них, к примеру, есть такой режим песочницы. Он используется и бухгалтерами и при отладке комплекса. Если перевести станцию в локальный режим работы, то вам в теории ничего не мешает начать кромсать данные в базе как вам заблогарассудится - типа - эксперименты проводить. Вы можете этим часами заниматься. А потом просто сказать что-то типа undo и система у вас вернется в начальное состояние. В теории - так же просто делать и пошаговый undo и на заданный момент времени. Как вот эту, например фичу реализовать в стандартном реляционнике, вот без такого потокового метода записи - я не представляю, - накладные расходы слишком большими будут.

Как то так ?
Да, по эффекту примерно похоже. Нууу... Oracle наверно может все, но это очень дорого, и по стоимости и по обслуживанию. Согласитесь.. небольшая конторка вообще без админов его себе позволить не может.

Gluk (Kazan)То есть 200 внедрений это НЕ серьезно?
Смотря с чем сравнивать :) Если с 1С например, то эта капля даже не в море, в океане.

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

Не покупать и не приобретать, а скорее, - поучаствовать. Вот пытаюсь понять перспективность. У меня тоже есть некоторое представление о теории и практике строения реляционных СУБД. И я понимаю, что это чудо ни на что не похоже. Но живет же. И даже вполне себе прилично. Вот мне и стало интересно. Я пытаюсь немного абстрагироваться от своих знаний и действительно посмотреть на систему непредвзято. Сравнивать только возможности, причем в контексте применения к конкретным задачам. Меня одной на такой анализ не хватит. Хочется коллективного мнения.

Взять к примеру, переменное число полей в таблицах. Де-факто получается, что у них просто очень широкие таблицы, в которые напихано сразу все. В теории, - ну что мешает сделать это в реляционной СУБД? Тем более что ALTER TABLE, насколько я понимаю, операция простая и в современных СУБД ресурсов не требует особо, а значения с NULL память не забивают.. Так почему не делают? Некошерно? Некрасиво? Почему?

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

А жаль что не видите смысла обсуждать причины, но воля ваша.

Dimitry Sibiryakovинтересующаяся_мнениемПо номеру транзакции. Если станция получила обновление с пропуском, она запрашивает у
сервера недостающее и тогда он уже ей персонально пересылает.

Такое возможно в двух случаях:
1) Транзакции полностью сериализованы и идут исключительно последовательно;
2) Хранится индивидуальный список принятых транзакций.

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

Какой случай реализован в Вашей системе?

Я могу уточнить это у разработчика, - но по-моему первый. Информация от клиента уходит на сервер, сервер ей присваивает очередной по порядку номер и бродкастит это клиентам. Клиенты получают, записывают к себе в базу. Если клиент видит, что у него пропуск в номере - запрашивает у сервера недостающее.

Vladimir BaskakovА, тогда хороших полетов! То есть кадры, зарплата, склад, управленка? Налоги всякие... а отпуска, больничные... перекрывающиеся... бюджетирование...

В предыдущей версии - да.

Vladimir Baskakov(тихо, почти шепотом) толстый клиент, да? чур меня, чур меня...

Да, собственно на базе фреймворка и сделан. Клиентские БД, которые в описании базы описаны встроены в фреймворк, т.е. они как встроенная база работают.

Vladimir BaskakovА на чем оно написано? Апи какое?

База и фреймворк написаны на C++, причем чистом, без использования библиотек. Разработчики собирали их детище под разными платформами, не Win - работает. Думаю, полное тестирование все-таки выявит особенности, но опять-таки, думаю, что допилить в случае чего будет несложно.
Сама прикладная часть написана на встроенном языке фреймворка, на нем и API, если дописать что-то хотите. Встроенный язык с полной поддержкой ООП и плюс чего-то там еще умеет. Но в этом мне еще отдельно разбираться надо.

Vladimir BaskakovНапример, я хочу прикрутить к этому мегачуду эксель. Люблю экселевские сводные таблички например... так получилось. Или люблю фаст-репорт. Или кристалл - репорт. Или еще какую нить всеядную фигню...

Excel, понятное дело, прикручен в плане экспорта в него. Более детально - надо спрашивать у разработчиков. Насчет остальных продуктов - неуверена. Они для создания отчетов внутренними средствами фреймворка пользуются. Доработки такого рода делают если заказчик пожелает.

Vladimir BaskakovМой вердикт такой - или - это мегагениальный суперпродукт будущего.... или.... Ну - я романтик - буду верить в хорошее!
Вот и я пытаюсь понять кто я.. или романтик или :) Поэтому и хочу коллективного мнения и критики подхода. :)
Только аргументированной.

Dimitry SibiryakovТ.е. пока с сервером работает один клиент, остальные сидят и курят в очереди.

Почему? Каждый клиент ведь работает со своими локальными данными. Чтение - это вообще не проблема. Обновление записи, - что в такой схеме помешает нескольким клиентам одновременно обновлять данные? Они обновили, - отправили на сервер. А там уже транзакции номер присвоился. Так на практике и происходит.

Dimitry SibiryakovЕщё вопрос:
она продолжает работать с состоянием, актуальным на момент завершения седьмой
транзакции и продолжает формировать данные для следующей. Если она в этот момент завершит
свою работу и изменившиеся данные пойдут на сервер, он не сможет записать ее данные и
сообщит на станцию об ошибке (вспомним, что они редактировали один и тот же документ).
Как сервер определит, что они редактировали один и тот же документ?

Сценарий:
1. Операционистки 1 и 2 начинают редактировать Документ 1;
2. Операционистка 3 начинает редактировать Документ 2;
3. Операционистка 1 сохраняет Документ 1;
4. Операционистка 3 сохраняет Документ 2;
5. Операционистка 2 сохраняет Документ1.
Что делает сервер чтобы сообщить Операционистке 2 об ошибке?

Сервер всегда знает станцию, от которорой пришел запрос на обновление данных.
Допустим в вашем сценарии на начальный момент времени у нас 7 транзакций. Данные от операционистки 2 сервер сохранит в качестве транзакции под номером 8, а от операционистки 3 - 9. Когда придет запрос от операционистки 2, там будет указано, что она хочет сохранить документ 1 и ее последняя транзакция - 7. Сервер увидит, что после этой транзакции уже происходило редактирование этого документа (сохранено в транзакции 8) и он вернет клиенту сообщение об ошибке - что-то вроде "конфликт обновление записи, обновите документ и отредактируйте его снова". Вообще- это задача прикладного программиста отработать эту ошибку. Реакция с точки зрения пользователя может быть и другой, например - перезаписать автоматом, или сравнить запись по полям, обновив автоматом те поля где нет конфликта и дать пользователю решать, как именно разрулить конфликт с конкретным полем, ну и т.п.

--------------------------------Не понял - что вы такого удивительного обнаружили в их транзакциях.
Вполне нормальный механизм. Обычно это называется "оптимистическая блокировка".
А транзакции перепутаться не могут просто потому, что номер транзакции присваивается при фиксации.

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

Конечно, вся эта петрушка будет хорошо жить на небольших базах. Если мы начнем перерастать какие-то пределы (какие - хочу провести эксперименты со временем), то наверно этот недостаток должен начать давать о себе знать. По факту, я так понимаю они сталкивались с числом записей примерно до поллумиллиона в одной таблице, пока задержек не проявлялось.

Dimitry SibiryakovТо бишь в примере из статьи при записи транзакции 10 надо определить, что транзакция 8
изменила именно Документ 1, а не Документ 3, например.

Ну а как вы в обычной базе определяете, что это уже существующая запись? По ключу. А поиск - индексы.