MongoDB 1.6.0

Аргументов больше нет?

>В этом пионерском носкуле (mongodb) проблема консистентности стоит горааздо острее. ...которой, мы так и не увидели даже на примере бухгалтерской проводки. Ну да ладно.

Примера значит не будет. Обосновать не можете.

Ну, почитай первые две-три страницы, там фанаты sql чото требовали.

>Аргументов больше нет?

Аргументов чего?

Или ты ждешь, что я стану с копипастой беседовать?

>Да не, чтоб чужих не пропускать.

Думаешь, тайна кумыса так строго охраняется? Ну-ну, блажен, кто верует.

...которой, мы так и не увидели даже на примере бухгалтерской проводки. Ну да ладно.

Кто читал внимательно, тот увидел. Хотите писать бухгалтерию с БД в Mongodb? Вперёд. Время покажет кто был прав. Загнутся все эти no-sql поделки со временем. А если нет, то только если приобретут возможности развитых РСУБД. Я вам это гарантирую.

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

>> Абак рулит.

Да понятно уж давно, читать ты не умеешь.

Зато у меня воображение нормально развито: я представляю себе бухгалтера 500 лет назад, который, когда какой-нить купец спрашивает о состоянии своего счета, начинает рыть кучу пергаментных томов %)

Ссылка на демотиватор - какое достойное завершение спора

Сколько пафоса! А по теме есть что сказать?

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

>Кто читал внимательно, тот увидел.

Ну так можно «на бис», для слепого Базилио, где такое было?

Время покажет кто был прав

да уже показало

А если нет, то только если приобретут возможности развитых РСУБД

чото мускуль не спешит помирать. Или он уже «развитая РСУБД»?

Я вам это гарантирую

инфа 100%?

да уже показало

что я прав.

чото мускуль не спешит помирать. Или он уже «развитая РСУБД»?

Почти. Он в процессе развития.

инфа 100%?

Я гарантирую это!

>Зато у меня воображение нормально развито: я представляю себе бухгалтера 500 лет назад, который, когда какой-нить купец спрашивает о состоянии своего счета, начинает рыть кучу пергаментных томов %)

Да уж, развито. И даже слишком.

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

Ну да, бгыкаешь, весело тебе. А все от того, что ты не в теме очень сильно. А понимал бы ты, хоть немного, о чем речь — плакал бы от позора.

Возвращаясь к вопросу выбора технологий: про дверь уже было в этом треде?

> Ну так можно «на бис», для слепого Базилио, где такое было? Базилио только притворялся слепым, но он всё видел!

> да уже показало

ты ссылку забыл на:

Кто читал внимательно, тот увидел.

Ночь уже. До завтра anonymous

> Ну да, бгыкаешь, весело тебе.

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

А все от того, что ты не в теме очень сильно. А понимал бы ты, хоть немного, о чем речь — плакал бы от позора.

«Спердобейся», какая прелесть %)

>Ну веселишь ты меня, что тут поделать.

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

«Спердобейся», какая прелесть %

Ты бы завязывал с веществами — видишь, как плохо они влияют? Вот теперь глюки у тебя — прочел то, что не написано.

> причину твоего веселья мы уже установили.

Не «мы» %) Или у тебя multiple personalities?

Ты бы завязывал с веществами

Я не могу с ними завязать - я к ним не привязывался :/

>я к ним не привязывался :/

сходи к доктору. Новости будут плохие.

Вот представь. Рассказываешь ты человеку про print «HelloWorld», а он тебе в ответ: «Бгг. Ну ты и ламо! Где ты такие принтеры видел? Эта твоя контора HelloWorld небось еще и картриджи одноразовые делает, или мож, принтеры одноразовые? Ты дебил, как принтер может на экране печатать? Хотя, у таких недоумков может и экран бумажный быть»

Видишь, как смешно? И главное, ему ведь тоже смешно, да. Думает, «Эк я его уделал!» А ему не смеяться, ему плакать надо. Слезами позор свой смывать, хоть и бесполезно это.

И вот, ты ему говоришь это, что, мол, радоваться-то ему особо нечему. Но куда там! Он же победил, он же крутой! Вот он и пишет тебе в ответ какой-то невнятный бред, типа «спердобейся штоле? ыы!»

Вот, стрелок, такие дела. Да.

>по ссылке не ходил, естественно

