Дебет Плюс - кроссплатформенная бухгалтерия

>> Как программа на Java может разрабатываться с 91 года?

>RTFM FAQ!

Вот именно. Он же написал что сначала делали на ++ но устали бороться с ветряными мельницами.

> объясните мне, что такого плохого в "жабе" ?

Её жабья натура.

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

> То что на жабе это конечно плохо, но за то что работает под никсами большой респект ИМХО

А кто сказал, что оно работает ?????????? Убогое поделие ... Впрочем, как и любая из предыдущих версий Дебет+ ...

И саппорт у них голимый ... Чуть шо, советуют переставить "самую лучшую ОСь" ... Если они и Линуха будут так же советовать переставить, то ей-бо, не выдержу, приеду в гости и вправлю мозги ....

Резюме: Это точно такая же "хорошая" программа, как и "ото" - самая лучшая из ОСей %) Ну и про соответствие надписей на заборах реалиям, то же вспоминайте почаще ... :)

>Чуть шо, советуют переставить "самую лучшую ОСь" ...

А что с ней еще можно сделать?:)

> Но я не сторонник такого рода заявлений, как 'тормоз - синоним Java'. Просто писать надо уметь.

+1. У меня щас складобухия на жабе в фазу бета-тестинга перешла. Предыдущая версия была на дельфе, но "от нефиг делать" портировал на жабу. Разницы в скорости работы что-то особо не замечаю. Да и ваще bottleneck в таких приложениях - вовсе не клиентская часть (при условии правильного проектирования серверной и не гоняния на клиент всех записей из базы до которых ручки дотянутся).

Зато сколько бонусов при написании кода - вообще кайф и сказка.

> Впрочем, как и любая из предыдущих версий Дебет+ ...

Что-то я не вижу ответов на 6 вопросов которые я недавно задал...

2Афтар: пешы исчо, нестесняйся. Особенно про сохранение логической целостности хотелось бы послушать.

> Вот именно - мне работать! Каждый день в OO.o работаю и вспоминаю жабину мать каждый раз как его запускаю, при том что комп у меня не слабый!

А не надо закрывать. А то мода пошла открывают/закрывают. Или ещё фича есть - предварительная загрузка - после неё всё взлетает.

>Товарищи! Какие такие "тысячи предприятий на Украине" ?! Полагаю, что при нынешнем состоянии дел в этом хм..."государстве" счет тому, что можно назвать "предприятием" идет скорее на десятки, да и то вряд ли. Голимый PR (public relations)! Такое мое мнение... > >С уважением, Дух кокоса.

А не пошли бы вы нах. с такими высказываниями?!!!

> Но я не сторонник такого рода заявлений, как 'тормоз - синоним Java'. Просто писать надо уметь.

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

Что-то я не вижу ответов на 6 вопросов которые я недавно задал...

2Афтар: пешы исчо, нестесняйся. Особенно про сохранение логической целостности хотелось бы послушать.

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

****1. Каким образом достигается логическая непротиворечивость между "хранящимся в XML документом" и сформированными на его основе бухгалтерскими проводками двойной записи.

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

***2. Каким образом обеспечивается отсутствие возможности искажения базы при сбоях клиентских скриптов.

я не совсем понимаю, что такое сбой клиентских скриптов. И встречаетля ли он в реальной жихни. Если вы ездите на автомобиле, то нет 100% гарантии что вы кого-то не задавите и не убъетесь сами. Вероятность искажения базы существует всегда. 100 процентов гарантии не будет даже с том случае если вы не будуте подходить к клавиатуре. Право на запись в базу, пару кривыз запросов и прощай данные. Правда в крутых СУБД это можно попытаться откатить (rollback) вместе с работой соседей. Честно говоря для меня это ситуация больше гипотетическая, чем жизненная.

***3. Каким образом обеспечивается защита от искажения базы путем прямого подключения SQL-консоли с последующими изменениями таблиц.

При прямой рупопашной рихтовке базы, если у вас есть такое право, защиты нет, ни в нашей системе ни в любой СУБД. Это вопрос из серии : Как вы обеспечите работоспособность мониторя, если я его буду лупить молотком?

На остальные вопросы отвечу позже, записался.

И всё же ссылка на быстрое приложение, написанное на жабке, не помешала бы

Хочу сказать за скорость.