Анон, кстати, тоже. Потому что там что-то говорится о хотлинкинге :)

>Анон, кстати, тоже. Потому что там что-то говорится о хотлинкинге :)

обнови своего касперского

>> я к ним не привязывался :/

сходи к доктору. Новости будут плохие.

Новостей не будет :)

Рассказываешь ты человеку про print «HelloWorld»

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

А ему не смеяться, ему плакать надо. Слезами позор свой смывать

Какая трогательная забота :)

>Новостей не будет :)

То есть, ты так ничего и не понял? Ну да патрег тебе судия.

>> Новостей не будет :)

То есть, ты так ничего и не понял?

Анон, что у тебя с памятью?

Ты бы завязывал с веществами

я к ним не привязывался :/

сходи к доктору. Новости будут плохие.

Новостей не будет :)

То есть, ты так ничего и не понял?

Что я понять-то должен был из этого диалога? :)

>Что я понять-то должен был из этого диалога? :)

Да не переживай. Кому-то дано, кому-то нет.

> Да не переживай.

Тебя не поймешь - то «слезами позор смывать», то «не переживай» :)

>Тебя не поймешь - то «слезами позор смывать», то «не переживай» :)

Если ничего нельзя изменить — остается только не переживать.

Да, жаль, конечно. В некоторых топиках ты производил впечатление человека, который знает, о чем говорит.

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

Ошибка №1. Остатки НУЖНО пересчитывать (иначе, как узнать его значение?)

И — ВНЕЗАПНО — ты предлагаешь пересчитывать эти остатки после каждой(!) проводки. В итоге получаем: вставка=O(N*N) выборка=O(1*c)

Вставка - N*N?! Это как? И что это за 1*c такое? :)

Я вижу три операции при вставке: вставка в список проводок и два обновления или вставки в аггрегированные данные. Как получили N*N?

При выборке - O(1) - просто запрос. Откуда взялся 'c'?

В общем позвольте пояснить что имеют ввиду про значения остатков, сальдо и прочее уважаемые анонимусы и защитники NoSQL (сам я свою позицию до конца не выработал).

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

В базе также хранятся map reduce процедуры, много их. Как пример одной такой пары:

- map в качестве аргумента всегда берет документы по одному (у нас это проводка, для примера с суммой 100), результатом работы map есть вызов emit(key,value), в нашем случае map вызовет emit(cred,+100) и emit(debet,-100) (знаки могут быть наоборот, я уж не помню что там и как в этом бухучете).

- reduce собирает в себя все что навыплевывал map,а также то что навыплевывали другие reduce, т.е. reduce(keys, values, rereduce) при этом keys это массив [[key, doc_id1],[key, doc_id2]], а values массив [val1, val2], где val1 это значение value выданное в функции map по ключу key при просмотре документа doc_id1. Самое важное: значение каждого reduce для каждого ключа сохраняется в B-tree (от чего база так сильно пухнет). Соответственно если мы запросим данные по какому то произвольному диапазону ключей, то NoSQL быстренько найдет значения этих ключей у себя в дереве, и вызовет для всех них reduce(null, [val1,val2,val3..], true), т.е. время выборки O(logN), что в общем то неплохо. В нашем простейшем случае reduce должна вернуть просто sum(values).

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

Когда будет написано куча map-reduce то мы поимеем любые варианты информации по счетам, оборотам, остаткам, взаимозачетам и пр имея в базе только одну сущность - документы с движением средств.

Две особенности: - чтобы писать на map reduce надо капитально повернуть мозги, например ключи-массивы и группировки по ним я так интуитивно и не понял, постоянно чиркаю на бумажке. - все эти map reduce вызываются только когда их просят, а не когда добавляются новые документы, при этом вызываются только для необработанных версий документов, результаты reduce записываются B-дерево в нужное место. Соответственно добавление новых документов нисколечки не тормозит.

После всего вышесказанного для меня остается непонятным одно: как запретить отгружать товар если долг контрагенты выше допустимого? Мы не можем в одной атомарной операции и прогнать все mapreduce и воспользоваться этим результатом. Может более просвященные люди расскажут как, очень интересно.

> Когда будет написано куча map-reduce то мы поимеем любые варианты информации по счетам, оборотам, остаткам, взаимозачетам и пр имея в базе только одну сущность - документы с движением средств.

Это единственное полезное, что сказал анон. Но на вопрос «а не будет ли это слишком дорого - генерировать эту информацию при запросе?» он предпочел петросянить про 500 лет.

После всего вышесказанного для меня остается непонятным одно: как запретить отгружать товар если долг контрагенты выше допустимого? Мы не можем в одной атомарной операции и прогнать все mapreduce и воспользоваться этим результатом.

Да, интересно. Я подозреваю, что без использования внешних менеджеров блокировок это невозможно.

>обнови своего касперского

Какой касперский?

> После всего вышесказанного для меня остается непонятным одно: как запретить отгружать товар если долг контрагенты выше допустимого? Мы не можем в одной атомарной операции и прогнать все mapreduce и воспользоваться этим результатом. Может более просвященные люди расскажут как, очень интересно.

А зачем Вам такие приземленные материи, как долг контрагента? У вас же есть дико быстрая NoSQL базка без убогих транзакций. И map-reduce с пучащим базку кешем. С точки зрения современной моды IT это практически оргазм.

> Но на вопрос «а не будет ли это слишком дорого - генерировать эту информацию при запросе?» он предпочел петросянить про 500 лет.

Знаешь, я уверен, что ты собирался задать вопрос «а не будет ли это слишком дорого - генерировать эту информацию при запросе?». Я даже уверен, что мой ответ ты воспринимал в контексте этого своего вопроса.

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

«То есть, чтобы узнать сумму на счету (ах да, „сальдо“), нужно запускать жаваскрипт, который проведет MapReduce по всем „бухгалтерским справкам“? Это рекомендованный метод решения таких задач?»

И вот ссылка, что бы любой желающий мог меня проверить: http://www.linux.org.ru/jump-message.jsp?msgid=5196253&cid=5208385

И еще вопрос касательно «петросянить про 500 лет». Если ты располагаешь достоверными сведениями о том, какие изменения произошли в методике бухучета со времен Екатерины Медичи, то поделись им пожалуйста. Я имею в виду не всякую фигню, которую минфин изобретает по пять раз на дню (типа, относить ли кактусы на расходы или на прибыль), а системообразующие методики, такие как баланс и двойная запись.

>После всего вышесказанного для меня остается непонятным одно: как запретить отгружать товар если долг контрагенты выше допустимого? Мы не можем в одной атомарной операции и прогнать все mapreduce и воспользоваться этим результатом. Может более просвященные люди расскажут как, очень интересно.

ну отлично, ты получил четкую модель данных по которой можешь строить всю аналитику и не просто аналитику, а аналитику с верификацией. Это уже очень хорошо.

Все, что тебе нужно, это во первых, подсчитывать и валидировать промежуточные результаты, а во вторых, использовать их.

А можно на пальцах по шагам объяснить как этого достичь, вместо игры в наводящие вопросы «догадайся сам, а я помогу»? хочется конструктива =)

>>После всего вышесказанного для меня остается непонятным одно: как запретить отгружать товар если долг контрагенты выше допустимого? Мы не можем в одной атомарной операции и прогнать все mapreduce и воспользоваться этим результатом. Может более просвященные люди расскажут как, очень интересно.

ну отлично, ты получил четкую модель данных по которой можешь строить всю аналитику и не просто аналитику, а аналитику с верификацией. Это уже очень хорошо.

Все, что тебе нужно, это во первых, подсчитывать и валидировать промежуточные результаты, а во вторых, использовать их.

AVL2, по тебе плачет отдел продаж. Мало людей обладают таким даром ответить на вполне конкретный вопрос так, чтобы сообщить ноль информации плюс чуточку перекрутить факты и неплохо создать видимость экспертного мнения. Это достойно уважения. Я серьезно.

Теперь по пунктам.

1. «ты получил четкую модель данных» - нет, не получил. Она уже была. Причем GognoDB тут не помогло никак.

2. «по которой можешь строить всю аналитику и не просто аналитику, а аналитику с верификацией» - опа... Так значит тупой подсчет позиции и элементарная проверка на выход из допустимого диапазона теперь называется «аналитика с верификацией». Век живи, век учись.

3. «Все, что тебе нужно, это во первых, подсчитывать и валидировать промежуточные результаты, а во вторых, использовать их.» - ага, конечно. Вот только вопрос был в том, как именно это сделать. На это уважаемый эксперт глубокомысленно промолчал.