Приложения на жабе, может и не летают как плюсовые, но и не заставляют вас уродоваться при написании, как плюсовые. Если скорость очень критична пиши на низком уровне. Если скорость достаточна, то нечего свои горбом облегчать жизнь машине, поскольку пользователю все равно, отреагирует система за 1 или 2 десятых сикунды. Здесь как в автомобилях. Помимо скорости есть еще и комфорт. Один умный человек сверху упомянул про болиды формулы 1. Я читал, что в этих болидах рули съемные, бо иначе в кабину не залезеш. Достаточно покататься пару дней на такой железяке, чтобы полюбить обычную машину в котрой можно расправить плечи и выпить кофе. Напишите на плюсах пару больших систем и глупые вопросы про что быстрее снимуться сами собой. Даже MS это поняли и выпустили шарп, который как две капли воды похож на джаву.

Кстати первые винды едва ворочались на тех машмнах которые тогда были. Наша система 2000-го года тоже нам казалась медленной по сравнению с предыдущей досовой, а сейчас летает. Дебет плюс V12 это конечно не пушинка, но на любом купленной не в антикварном лавке компе она должна работать нормально. Памяти подразумевается 512 (можно 256, но лучше 512) и тактовая 2Гц и выше, хотя можно и меньше.

Учетно-управленческие системы - это тяжедовесы и главное их достоинство не скорость.

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

Забавно, если пользователь по ошибке удалит какие-либо документы вместе с проводками. Будь иначе, наличие проводок просто помешало бы удалить документ. А так...

> СУБД тоже не обеспечивают логическую непротиворечивость.

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

> я не совсем понимаю, что такое сбой клиентских скриптов. И встречаетля ли он в реальной жихни.

Да сколько угодно. Ошибки там разные в браузерах.

> Вероятность искажения базы существует всегда.

Вопрос только в размере этой самой вероятности. Не правда ли?

> Право на запись в базу, пару кривыз запросов и прощай данные.

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

> Правда в крутых СУБД это можно попытаться откатить (rollback) вместе с работой соседей.

А вот причем здесь работа соседей? Откатятся только ваши конкретные "наработки".

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

А говорите про пятнадцать лет разработки. Э-хе-хе.

> Учетно-управленческие системы - это тяжедовесы и главное их достоинство не скорость.

Оправдывать кривизну архитектуры подобными фразами можно. Но не долго пользователям лапшу вешать сможете при таком подходе. Вот у нас оператор накладные набирает. Так если скорость набора падает до 4-5 секунд на позицию - все кричат, как укушенные. Операторов у нас, надо заметить, около 50. Плюс бухгалтеров человек 20. Плюс всяких агентов торговых и других сотрудников, для которых ОЧЕНЬ важна скорость реакции системы.

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

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

> я не совсем понимаю, что такое сбой клиентских скриптов. И встречаетля ли он в реальной жихни.

На половине скрипта тётя Маша зацепит кабель шваброй.

> откатить (rollback) вместе с работой соседей

Это что ж за СУБД такая крутая что транзакцию откатывает вместе с еще чьими-то данными?

> При прямой рупопашной рихтовке базы, если у вас есть такое право, защиты нет, ни в нашей системе ни в любой СУБД

Не, вопрос в другом: вот допустим есть проведённый документ. Открывая его из приложения тётка из бухгалтерии видит те цифры что она туда вбила. А отчёт показывает черти-что, потому как сисадмин Вася в проводках поковырялся... В моей системе, например, в этом случае триггер на изменение таблицы проводок посмотрит на состояние документа и ругнется. Изменение состояния документа пишется опять же соответствующим триггером в аудит. Трогать триггера и чистить аудит может только DBA. И самый супер-пупер юзер в консоли не сделает больше чем ему разрешено. А если документ лежит в XML-блобе, то синхронизировать этот XML-блоб c реляционной таблицей средствами клиента - весьма чревато.

> На остальные вопросы отвечу позже, записался.

Может лучше на www.sql.ru продолжить? Там тааакие зубры в области разработки ИС есть - мало не покажется :) Тут всё-таки более сисадминский а не аппликушно-девелоперский форум.

> 4-5 секунд на позицию

Собственноглазно наблюдал оператора бившего в моей системе 2 позиции в секунду. Так что виртуозы цифровой клавиатуры есть такие что огого.

> Хочу сказать за скорость.

Если хочешь увидеть впечатляющую скорость исполнения псевдокода - погляди на xHarbour.