Мы не можем в одной атомарной операции и прогнать все mapreduce

Зачем нам все mapreduce? За балансы счетов отвечает только один.

Если нужно обслуживать клиента, который одновременно может делать несколько заказов, то тут конечно без лока не обойтись, но его реализация ничего не стоит.

И вот ссылка, что бы любой желающий мог меня проверить: http://www.linux.org.ru/jump-message.jsp?msgid=5196253&cid=5208385

Ты ещё на заборах рекомендованную методику почитай. Может ещё придумаешь как БД притормозить.

Методика рекомендованная Екатериной Медичи: Используйте MapReduce!

> Если нужно обслуживать клиента, который одновременно может делать несколько заказов, то тут конечно без лока не обойтись, но его реализация ничего не стоит.

<trolling mode=«fat»> Если клиент - один в день, то да. Так что все оправдано. Для псевдобизнеса «на коленке» ваши кушеткаДБ - самое оно. Прибыли нет, но и программисты много не требуют: работают за идею, а на оплачиваемую работу таких «спецов» никто брать не хочет. </trolling>

>1. «ты получил четкую модель данных» - нет, не получил. Она уже была. Причем GognoDB тут не помогло никак.

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

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

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

А ты молодец, поставил p3-600 с гигом рамы и провел свои три накладные в сутки - на кой ляд тебе все эти носиквелы?

2. «по которой можешь строить всю аналитику и не просто аналитику, а аналитику с верификацией» - опа... Так значит тупой подсчет позиции и элементарная проверка на выход из допустимого диапазона теперь называется «аналитика с верификацией». Век живи, век учись.

Ну, аналитика может быть и такой. У тебя копеечка, а у Абрамовича - рубль, но у вас у обоих - деньги. Важно то, что ты можешь посчитать все, что тебе нужно и если тебе нужна одна сумма - let it be и не парься.

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

3. «Все, что тебе нужно, это во первых, подсчитывать и валидировать промежуточные результаты, а во вторых, использовать их.» - ага, конечно. Вот только вопрос был в том, как именно это сделать. На это уважаемый эксперт глубокомысленно промолчал.

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

Что тут еще непонятно?

Я тебе про Фому, а ты мне про Ерему.

>1. «ты получил четкую модель данных» - нет, не получил. Она уже была. Причем GognoDB тут не помогло никак.

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

1. Как то, нужен мне nosql или нет, связанно с тем, что я написал выше?

2. не щекочет и не щекотал. Когда такое начиналось, обычно единственно правильный вариант - выгнать чудо-девелопера, что наваял адский ужас, что даже кластер не тянет, и переписать его код.

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

Google и Facebook - другая история. Там, даже если данные просто исчезнут, беды большой не будет. И задачи у них решаются другие.

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

Какая оплата - такой и сервис. Какой сервис - такие и технологии.

А ты молодец, поставил p3-600 с гигом рамы и провел свои три накладные в сутки - на кой ляд тебе все эти носиквелы?

Похоже тебе из астрала все хорошо видно.

2. «по которой можешь строить всю аналитику и не просто аналитику, а аналитику с верификацией» - опа... Так значит тупой подсчет позиции и элементарная проверка на выход из допустимого диапазона теперь называется «аналитика с верификацией». Век живи, век учись.

Ну, аналитика может быть и такой. У тебя копеечка, а у Абрамовича - рубль, но у вас у обоих - деньги. Важно то, что ты можешь посчитать все, что тебе нужно и если тебе нужна одна сумма - let it be и не парься.

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

3. «Все, что тебе нужно, это во первых, подсчитывать и валидировать промежуточные результаты, а во вторых, использовать их.» - ага, конечно. Вот только вопрос был в том, как именно это сделать. На это уважаемый эксперт глубокомысленно промолчал.

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

Что тут еще непонятно?

Все непонятно.

redbaron спросил «как запретить отгружать товар если долг контрагенты выше допустимого?»

Какая очередь? Что, все операции записи стают в очередь, и потом что-то принимается, а что-то отбрасывается?

Что считается событием: сделка или попытка сделки?

Что именно при этом хранится в базе?

Как для программы-клиента выглядит успешность/неуспешность совершения проводки?

redbaron, а тебе понятно? Может объяснишь?

Я понял общую концепцию но как это конкретно реализовать на примере не понял :) В простой ситуации у нас есть два типа документов в базе: те что двигают деньги и те что двигают товар.

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

Но вот что подумалось, поскольку документ движения денег будет создан в любом случае независимо от успеха/неудачи движения товара, то с точки зрения бизнеса что мы используем транзакции и с филигранной точностью раздаем разрешения на отгрузку, что мы тупо решаем ее наивным способом выше - нет никакой разницы. Ну прикрутили мы транзакции, ну прибежал клиент за товаром на 2 минуты раньше чем бухгалтерия вбила новый документ увеличивающий долг в базу - SQL со всеми наворотами никак не спас нас от ситуации, что и долг есть и товар уплыл, а раз SQL не спасает то можно и NoSQL поставить, раз результат один и тот же, зато бонусов сильно больше, как ни крути а иметь в базе только фактически существующие документы и мапредьюсить их и в хвост и в гриву сильно проще с точки зрения разработки и поддержки, а также сильно лучше с точки зрения скорости.

>1. Как то, нужен мне nosql или нет, связанно с тем, что я написал выше?

nosql решает вполне конкретные задачи. Нет задач - нет nosql.

2. не щекочет и не щекотал. Когда такое начиналось, обычно единственно правильный вариант - выгнать чудо-девелопера, что наваял адский ужас, что даже кластер не тянет, и переписать его код.

Пока это работает - nosql не нужен.

Google и Facebook - другая история. Там, даже если данные просто исчезнут, беды большой не будет. И задачи у них решаются другие.

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

Какая оплата - такой и сервис. Какой сервис - такие и технологии.

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

Похоже тебе из астрала все хорошо видно.

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

redbaron спросил «как запретить отгружать товар если долг контрагенты выше допустимого?»

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

Какая очередь? Что, все операции записи стают в очередь, и потом что-то принимается, а что-то отбрасывается?

Да в идеале, ничего не отбрасывается. Все документы идут во входную очередь.

Что считается событием: сделка или попытка сделки?

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

Что именно при этом хранится в базе?

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

Как для программы-клиента выглядит успешность/неуспешность совершения проводки?

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

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

Транзакции здесь не при чем. Они только добавят вам дедлоков и только.

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

>Методика рекомендованная Екатериной Медичи: Используйте MapReduce!

ой, смищьно-смищьно!

Я смотрю, ты специалист в этом вопросе? Тогда к тебе тот же вопрос, что и к стрелку: какие изменения произошли в методике бухучета со времен Екатерины Медичи?

>Решение о проводке зависит от бизнес-модели. Или вы работаете с товарным кредитом и проводите товар (тогда резервирование денежных средств работает в сервисном режиме, позволяя гибко установить ограничения товарного кредита) или без него, тогда товар не проводится.

То есть, модель ИС должна отражать бизнес-модель, и весь вопрос сводится к тому, на сколько точного отражения позволяет достичь тот или иной инструмент?

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

2AVL2

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

ZODB Год 98-й если память не изменяет, не старше 95-го точно. Но в 98-м был.

Ссылки есть, да. Транзакции тоже. Есть целостность за счет интерфейсов. Тоесть я не смогу в документ положить объекты иного типа, чем явно указано.

В Zope кроме того возможет такой случай: До 2000г. банковские счета были не 20 знаков, а после 20. В SQL бодренько для новых документов завели новые таблицы. Или придумали отображение не 20-и занчных документов на 20 значные и конвертнули их. В Zope поправили схему, теперь в каталоге документов могут лежать как новые документы, так и старые. Есть адаптер для преобразования (для расчетов какихнибудь). Но если я открою для просмтора старый документ, то даже форму я увижу СТАРУЮ.

>Хотите писать бухгалтерию с БД в Mongodb? Вперёд.

Google ERP5. Там правда ZODB не для хранилища. Есть еще Японская банковская система, не помню названия.

>> Хотите писать бухгалтерию с БД в Mongodb? Вперёд.

Google ERP5. Там правда ZODB не для хранилища.

А что там для хранилища и причем тут ZODB? Она, IIRC, не документно-ориентированная, а объектно-ориентированная.

Написано же в ZODB есть транзакции

> Написано же в ZODB есть транзакции

Вопрос был «причем здесь ZODB?».