Уважаемый коллега! Я не собираюсь даже пытаться переубедить вас. Могу лишь сказать следующее. Я пишу и на С++ и на Java и даже на C#. Выбираю язык в зависимости от задачи. Писать Web-приложение на С++, или же драйвер на Java считаю кощунством. Но у разных людей, разное мнение. Могу сказать из опыта, что скорость работы с памятью (указатели, копирование памяти) однозначно у С++ лучше и этим спорить бессмысленно, но в задачах прикладного уровня (например, работа с БД) вы больше потеряете (в поддержке, и быстроте разработки) чем получите, т.к. тормоз будет самый главный БД, и ваши пару наносекунд/миллисекунд (нужное подчеркнуть) никому ничего не дадут. У Java есть другая беда - к сожалению большой процент программистов с низким уровнем квалификации. Это сложилось, IMHO, из-за того, что на язык более прост, чем С++ и уровень вхождения меньше.

>Кстати первые винды едва ворочались на тех машмнах которые тогда были. Наша система 2000-го года тоже нам казалась медленной по сравнению с предыдущей досовой, а сейчас летает. Дебет плюс V12 это конечно не пушинка, но на любом купленной не в антикварном лавке компе она должна работать нормально. Памяти подразумевается 512 (можно 256, но лучше 512) и тактовая 2Гц и выше, хотя можно и меньше.

Это что, каждые два года менять машинный парк? То-то моему руководству деньги больше некуда тратить. 256 - это железо, купленное в последний год-полтора. И тактовая 2ГГц, ну да. Вы предлагаете под новую систему все клиентское железо обновлять? Или рассчитываете на богатого клиента, которому туда 50 тысяч, сюда 50 тысяч - без разницы?

>256 - это железо, купленное в последний год-полтора Ничего не путаете? 256Мб уже давно не покупают. 512Мб и выше берут в последний год/полтора - я уже не говорю о том, что мода пошла >1Gb

>И всё же ссылка на быстрое приложение, написанное на жабке, не помешала бы.

IntelliJ IDEA.

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

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

>Правда в крутых СУБД это можно попытаться откатить (rollback) вместе с работой соседей.

http://jakarta.apache.org/commons/transaction

Будет вам rollback на файловой системе.

>Плюс всяких агентов торговых и других сотрудников, для которых ОЧЕНЬ важна скорость реакции системы.

Что-то мне подсказывает что узкое место в любом случае _не_ морда.

>Плюс всяких агентов торговых и других сотрудников, для которых ОЧЕНЬ важна скорость реакции системы.

Я както нашол pull XML парсер в котором почему-то в жабке обнаружилась проблема с юникодом. Терзаемый смутными сомнениями как это так я полез в исходники... и обнаружил что тип который это писал изобрел для жабы все чего ему не хватало: и malloc и прямую работу с указателями....

>Это что, каждые два года менять машинный парк?

Зачем его менять? Он говорит о том что скорость жакого интерфейса вполне отвечает текущим железкам. Не все же их купили 5 лет назад.

> я уже не говорю о том, что мода пошла >1Gb

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

А почему бы таким клиентам вообще не предложит тонкого клиента (браузер)? Тогда вообще можно не думать о памяти почти.

>Он говорит о том что скорость жакого интерфейса вполне отвечает текущим железкам.

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

К этому и идет. Хотя не быстро. Во всяком случае, некоторые новые подсистемы, которые можно было без ущерба выделить в отдельную задачу, уже через браузер.

>> Это что, каждые два года менять машинный парк?

> Зачем его менять? Он говорит о том что скорость жакого интерфейса вполне отвечает текущим железкам. Не все же их купили 5 лет назад.

Берется одна могучая железка в качестве терминального сервера. И юзерам ставятся самые дешевые драндулеты. Все довольны: админу надо админить одну машину с софтом, у юзеров всё летает, директор сэкономил баблос.

Зачем все усложнять... Терминальные клиенты тоже разные бывают и не очень-то они дешевые. Или имелось обычные машины через Terminal Services (или подобное)?. Могучий терминальный сервер может обойтись гораздо дороже обычного сервера workgroup-уровня. Взять весь зоапарк старых машин и пусть работают в качестве тонких Web-клиентов вместе с средненьким сервером.

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

http://www.itk.ru/r2d2/index.shtml

CLIP + Mozilla XUL.

> Если хочешь увидеть впечатляющую скорость исполнения псевдокода - погляди на xHarbour.

Ага. Ещё на CLIP. :)