>А я думаю, что старше тебя лет на десять. Ну да не в этом дело. См. ниже.
Надо же.
Такой большой и такооой глупый :-)
Хотя учитывая + 10 лет это уже явные признаки начинающего маразма.

> Open Audio Library.
:-)

>если картинка в виндах омерзительного качества?

Точно, маразм. И при этом паранойя.
Мне Вас жаль.

>www.sap.com/linux :) это что ? детская поделка ? я бы даже не пытался >выставить такое на всеобщее обозрение :)

Странно, как же Вы выставили itk.ru ? :-)

to ifconfig: если уж проявились такие ассоциации "из пункта А в пункт Б" то увы сикель в данном случае выглядит как прицеп которому требуется тягач в виде С++ или другого языка программирования потому как голым сикелем много не понапишешь -- а вот клип - это тот материал из которого можно сделать хоть велосипед хоть персональную легковушку различного качества либо тот тягач который будет тащить сикель -- и именно поэтому меряться на абстракной задаче я не буду -- только на конкретной.

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

Небольшой пример ВЫЧИСЛЕНИЙ - например оператор ввел накладную из 20 строк - любую из строк можно обработать и разложить по полочкам можно паралельно - они друг от друга никак не зависят - раскидали их про процессорам/машинам - эти процессы начинают транзакции - и упираются в сикель - в лучшем случае все транзакции закончатся последовательно в худшем попадут в клинч и юзерь получит отлуп

А вычислений здесь немало - пересчитать остатки по каждому товару - сделать проводки - перестроить аналитические и статистические данные - перестроить баланс - все эти процессы/ процедуры также легко распаралеливаются по железу - но увы дырка будет одна - сикель

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

Вариант третий - не делать все вычисления - не перестраивать балансы - не делать проводки - не пересчитывать аналитические данные - тогда на каждый запрос типа "сколько там у нас XXX в разрезе YYY на уровне ZZZ за период DDDD" на сервак улетает полтысячи запросов с тем чтобы вычислить требуемые чиселки -- и опять не хватает скорость доступа к БД

Щаз мне начнут заливать про OLAP+OLTP - ну давай - только я сразу могу сказать - и тот и другой использует кеширование для расшивания описанных мной дырок и сикель как таковой используется только для конечного хранения данных - о чем я и говорил чуть выше. Но при этом забудь про распределенные вычисления - некому поддерживать актуальность кешированных данных. В лучшем случае можно пользовать несколько процессоров на серваке а вот о кластере придется забыть. Кстати - в данном случае получается клип - работа OLTP сервера и есть работа с закешированными таблицами - ну разве что не в формате DBF:)

В случае же РАСПРЕДЕЛЕННЫХ ВЫЧИСЛЕНИЙ и отсутсвия дыры под названием сикель - все вычисления производятся сразу паралельно при этом данные в БД попадают в готовом для использования виде - и на запрос типа "чуть выше было описано" ответ будет практически моментально - причем его выполнение тоже можно распаралелить

По скорости написания программ вообще не буду спорить ни на какую тему - слишком много тут зависит от субъективных факторов и цифрами их не измерить.

to anonimus на www.itk.ru нет ничего про конкретные бизнес-программы и если ты там умудрился найти описание нашей старой проги - увы это чей-то промах - снесу эти файлы как только найду :)

Больше одного языка выучить можно. Память только нужно иметь.

>транзакции - и упираются в сикель - в лучшем случае все
>транзакции закончатся последовательно в худшем попадут в клинч
С чего вдруг? Такое произойдет если(одно из):

1. Все данные на одной однопроцессорной машине(тогда так быстрее)
2. Запросы выдаются серверу *последовательно*

>все вычисления производятся сразу паралельно
Так открой несколько соединенй и передавай им свои SQL в разных threadах - и будет тебе паралельно.
Просто больше сложностей в случае каких-либо ошибок.

>транзакции - и упираются в сикель - в лучшем случае все >транзакции закончатся последовательно в худшем попадут в клинч С чего вдруг? Такое произойдет если(одно из): 1. Все данные на одной однопроцессорной машине(тогда так быстрее) 2. Запросы выдаются серверу *последовательно* >все вычисления производятся сразу паралельно Так открой несколько соединенй и передавай им свои SQL в разных threadах - и будет тебе паралельно. Просто больше сложностей в случае каких-либо ошибок.

Чем так уж плох SQL?

Может я что-то не понимаю, но на SQL логику не пишут.
У него хороший SELECT/UPDATE/и т.п. Этим и нужно пользоваться.
Все остальное - для внешних языков(в т.ч. и потоки).

Пример для любителя паралелизма - 
#!/bin/bash
while read СТРОКА ; do 
echo "
{INSERT/UPDATE/DELETE .... $СТРОКА ...}
" | sqlplus & 
done <НАКЛАДНАЯ 2>&1 | ОБРАБОТАТЬ ОШИБКИ

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

И логику хоть на чем пиши - все равно в сикель за данными/ транзакциями полезешь - а он как раз клинчи в это время расшивает. Вот и будешь кукарекать - зато многопоточно :)

SQL то тут причем?

>он же не сможет себя распаралелить на много железяк
Я бы не был так уверен. Завтра спрошу у ДБА, говорят есть всякие paralel server(если они об этом - могу ошибаться)

>залочен другим процессом
Та же ситуация возникает НЕЗАВИСИМО от сиквела в ЛЮБОЙ системе с блокировками и паралельной обработкой. 
И если я правильно помню институтский курс проблема разрешима.
Правда, я видел как ORACLE блокируется, но это минус конкретной реализации.

>на оракловскую иглу подсесть
Пример из PostgreSQL:
test=# select ... for update
ERROR:  Deadlock detected.
	See the lock(l) manual page for a possible cause.

Где проблема?

>на www.itk.ru нет ничего про конкретные бизнес-программы
на sap.com/linux тоже.
Не, я понимаю, что фирма ИТК поступает с нами горааздо лучше, чем SAP.
ИТК дает народу под GPL великий и могучий язык для описания бизнеса-
клиппер, SAP же за ABAP хочет денежку, а уж аз написанный на нем функционал - тем более. А чтобы еще сильнее навредить народу SAP раздает вредоносный sql-based софт - SAP DB - под GPL, чтобы из последних сил подорвать могущество фирмы ИТК и хоть как-то бороться с ее монополией

;-))))

>И логику хоть на чем пиши - все равно в сикель за данными/ >транзакциями полезешь - а он как раз клинчи в это время расшивает. >Вот и будешь кукарекать - зато многопоточно :)

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

:-/
Можно подумать, что производительность - это все что может быть надо.

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

>>Может я что-то не понимаю, но на SQL логику не пишут.
У него хороший SELECT/UPDATE/и т.п. Этим и нужно пользоваться.
Все остальное - для внешних языков(в т.ч. и потоки).


Совершенно верно. Не понимаешь. Вот она чистейшей воды логика web програмера, шедевром готорой здесь было высказывание что у оракла есть достойный "заменитель" MySQL. Про PL/SQL, хранимые процедуры, тригеры, server side java может быть слышал когда нибудь? и что ВСЯ логика пишется именно в пакетах и отчасти в тригерах именно на сервере (пишеться кнечно не ANSI SQL, но мне трудно разделить где заканчиваеться SQL и начинаеться PL/SQL или Java). А клиент нужен только для того чтоб функции, процедуры да вьеверы дергать (не в коей случае не таблицы). Лано, это уже неоднократно здесь обсасывали....


Так, теперь с о более интересном...

>>требуется тягач в виде С++ или другого языка программирования потому как голым сикелем много не понапишешь

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

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

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


>>А вычислений здесь немало - пересчитать остатки по каждому товару - сделать проводки - перестроить аналитические и статистические данные - перестроить баланс - все эти процессы/ процедуры также легко распаралеливаются по железу - но увы дырка будет одна - сикель


А причем тут сиквел (как язык)? распаралеливать запросы непосредствено к данным и распаралеливания по нодам и есть задача сервера (замечали наверное что обычно пишут ___SQL_SERVER____). А ваша задача как программера помочь ему (SQL server) максимально правильно построить модель данных, чтобы он бедняга поменьше дурной работы делал.


>>Теперь случай когда внесение новой накладной обрабатывается одной транзакцией и эта одна транзакция производит все перечисленные телодвижения - юзерь будет сидеть и ждать пока не завершатся все вычисления - вот это именно ты и константировал - не хватает скорости доступа к данным чтобы в разумное время произвести все вычисления


Да, это я константировал... Это ведет к потере скорости, но зато гарантирует целостность. А целостность данных главнее. Скорость в конце концов можно купить (железо и более квалифицированые програмеры, которые explain пользовать умеют).
насчет сидеть и ждать... не всегда, строй приложение так, чтобы после проводки накладной юзверь не ждал завершения транзакции, а готовил следующюю накладную. Если об этом думать перед написаниям апликухи, то подобных проблем, в смысле ждать возникает по минимуму...


>>По скорости написания программ вообще не буду спорить ни на какую тему - слишком много тут зависит от субъективных факторов и цифрами их не измерить.

Спорить тут и вправду бесполезно. Хотя примеров апликух пользующих RDBMS значительно больше... странно..

Вот только когда увижу (или мне расскажут о супермаркете в 30 касс,100 рабочих мест и миллионе транзакций в день), пользуюших аппликуху написаную без SQL сервера. вот тода снова переспрашу ваш URL... А пока, это все разговоры н3и о чем.

> Вот только когда увижу (или мне расскажут о супермаркете в 30 касс,100 рабочих мест и миллионе
> транзакций в день), пользуюших аппликуху написаную без SQL сервера.

Много ты написал, но все вода, а вот на последнее мне захотелось ответить.
Значит представь себе огромный завод с сотней складов (это уже больше ста мест), тысячи наименований
изделий, вереницы грузовиков, бухгалтерия соотвествующая и т.д. Работает на клиппере. Причем я тебе могу
показать не один такой "завод", а с десяток... Попробуй сунься туда со своим
sql'ом и java. Только помни, средняя машинка на рабочем месте p200/32M, и это считается еще "жирный" клиент ;)

>Угу. А на клиппере, разумеется, никаких блокировок нахрен не надо.

надо, но клинчи разводятся легко так как нет понятия "транзакция"

>Да и доступ из соседних приложений очень легко реализуется. >У него же енжин прям в dbf файле - само все отслеживается >:-/

К чему это ? мы продолжаем обсуждать чистый клиппер ? А я уже давно закончил :)

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

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

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

Легко. И могу показать сетюку в 350 машин с примерно 150 прогами писанными на клиппере. Причем не мной писанными и я к этой конторе имею только "консультационное" отношение. И как писал очередной анонимус - p200/16 считается жирным клиентом :) Да еще и arcnet жив, причем самый длинный хвост - около 4км.

>А то грустно :-)

Грустно то что "не слышал где звон, зато наехал".

теперь to ifconfig: >Да, это я константировал... Это ведет к потере скорости, но зато >гарантирует целостность. А целостность данных главнее. Скорость в >конце концов можно купить (железо и более квалифицированые >програмеры, которые explain пользовать умеют). >насчет сидеть и ждать... не всегда, строй приложение так, чтобы >после проводки накладной юзверь не ждал завершения транзакции, а >готовил следующюю накладную. Если об этом думать перед написаниям >апликухи, то подобных проблем, в смысле ждать возникает по >минимуму...

Смотри сколько геморою сам же и перечислил (а я тебя за язык не тянул) значит от программера и железа требуются:

- Java чтоб писать приличную бизнес логику - С++/ .... чтоб писать клиенскую часть - explain - чтоб быстрые запросы строить - клиенская часть поддерживаюшая многозадачность - хорошо думать и искать компромисы между "делать щаз" или "доставать по мере надобности" - задачка не из слабых и без опыта реальных эксплуатаций ее не решить - умение расшивать клинчи я бы еще добавил : - знание диалекта SQL - умение читать планы выполнения и оптимизировать запросы под эти планы - умение крутить настройки сервера с целью "вытаскивания" узких мест

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

А теперь подумай - ради чего собственно столько сил и бабок тратиться ? Сможешь ответить ? Один из ответов прозвучал "ради целостности". А ты пробовал обеспечить целостность другими способами ? Или просто начитавшись рекламы и консультантов от оракла поверил им на слово ?

Вот тут действительно грустно.

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

Ну и где самое узкое место ? Вот именно-то :) в том самом сикеле, который для КИС как корове пятое колесо.

И про ООБД я тебя тоже за язык не тянул - НУ И ГДЕ ОНИ ?????? Ты знаешь что ОО реализованное через сикель нагружает сикель в несколько раз больше ? Опять узким местом является сикель.

uri@itk.ru

Насчет жирного клиента

Зачем продлевать жизнь х#@не.
У нас есть очень большая программа написанная на Clipper сторонней
компанией. Работает она через одно место, день лучше начинать с пере-
индексации файлов. Это я думаю наглядный пример тем кто хочет экономить, оставаясь на старом железе и таких технологиях как
Clipper/DBF.

Web-based работает на любом компьютере, нужен жирный сервер, а не
жирный клиент.

Я работаю в госучреждении и основной язык разработки FoxPro for DOS.
Можно конечно использовать Pascal (раньше использовался) или C,
но зачем извращаться.
VisualFox for Win нельзя использовать, так как говорят нет
клиентов для его использования, довольная быстрая машина считается
Pentium166/8Mb.

Все попытки использовать Linux/Postgre/Perl/Apache натыкаются на
заявления начальника, что нет людей знающих такие технологии
(кроме меня конечно).

DBF - редкое дерьмо, особенно при подключении c нескольких машин.
Часто бывают повреждения файлов. Тупость пользователей и доступность ими для изменения любых данных просто убивает. Изменение - это
удаление файлов DBF целиком.

Установка нового, даже очень крутого сервера обойдется дешевле,
чем покупка 100 клиентских компов :))

M.

привет очередной анонимус

>Зачем продлевать жизнь х#@не.

Опять по кругу - с клиппером уже разобрались - почитай весь тред

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

Перенеси на линукс+DosEmu и забудешь про эту проблему

> Web-based работает на любом компьютере, нужен жирный сервер, а не жирный клиент.

Вот именно так и будет работать только не по http а по telnet/ssh именно на жирном сервере и тощих клиентах и индексы лететь не будут

> DBF - редкое дерьмо, особенно при подключении c нескольких машин. Часто бывают повреждения файлов. Тупость пользователей и доступность ими для изменения любых данных просто убивает. Изменение - это удаление файлов DBF целиком.

Блин ! при чем тут DBF ? это технология файл-сервер - где от каждого чиха любой машинки отлетают индексы

> Установка нового, даже очень крутого сервера обойдется дешевле, чем покупка 100 клиентских компов :))

Я и говорю - ставь линукс+DosEmu или другой терминал-сервер и живи ! А про клиипер+DBF забире слова обратно - они в этом не виноваты.

Про PL/SQL, хранимые процедуры, тригеры, server side java

Слышал. Действительно, без оных порой(и наверное часто) тяжело. Факт. Но этим можно пользоваться ТОЛЬКО для манипуляции SQL данными (мнение сисадмина) - . Аргументирую (я видел oracle/unix, об этом и говорю). Когда нибудь приходилось обращаться оттуда к НЕ базе данных (к примеру к внешнему файлу)? Попробуй разграничить права пользователей БД на эти самые файлы. Типа пользователю А файлы из каталога К, пользователю Б из Д и т.д. Куски сервера работают с одинаковыми привилегиями. В резольтате файл созданый СЕРВЕРОМ(для любого пользователя) читаем ВСЕМИ пользователями. Это хорошо?

А про PL/SQL предпочел бы не говорить - премерзкий язык(именно как язык) по сравнению с той же Java(хотя и она не пиво:-) И пока приличных server-side встроеных языков не видать :-((пока про оракл+ява ходят слухи про нестабильность)

про лимон транзакций в сутки -- я не знаю о каких транзакциях идет речь - если дашь раскладку по типам транзакций и размерам БД - позже скажу более точные цифры -- а сейчас провел небольшой эксперимент на клипе под линухом на селероне 400 - добавление 1М записей разной структуры БД - от 2 до 5 минут, чтение 1М записей всегда менее 1 минуты -- выборка 100 записей из 1М и их обработка - около 5 сотых секунды. Итого вся работа с БД укладывается в 10 минут машинного времени.

Я очередной анонимус :)

2Uri:
1. Языки для разработки бухгалтерии под линух - чем собсно python с библой для гтк/qt не подходит ? И прикручивание библы для доступа к СУБД собсно проблема небольшая. Конечно, 10 лет назад наверное этого не было, не буду врать, но ведь сейчас-то есть ? И согласитесь, разработчиков/тестеров/юзеров у python-а несколько больше, чем у клипа, не в обиду будет сказано.
2. Совершенно с Вами согласен - скорость работы бухгалтерского софта определяется на 90% скоростью доступа к данным.

Однако:
3. Я так и не понял, Вы говорите, что клип может не юзать dbf и согласны с тем, что это устарело. Ок, что тогда использовать, если отметается dbf (устарел) и sql (тормозит) ? Так чтоб быстро, надежно и т.д. и т.п. ? И желательно не в виде какой-то экзотической примочки ?
4. Использование терминал-сервера не есть изящное решение. Оно работает, не спорю, однако что делать если рабочее место графическое ? Знаете какой там трафик будет ? Все ж таки 21 век на дворе... 
5. Почему все молчат про трехзвенную модель ? Я вставлю свои пять копеек: сравнительно небольшой объем трафика, при нормально растущих руках возможно написание клиента с минимальными требованиями, причем довольно легко нарисовать скажем графическую и терминальную версии, если нужно. И параллелить сервер приложений можно, и безопасность сделать нормальную, и для критичных задач делается нормально.
6. Да, sql тормознее, чем БД с позиционированием. Однако учитывайте также время написания алгоритма сравнительно с построением select-а. Да, рука набита, пишется на раз, однако если таких запросов много, то имхо, конечно, но select изящнее. Учитываем также возможность кэширования однотипных запросов на продвинутых СУБД.
7. А чем собсно проблема - знать несколько языков ? С СУБД общаемся через sql, все остальное делаем на другом языке, а в критичных местах можно и с/c++ впихать...
8. Скорость работы СУБД на sql очень сильно зависит от правильности построения базы. Адекватная задаче структура таблиц, нормализация, правильно построенная система индексов и просмотров (view) - 70 процентов успешного выполнения задания.

Собсно мое имхо: клип - вещь очень хорошая и нужная, для написания софта локального применения. Если речь идет о скорости, надежности, обеспечении целостности данных, о больших объемах информации - я лично выберу sql-server под стать поставленной задаче. Если мне нужно будет крутить что-то небольшое в рамках 1-2 машин, то я подумаю о применении клипа.

Ох и написал,сорри :)

2Uri:
1. Языки для разработки бухгалтерии под линух - чем собсно python с библой для гтк/qt не подходит ? И прикручивание библы для доступа к СУБД собсно проблема небольшая. Конечно, 10 лет назад наверное этого не было, не буду врать, но ведь сейчас-то есть ? И согласитесь, разработчиков/тестеров/юзеров у python-а несколько больше, чем у клипа, не в обиду будет сказано.
2. Совершенно с Вами согласен - скорость работы бухгалтерского софта определяется на 90% скоростью доступа к данным.

Однако:
3. Я так и не понял, Вы говорите, что клип может не юзать dbf и согласны с тем, что это устарело. Ок, что тогда использовать, если отметается dbf (устарел) и sql (тормозит) ? Так чтоб быстро, надежно и т.д. и т.п. ? И желательно не в виде какой-то экзотической примочки ?
4. Использование терминал-сервера не есть изящное решение. Оно работает, не спорю, однако что делать если рабочее место графическое ? Знаете какой там трафик будет ? Все ж таки 21 век на дворе...
5. Почему все молчат про трехзвенную модель ? Я вставлю свои пять копеек: сравнительно небольшой объем трафика, при нормально растущих руках возможно написание клиента с минимальными требованиями, причем довольно легко нарисовать скажем графическую и терминальную версии, если нужно. И параллелить сервер приложений можно, и безопасность сделать нормальную, и для критичных задач делается нормально.
6. Да, sql тормознее, чем БД с позиционированием. Однако учитывайте также время написания алгоритма сравнительно с построением select-а. Да, рука набита, пишется на раз, однако если таких запросов много, то имхо, конечно, но select изящнее. Учитываем также возможность кэширования однотипных запросов на продвинутых СУБД.
7. А чем собсно проблема - знать несколько языков ? С СУБД общаемся через sql, все остальное делаем на другом языке, а в критичных местах можно и с/c++ впихать...
8. Скорость работы СУБД на sql очень сильно зависит от правильности построения базы. Адекватная задаче структура таблиц, нормализация, правильно построенная система индексов и просмотров (view) - 70 процентов успешного выполнения задания.

Собсно мое имхо: клип - вещь очень хорошая и нужная, для написания софта локального применения. Если речь идет о скорости, надежности, обеспечении целостности данных, о больших объемах информации - я лично выберу sql-server под стать поставленной задаче. Если мне нужно будет крутить что-то небольшое в рамках 1-2 машин, то я подумаю о применении клипа.

> 1. Языки для разработки бухгалтерии под линух - чем собсно python с библой для гтк/qt не подходит ?

Где эти проги ? Времени было вполне достаточно.

> И согласитесь, разработчиков/тестеров/юзеров у python-а несколько больше, чем у клипа, не в обиду будет сказано.

Без обид - нам пока естеров хватает - шлют глюки со всего света, уже примерно 200 адресов имеется. А сколько реально пользуется я вообше не представляю, знаю только то что в феврале утащили более 1000 копий, а в марте наверное будет в районе 2000.

> 3. Я так и не понял, Вы говорите, что клип может не юзать dbf и согласны с тем, что это устарело. Ок, что тогда использовать, если отметается dbf (устарел) и sql (тормозит) ? Так чтоб быстро, надежно и т.д. и т.п. ? И желательно не в виде какой-то экзотической примочки ?

Фишка номер 1 - какая половая разница гле лежат данные ? а если серьезно - то в зависимости от пожеланий админа бизнесдвижок должен уметь таскать данные откуда угодно - и чем больше поддерживаемых источников данных - тем лучше - с этим-то хоть согласны ?

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

Фишка номер 3 - использовать надо РАСПРЕДЕЛЕННЫЕ ВЫЧИСЛЕНИЯ - вообще-то этим всЕ сказано - но вот почему-то считают что это только распаралеливание работы клиента - однако я подразумеваю нечто большее

> 4. Использование терминал-сервера не есть изящное решение. Оно работает, не спорю, однако что делать если рабочее место графическое

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

> 5. Почему все молчат про трехзвенную модель ? Я вставлю свои пять копеек: сравнительно небольшой объем трафика, при нормально растущих руках возможно написание клиента с минимальными требованиями, причем довольно легко нарисовать скажем графическую и терминальную версии, если нужно. И параллелить сервер приложений можно, и безопасность сделать нормальную, и для критичных задач делается нормально.

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

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

И до кучи : назови пжлста пару-тройку серверов приложений с ценами и поддерживаемыми источниками данных. Для линукса конечно.

> 6. Да, sql тормознее, чем БД с позиционированием. Однако учитывайте также время написания алгоритма сравнительно с построением select-а. Да, рука набита, пишется на раз, однако если таких запросов много, то имхо, конечно, но select изящнее. Учитываем также возможность кэширования однотипных запросов на продвинутых СУБД.

А это тут совсем ни при чем - у сикеля тормоз совсем в другом месте. И меня например достает писать запросы :) хоть в клиппере хоть в сикеле - язык запросов вообще лишнее звено.

> 8. Скорость работы СУБД на sql очень сильно зависит от правильности построения базы. Адекватная задаче структура таблиц, нормализация, правильно построенная система индексов и просмотров (view) - 70 процентов успешного выполнения задания.

Проблема собственно вот в чем - берем туже накладную с 20 строками - как ты думаешь сколько потребуется запросов чтобы ее разложить по полочкам в готовом для употребления виде ?

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

Ну на пару-тройку с ценами меня не хватит, а вот 1 к примеру:
http://www.gnuenterprise.org/
Искать слово GNU Enterprise Application Server или GEAS.
Цену угадай. :-)
Oracle,DB2,Postgresql,mysql,разное odbc.

Там же forms+designer. 
Правда Reports только в proof-of-concept стадии.

Собственно к вопросу об инструментарии...

>Re: пару-тройку серверов приложений >Ну на пару-тройку с ценами меня не хватит, а вот 1 к примеру: >http://www.gnuenterprise.org/ >Искать слово GNU Enterprise Application Server или GEAS. >Цену угадай. :-) >Oracle,DB2,Postgresql,mysql,разное odbc.

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

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

>надо, но клинчи разводятся легко так как нет понятия "транзакция"

Ой! Т.е. про целостность данных мы просто можем забыть? :-)


>>Да и доступ из соседних приложений очень легко реализуется. >У него >>же енжин прям в dbf файле - само все отслеживается >:-/

>К чему это ? мы продолжаем обсуждать чистый клиппер ? А я уже давно
А что, есть еще грязный клиппер? ;-)
>закончил :)

Не, так вы таки не уходите от ответа то.
dbf - типа уже не, а sql тоже не, а что же?
Все предыдущее читал, ответа не увидел.

>А кто сказал что не хватает "скорости доступа к данным" причем в >контексте "сикель" ? Вы уж там между собой договоритесь "или или".

Говорил не я. И каким, простите, хреном я должен с кем-то еще договариваться. Тут народу много, а только @itk.ru :-)

>Легко. И могу показать сетюку в 350 машин с примерно 150 прогами >писанными на клиппере. Причем не мной писанными и я к этой конторе >имею только "консультационное" отношение. И как писал очередной >анонимус - p200/16 считается жирным клиентом :) Да еще и arcnet жив, >причем самый длинный хвост - около 4км

И все это взаимодействует, т.е. 150 программ друг с другом.
Ой, не смешите :-)
Вы привели бы пример интеграции разного софта на основе клиппера
или клиппера самого с собой, но чтоб не через жопу( i.e. базу)
а на уровне объектов.

>>А то грустно :-)

>Грустно то что "не слышал где звон, зато наехал".

Я, конечно, понимаю Ваше высокомерие, тем более, что некогда
имел несчастье общаться с бывшим работником вашей компании, подвизамшимся этак года два назад на заводе пластмасс.
У вас он тоже заразился, жаль ума это не прибавило ;-)

В общем, по мне так все ясно, можно и не продолжать... :-)

>>надо, но клинчи разводятся легко так как нет понятия "транзакция"

> Ой! Т.е. про целостность данных мы просто можем забыть? :-) ОЙ ! а я про это типа и не знал ДА ? Это типа целостность можно только на сикеле получить ? да что вы говорите !!!! целостность можно лекго получить на любом сервере кроме файл-сервера. И всего-то приложить некоторое усилие со стороны рук и мозгов.

>>Да и доступ из соседних приложений очень легко реализуется. >У него >>же енжин прям в dbf файле - само все отслеживается >:-/

И таки и не понял к чему в данном утверждении была улыбочка - да и само утверждение тоже не понятно совершенно.

>>К чему это ? мы продолжаем обсуждать чистый клиппер ? А я уже давно >А что, есть еще грязный клиппер? ;-)

Есть - клиппер проги под досэмулятором - это уже не клиппер и та куча недостатков которая тут вечно обсасывается в данной конфигурации отсутсвует. Еще есть клиппер с библами и еще есть клип,alaska,flagship,harbour,ADS, и много других примочек. так о чем ваше утверждение ? о DBF ? clipper ? или о чем-то своем ?

>>закончил :)

>Не, так вы таки не уходите от ответа то. >dbf - типа уже не, а sql тоже не, а что же? >Все предыдущее читал, ответа не увидел.

"распределенные вычисления" - это не ответ ? ну извиняй котовых продуктов в такой технологии еще нет, а выкладывать как ЭТО сделать я пока не собираюсь - во первых некому (тут еще пока DBF приравнивают ко всем проклятым глюкам файл-сервера) а во вторых вам это не надо судя по разговору - вам же сикеля достаточно .

>>А кто сказал что не хватает "скорости доступа к данным" причем в >>контексте "сикель" ? Вы уж там между собой договоритесь "или или".

>Говорил не я. И каким, простите, хреном я должен с кем-то еще >договариваться. Тут народу много, а только @itk.ru :-)

Значит вам хватает ? ну и хорошо - я рад, а мне не хватает.

>>Легко. И могу показать сетюку в 350 машин с примерно 150 прогами >>писанными на клиппере. Причем не мной писанными и я к этой конторе >>имею только "консультационное" отношение. И как писал очередной >>анонимус - p200/16 считается жирным клиентом :) Да еще и arcnet >жив, >причем самый длинный хвост - около 4км

>И все это взаимодействует, т.е. 150 программ друг с другом. >Ой, не смешите :-)

Большинство, по крайней мере есть с десяток таблиц, которыми пользуются абсолютно ВСЕ проги.

>>Вы привели бы пример интеграции разного софта на основе клиппера >>или клиппера самого с собой, но чтоб не через жопу( i.e. базу) >>а на уровне объектов.

А вы приведите аналогичный пример на сикеле но только не через sql-выражение. А на уровне объектов уже работает первая прога - в ней вообще нет ни слова про DBF да и про sql тоже :) какой модуль доступа к данным прицепишь - тем и будет пользоваться.

>>А то грустно :-)

>>Грустно то что "не слышал где звон, зато наехал".

>Я, конечно, понимаю Ваше высокомерие, тем более, что некогда

Какие вопросы - такие и ответы - я лично на вопрос "который час" отвечаю именно "третий" или "пятый" - и если для кого-то это считается высокомерием - то для меня норма жизни. >имел несчастье общаться с бывшим работником вашей компании, >подвизамшимся этак года два назад на заводе пластмасс. >У вас он тоже заразился, жаль ума это не прибавило ;-)

Быстро у вас однако выводы делаются. И какое отношение к себе вы желаете увидеть после этих слов ?

Догадываюсь кто именно - но увы он не долго у нас продержался и поэтому заразится от нас не мог.

> В общем, по мне так все ясно, можно и не продолжать... :-) ну тоже результат - пусть даже и такой :)

> Я, конечно, понимаю Ваше высокомерие, тем более, что некогда > имел несчастье общаться с бывшим работником вашей компании, > подвизамшимся этак года два назад на заводе пластмасс. > У вас он тоже заразился, жаль ума это не прибавило ;-)

> В общем, по мне так все ясно, можно и не продолжать... :-)

Значит так долбаный ананимус, моя фамилия Куликов, и по должности я пока директор ИТК.

Можете сколько угодно спорить о технических вопросах, но попрошу не лезть в личный состав нашей компании, тем более по знакомству с такой жертвой аборта как Минеев (он же Чумчаев) Андрей Анатольевич 40 лет, средний рост худощав, носит очки представляется специалистом по юниксу и бухгалтерским программам, попрошу выводов не делать. По той простой причине, что это говно наделало нашей конторе столько неприятностей, что по законам мужской порядочности ему просто морду бить мало.В штате нашей конторы он числился года четыре назад не более полугода. Должен был заниматься маркетингом. Первый же его маркетинг вылился в то, что он пришел на Буммаш, представился не работником ИТК а директором советско-японской фирмы которая разработала крутую систему. Этой "системой" была наша разработка почившей в бозе YUDB. На тот момент и не было речи вести речь о ее коммерческом использовании. Через неделю после его появления на заводе (о котором я не знал) у нас была встреча с руководством ВЦ. Где помимо прочего я упомянул о том что мы работаем над сетевой СУБД. Представьте себе ситуацию когда нач.ВЦ меня спросил знаю ли я такого Андрея Анатольевича и выложил описание нашей YUDB! Задумайтесь над ситуацией! Мог ли вообще нормальный человек такое сделать! Этот человек наделал много проблем нашей конторе. Клип затормозился на полгода по его вине. И вот даже теперь эта сволочь нам подлянку делает. По его морде судят о нашей конторе! Значит два года назад он бравировал тем что он бывший работник ИТК? Он наверняка говорил что программисты у нас классные, но вот директор козел? А он не говорил по какой причине я выкинул его из гостиничного номера в одних трусах? Нет не за Буммаш, это была уже другая подлянка. Почище первой.

Предупреждаю всех, кто будет иметь с ним дело или уже имеет дело через мыло. Этот человек к нашей конторе никакого отношения не имеет. Более того, нашей конторе он крайне неприятен. Он может распространять наши dosemu или патчи выдавая за свои.Хай с ним не жалко. Значит так. Г-н Минеев, я знаю что ты сейчас читаешь эти строки. Ты просто не можешь их не читать. Даже сейчас ты продолжаешь говнить нам. Делай выводы.

А вы герр анонимус берите ящик пива и к нам в контору. А то сами придем такие разборки наведем...

Мда.. тут уже личные разборки идут. Я никакого отношения к вышеупомянутому гражданину не имею. И в общем об Itk узнал на этом форуме.

Я сам никогда не писал на клиппере (будем называть это старым клиппером) да и врядли буду, но видел немало прог писаных в связке с досом, образца 93-96 годов. Причем громадными эти базы не назовешь. И даже будучи перенесенными на современное железо тормозят они по страшном при числе клиентов >1. Ну да ладно, бум считать что это все недостатки "старого" клиппера.

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

Но сметы на проект калькулировать немного умею, как тут заметили, жирный сервер стоит не так уж и много в общей сумме проекта. Клиенты... да вообще без разницы какие. Вполне достойно четверки с 16 метрами смотряться.. Абы win9x запускался. Для особо продвинутых вообше есть терминалы. Оракловские лицензии стоят денег кнечно не малых, но весьма посильных, если клиент кнечно не пирожками торгует. Программеры, да не дешивы, но квалифицированному програмеру пофиг что писать(кстати без предрассудков linux vs win32), так что к делу относиться только скорость написания прикладухи и дальнейшая чистка багов. Так что в общем стоимость решения скорее всего будет ниже.

А вообще ситуация напоминает анектдот. Все рота идет не в ногу, один прапорщик в ногу. Это я о 1000 between 2000 копиях. Надеюсь я правильно понял ваши слова о том что с вашего сайта было утащено около 1000 копий. Из этого следует что ознакомится с вашими трудами решило (пока) около 1000 разрабочиков.. И далеко не все что-то напишут. Я думаю, что не открою вам глаза если скажу, что разработчиков пользующих SQL на порядки больше, а количество инсталяций различных SQL серверов соизмеримо с количеством постоянных хостов в инете.

P.S. Буду рад, если количество пользуюших ваш продукт будет увеличиваться, а в продаже рядом с коробками с надписью www.1C.ru появятся коробки с вашим URL.

>Значит так долбаный ананимус, моя фамилия Куликов, и по должности я >пока директор ИТК.

Значит так, долбаный г-н Куликов. Моя фамилия Мелехов и я по должности
ведущий инженер ОАО Белкамнефть.


>А вы герр анонимус берите ящик пива и к нам в контору. А то сами придем >такие разборки наведем...

Чего ?
:-)

1000 только за ФЕВРАЛЬ и только с нашего ftp (а есть еще два зеркала, но статистика оттуда неизвестна - есть только сведения за декабрь - так вот в декабре только на зеркале в Иркутске было вытащено примерно столько же сколько и из homeftp), в марте уже больше февральской цифры, линксрунетовский счетчик на клиповской странице показывает более 30000, честно говоря для такой конторы как малюсенькая ИТК и абсолютно неновостного сайта - цифиря не маленькая. Это при том что клип стал анонсироваться всего полгода назад - до этого времени мы вообще не лезли на такие форумы как тут.

К вопросу о "прапорщике" хочу сказать вот что - большинство бывших клипперистов не живут в линуксах и не лазят по линуксовым конференциям - все эти цифири показывают что ЕСТЬ МНОГО ЛЮДЕЙ КОТОРЫМ ИНТЕРЕСЕН КЛИППЕР ПОД ЛИНУКС, если сюда еще приплюсовать тех кому нужен клиппер под винду - я только в нашем городе знаю (не лично конечно) около сотни программеров которые до сих пор пишут на клиппере/фоксе: - буммаш 15, удмуртнефть -25, мехзавод 30, ижсталь -20 , сколько на ижмаше не знаю, но там тоже есть немало программ на xBase. И из этой сотни только примерно 5 знают о клипе (и о возможностях линуха тоже -здесь кстати и скрывается проблема малораспространенности линуха)- это те которые понимают что даст им линукс - остальные либо вообще ничего не знают либо им просто по барабану - лишь бы ЗРП платили вовремя.

Я не могу сказать точно сколько программ работает на этих заводах, всех их не знаю, неплохо знаю только п1 и п3 и есть сведения из п2 и по этим данным получается что на каждого программера приходится от 3 до 15 написанных программ - умножить сможешь ? Под 1000 xbase программ только в нашем городе !!! Не знаю как в других городах, но что-то мне слабо верится что только ижевск подсел на xbase. Пишут-то нам отовсюду причем и из банков и из крупных контор, а не только "подельщики". И не только из России, а со всего мира, например один китаец сообщил что у него в конторе 3000 программ на xBase.

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

И кто тут "прапорщик идущий не в ногу" ? У вас свои данные - у нас свои. Незнание альтернативной информации - это не причина для категорических выводов.

P.S. шеф конечно перегнул палку - но я его понимаю - делать выводы из одного факта - дело людей с "минимальной конфигурацией" - а вот орать при этом на весь рунет - тут оба себя показали с лучшей стороны.

uri@itk.ru

2Uri:

1. Все-таки так и не услышал ответ на вопрос касательно sql vs clip, поэтому повторю: Вы говорите, что dbf вроде как старо, а sql - отстой. Повторяю вопрос: что за модель данных Вы предлагаете использовать ? Какой софт для этого нужен ? Где его можно взять ? Сколько он стоит ? Насколько серьезно ведется его сопровождение ? Кто им уже пользуется ? Я так понимаю, что имеется в виду некая сетевая база данных в исполнении Вашей фирмы. Что это за зверь - неизвестно, насколько я понял, задача еще не дописана, поэтому говорить о ее характеристиках пока невозможно. Вспомним также из истории СУБД вымершие ныне сетевые, объектные и прочие типы БД, про которые сейчас уже никто и не слышит... Кто даст мне гарантию, что это будет без тормозов, надежно и так далее ? Никто (щас кто-нибудь начнет орать о том, что за надежность надо платить деньги :). Правильно, я заплачу за оракл в таком случае:) )
2. Бизнес-приложения, написанные на python & gtk есть :). По крайней мере я их пишу :). Конечно, это не ответ, однако мы говорим о принципе, я правильно понимаю ? естественно, количество софта под клиппер несораизмеримо больше... Однако и история языка вроде как немалая, 15 лет все-таки ? В то же время софта на sql-серверах тоже вроде как немало.
3. Я повторюсь. Да, базы на локальных файлах быстрее. За счет "низкоуровневого" доступа. Однако не будем отрицать и присущие им недостатки - тот же "клинч", про который Вы пишете, реально может быть и там, ибо если несколько процессов будут лезть в одно и то же место базы, то тут уже ничего не поделаешь - кому-то придется подождать. Конечно, можно сделать целостность, скорость, обеспечение нормальной работы с большими объемами данных _везде_, даже на уровне ассемблера, однако во сколько это обойдется ? И насколько мобильным будет такое решение ? Посмею поспорить, что на сопровождение sql-софта уйдет меньшее время, и решение на базе него будет мобильнее и "живучее", чем клиперское за счет абстрагированности от механизмов доступа к данным.
4. С каких пор недостатком проекта считается использование нескольких языков ? Мне не претит использовать sql в качестве языка доступа к СУБД, python для написания клиента, c/c++ в некоторых критичных местах сервера приложений, perl для генерации отчетов...

5. Касательно накладной в 20 строк. Случай далеко не типичен и может быть вызван неверным проектированием системы. Однако, давайте для интереса предположим, что каждая строчка должна отобразится на базу в отдельную таблицу. Причем с неким контролем состояния системы - либо все изменения пройдут одновременно, либо они не пройдут вообще. Мне предлагается сделать это на основе sql-сервера. Возьмем postgreSql:
begin;
insert into bla_bla_bla values(<данные накладной>);
<некие вычисления - баланс, определение сумм>
update balans set bla_bla_bla;
... <подобные блоки> ...
end;
Для скорости вычислений я это напишу на с++, и собственно вычисления оптимизирую, чтоб основные тормоза были только на sql. Тогда на реальной задаче, только там не 20 строк, а 14 с подсчетом баланса и контролем целостности, у меня получается вполне приемлимая скорость - конечно, я не претендую на истину в первой инстанции, но этот код будет гарантированно работать, и я не буду отвлекаться на "клинчи", и сопровождать такой код имхо удобнее, чем клиповый - он сравнительно с моим должен содержать контроль операций, а у меня это делается на уровне СУБД. И делать я это буду на сервере, а не на клиенте, так что трафик у меня будет никакой. А еще я отключу немедленную фиксацию данных на диске... А определенные части задачи для пущей крутизны прошью прямо в СУБД, и напишу их на с... И индексов наделаю нужных... Так где именно у меня тормоза ?

5. Графический терминальный клиент подгружает трафик порядочно сравнительно с терминальным. Вы уверены, что Ваша сеть потянет этот трафик ? Кроме того, достаточно ресурсов требуется и от терминал-сервера, и для 20-30 клиентов Вам потребуется нехилое такое железо. Сравнимо с ресурсами для сервера приложений разница будет заметна.

6. Никто не разрабатывает бизнес-приложения в расчете сразу на несколько реализаций источников данных. Нет смысла и очень много гимора. Да, каждый sql-сервер имеет свой прибамбас. Однако ведь и каждая локальная СУБД работает по-своему ? Вопрос совместимости имхо неактуален. Покажите мне, где это нужно ?

7. А зачем Вам приводить примеры пары-тройки приложений ? А чем не устраивает CORBA ? Это не сервер, но на основе свободной corba-библиотеки (пробовал OMNI, MICO, ORBachus) вполне реально наваять сервер приложений исключительно под задачу... Там собсно код сервера объемом строчек в сто... Осталбное - реализация конкретной задачи. И распараллеливается кстати тоже...
Собственно сервер приложений можно вообще наваять на чем угодно, вопрос в том, насколько удобным будет это решение... А как насчет различных кусков сервера, писаных на разных языках ? Где скрипт, а где и бинарник ? Зачем повторять пройденное ?

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

ну во первых - мне искренне жаль что техническое обсуждение превратилось в безобразие. Если еще осталось желание обуждать ТЕЧНИЧЕСКИЕ вопросы - давайте продолжим.

> 1. Все-таки так и не услышал ответ на вопрос касательно sql vs clip, поэтому повторю: Вы говорите, что dbf вроде как старо, а sql - отстой.

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

> Повторяю вопрос: что за модель данных Вы предлагаете использовать ?

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

> Какой софт для этого нужен ? Где его можно взять? Сколько он стоит?

Нету. Если бы был этот софт да еще лучше под маркой Оракле - данного обсуждения не было бы вообще.

> Я так понимаю, что имеется в виду некая сетевая база данных в исполнении Вашей фирмы.

Я этих слов не говорил - это к тому чтобы потом не валили на меня все шишки.

> Вспомним также из истории СУБД вымершие ныне сетевые, объектные и прочие типы БД, про которые сейчас уже никто и не слышит...

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

> Кто даст мне гарантию, что это будет без тормозов, надежно и так далее ?

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

"надежно" - дает большое кол-во тестеров и квалификация разработчиков

"так далее" - дает торговая марка.

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

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

> Конечно, можно сделать целостность, скорость, обеспечение нормальной работы с большими объемами данных _везде_, даже на уровне ассемблера, однако во сколько это обойдется ?

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

>И насколько мобильным будет такое решение ?

Зависит от квалификации разработчика и его добросовестности. И в его же компетенции сделать софт дешевым и мобильным.

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

Тоже попытаюсь поспорить - меня в сикеле буквально бесит то что СВЯЗИ МЕЖДУ ТАБЛИЦАМИ описываются в бизнеслогике и при любой перестройке структур таблиц надо править неизвестное кол-во сикель запросов. Это в принципе решаемо - но тогда бизнеслогика должна стать "отвязанной" от структур и конечных сикель выражений - а это уже близко к ОО-представлениям и сразу же возникает вопрос (по крайней мере у меня) "а почему собственно для общения между клиентом и сервером обязательно использовать сикель ?" Здесь вообще лучше использовать такой язык который понимается без синтаксического анализатора и желательно не требует оптимизации планов выполнения.

>4. С каких пор недостатком проекта считается использование нескольких языков ? Мне не претит использовать sql в качестве языка доступа к СУБД, python для написания клиента, c/c++ в некоторых критичных местах сервера приложений, perl для генерации отчетов...

Я разве в явном виде писал о том что это недостаток ? У кого-то были ассоциации на тему "доставка из пункта А в пункт Б" - я просто добавил что сикель в данном случае "телега требующая тягача в виде С++". Телега в данном случае - сикель, тягач - С++, сколько языков используется в проекте вообще-то по барабану, лишь бы они красиво стыковались между собой без вызова лишних bash при вызове подзадач и тюдю.

>5....... Касательно накладной в 20 строк. Случай далеко не типичен и может быть вызван неверным проектированием системы. Однако, давайте для интереса предположим, что каждая строчка должна отобразится на базу в отдельную таблицу. Причем с неким контролем состояния системы - либо все изменения пройдут одновременно, либо они не пройдут вообще.............. И делать я это буду на сервере, а не на клиенте, так что трафик у меня будет никакой. А еще я отключу немедленную фиксацию данных на диске...

Ошибка в представлениях об аналитическом учете. я же в той самой мессаге написал внизу (придется повторить и очень прошу прочитать внимательно и лучше два-три раза):

-------------- begin

Проблема собственно вот в чем - берем туже накладную с 20 строками - как ты думаешь сколько потребуется запросов чтобы ее разложить по полочкам в готовом для употребления виде ?

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

-------------- end и еще раз прочитайте

А в этой фразе заложена бомбочка - так вот открываю страшный секрет :) обработка одной строки накладной потянет за собой от 1000 до 10000 транзакций в зависимости от требований к АНАЛИТИЧЕСКИМ СПОСОБНОСТЯМ ИС.

Теперь пожалуйста скажи мне сколько времени займет выполнение 20000 - 200000 транзакций в самых оптимизированных суперпрограммером режимах на самом супернастроенном и навороченном сервере ?

Теперь представь себе что таких документов (не только накладных) за сутки приходится оформлять несколько тысяч ?

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

>6. Никто не разрабатывает бизнес-приложения в расчете сразу на несколько реализаций источников данных. Нет смысла и очень много гимора. Да, каждый sql-сервер имеет свой прибамбас. Однако ведь и каждая локальная СУБД работает по-своему ? Вопрос совместимости имхо неактуален. Покажите мне, где это нужно ?

Изначально разговор начинался "итк vs 1С" !? Нужно это именно для того чтобы удовлетворять потребности конкретного клиента. Ну приходишь к клиенту и пытаешься ему вставить ИС на Оракле, а у него уже есть DB2 к примеру - и такая вполне лицензионная и спецы подготовленные и тюдю. Ну и зачем ему Оракл. Или допустим за каким лешим нужен тот же оракл в конторе с 10 рабместами - им и МуСикеля вполне достаточно и по цене более приятно выглядит. ну а для тех кто работает дома в одиночку - им что продолжать на 1С работать ? А в данном случае и обычного DBF хранилища по самые уши достаточно.

> 5. Графический терминальный клиент подгружает трафик порядочно сравнительно с терминальным. Вы уверены, что Ваша сеть потянет этот трафик ?

не буду категорически настаивать, но видел собственными глазами и работал за X-терминалом который стоял через радио-канал и при этом скорость канала не превышала 20k в сек. И есть некоторые сведения что можно вполне сносно работать даже через модем 14400. Вот этого своими глазами не видел, но думаю что вполне реально.

>Кроме того, достаточно ресурсов требуется и от терминал-сервера, и для 20-30 клиентов Вам потребуется нехилое такое железо. Сравнимо с ресурсами для сервера приложений разница будет заметна.

Ну есть у наших клиентов сервера с одновременно работающими 35-50 пользователями причем под DosEmu. Клип-программы эффективнее досовской проги ну где-то раза в два (в текстовом режиме). Есть сведения от тестеров что давали поработать в тестовом режиме более 60 пользователям на одном сервере pIII-600. Обратно в новеловскую сетюку они шли с большой неохотой. Что там за задачи точно не знаю - что-то типа приема оплаты за электроэнергию.

> 7. А зачем Вам приводить примеры пары-тройки приложений ?

Просто из любопытсва можно спросить ? Может я просто чего-то не знаю и хочу пополнить свой багаж знаний.

> А чем не устраивает CORBA ? Это не сервер, но на основе свободной corba-библиотеки (пробовал OMNI, MICO, ORBachus) вполне реально наваять сервер приложений исключительно под задачу... Там собсно код сервера объемом строчек в сто... Осталбное - реализация конкретной задачи.

А тиражироваться она потом будет ? и чтоб не требовала программера с хорошей квалификацией ?

> И распараллеливается кстати тоже...

Да по барабану что клиент будет распаралелен - все равно 200000 запросов полетит в один сервер - только многозадачно :)

> Собственно сервер приложений можно вообще наваять на чем угодно, вопрос в том, насколько удобным будет это решение... А как насчет различных кусков сервера, писаных на разных языках ? Где скрипт, а где и бинарник ? Зачем повторять пройденное ?

А тиражирование ? А обслуживание ИС малоквалифицированными фрайчайзерами ? Гдеж на всех набрать столько толковых программеров знающих по нескольку языков ?

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

С этим полностью согласен. Но непонятно почему это должны быть РАЗНЫЕ ПРОДУКТЫ писанные на разных языках даже при том что вылезли из рук одного разработчика и имеют одну и туже конечную цель но только в разных масшабах.

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

А вот с этим нет. Масяню видел ? Она там "офигительный набор отверток дарила своему другу". Предпочитаю иметь вот именно такой "офигительный набор отверток" чтоб и в часах можно было поковыряться и при необходимости закрутить шуруп в бетонную стену без использования бетонодробилки.

2Uri:

1. Масяня дарила _несколько_ инструментов. Пусть в виде набора. А одной и той же отверткой ковырять часы и на стену чего-то вешать... И набор отверток не обязательно должен быть от одного производителя - не к месту будет упомянут М$ :)

2. Да, согласен, все запросы многозадачно пойдут на один сервер СУБД. Однако, есть ли этому альтернатива ? Какая ?

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

4. Насчет 60 телнет-клиентов - верю, однако настаиваю на том, что графический терминал-сервер скушает немеряно ресурсов сравнительно с сервером приложений и отдельно стоящим графическим тонким клиентом.

5. Пришел я к клиенту с целью впарить ему свою суперсистему под оракл, а у него db2 стоит... Однако если бы я пришел ему впаривать свою суперсистему на другой СУБД, а у него уже есть более другая, то ты окажешься в той же ситуации ? А если мы будем делать какие-то прокладки и компенсаторы, то получим такой гимор...

6. Куча транзакций в навороченной системе на локальной БД реализуется кучей кода, который делает вещи, аналогичные sql-серверу. Разница только в том, что в случае sql это делает сервер автоматом, а на локальной базе это делает программер, который может сделать это лучше, ибо знаком с частными случаями. Однако - в случае изменения системы в моем случае придется переделывать кучу запросов, а вам - переписывать кучу кода. Кому что больше нравится...

7. Над темой "как отразить объекты системы на субд прозрачно" сломано много копий, и насколько я знаю, еще никто не вывел более-менее приемлимого решения...

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

9. Сложность системы легко скрывается от персонала - просто можно им сказать: вот так вот пишется плагин на этом языке, вот так - на этом, а вот так - на этом. Выбирай, чего знаешь, то и делай. За это собсно я и уважаю corba - сервис может быть написан на чем угодно, важно чтоб он имел определенные параметры, а что творится внутри - это его проблемы.

10. да, к sql нужен "тягач", ну не обязательно на с/с++, однако - этот тягач более-менее универсален и скрывает от меня механизм оптимизации и выполнения запросов. И это дает мне определенную свободу действий и возможность больше времени уделить другим проблемам. Конечно, при построении большой системы я на каком-то этапе получу проблемы, однако ведь и тут есть выбор...

Вообще, похоже мы говорим об одном и том же, только по-разному :).
Я не говорю, что sql есть панацея от всех проблем, однако какова реальная альтернатива sql && локальным базам ? Имхо пока стоит выбирать одно из двух, и выбирать на основе определенной задачи - где чего лучше подходит...

Насколько я понял, тебе нравится клип за то, что там все можно оптимизировать до небалуйся. Да, sql-сервер в этом плане оптимизировать несколько сложнее. Однако это ведь не означает, что клип после этого - панацея ? Ведь детальная оптимизация нужна далеко не всегда. Всякому инструменту - свое применение, и только.

Да уж, наворотили обсуждений :)

Не проще ли такие объемы на мыло перевести, если интерес появился и додавить друг дружку так охота? Ну а Куликов конечно дал маху :( Сидел вот щас и все перечитывал тему от начала до конца, так прям глаза резануло. Хотя руководить чисто программистской конторой (да еще такой:) в течение 12 лет - не каждому по силам, и на нервы влияет пагубно :(

А вообще много споров здесь - бессмысленные на мой взгляд. Похоже на разговоры верующих с атеистами. Одной программы (или одного решения) на все случаи жизни в природе просто нет. Стрелять из пушки по воробьям или бороться с ораклом силами нескольких человек - абсурд. Clip - классная вещь, но только для определенного круга задач. А обвинять продукт в том, что он неизвестен и поэтому дерьмо - глупо. Как говорится, "не учите жить, лучше помогите материально". Где-то наверху было про энергию этих мужиков, так вот я ее не по наслышке знаю, и думаю, что ее хватит на раскрутку clip'а.

Сергей Розенфельд, технический директор ОАО "УНПП НИПИнефть", бывший сотрудник ИТК :)

> 2. Да, согласен, все запросы многозадачно пойдут на один сервер СУБД.

Хотелось бы это закрепить и обратно не возвращатся. Формулирую : в файл-сервере узкое место - сетка, в терминал-сервере узкое место процессоры, в клиент-сервере - сервер БД. Останавливаемся на этом тезисе как на аксиоме и больше к этому вопросу не возвращаемся, а то тред растет и сдвигов нету.

> Однако, есть ли этому альтернатива ? Какая ?

Я уже говорил - РАСПРЕДЕЛЕННЫЕ ВЫЧИСЛЕНИЯ, а решений готовых чтоб прям щаз попробовать - увы нету.

> ....

чтоб не разводить длинный флейм покоцал непринципиальные места

>5. Пришел я к клиенту с целью впарить ему свою суперсистему под оракл, а у него db2 стоит... Однако если бы я пришел ему впаривать свою суперсистему на другой СУБД, а у него уже есть более другая, то ты окажешься в той же ситуации ?

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

> А если мы будем делать какие-то прокладки и компенсаторы, то получим такой гимор...

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

> 6..........

сливаю в 7. Так как они просто не разделимы.

>7. Над темой "как отразить объекты системы на субд прозрачно" сломано много копий, и насколько я знаю, еще никто не вывел более-менее приемлимого решения...

Потому-что все пытаются реализовать ООБД по типу СикельБД - тюею по запросно-ответному типу. Придумывают OQL,XQL,.... и пытаются отобразить их на объекты, а объекты на таблицы. Поверх всего этого еще и препроцессоры, которые по описанию объектов генерят C++ сырцы. И стоит только вмешаться в любое место как это все хозяйство начинает безбожно глючить. А беда-то в том что ЯЗЫК ЗАПРОСОВ здесь как пятое колесо. Не в том смысле что выкинуть все сикели на хрен - хранить объекты где-то придется, а именно в том смысле что нельзя к объектам обращатся как к таблицам. Не терпят они над собой никаких ЗАПРОСОВ - это противоречит их сути.

Каждый объект самостоятельная сущность, которая живет по своим правилам и выполняет свои функции/методы. И никакой язык запросов не может снаружи определить какие конкретно объекты подходят под выражение запроса - это может решить только сам объект и никто другой - отсюда вывод - оптимизация по индексам летит к чертовой матери. И сикель-сервер превращается в обычную хранилку неиндексированных данных - тут вообще проще в текстовом файле хранить, и есть реализации ООБД на XML-формате. Увы ссылку не помню.

А решение ЕСТЬ. И этому решению по барабану где хранить объекты, сикель-сервер тут имеет только одно преимущество - вроде как у хороших серверов надежность хранения данных выше чем у файловых систем. А все остальное у сикеля только недостатки.

>8. Я очень сильно сомневаюсь, что в крупной ит-системе необходимо сделать кучу операций сразу, причем много. Это говорит о том, что с системой что-то не так...

Это говорит о том что вы еще не нарывались на прожорливых до информации руководителей. Те руководители которые принимают решения только по одному параметру "остаток на расчетных счетах" я в расчет не принимаю - их время уже заканчивается.

> А аналитические способности ИС можно выразить и по другому: - ведь необязательно вести аналитику в той же базе на той же машине. - ведь необязательно вести аналитику в базе вообще - ведь необязательно просчитывать аналитику именно сейчас. - есть еще и комбинированные решения.

Не пройдет ни один из этих пунктов - любое из них - это просто частичное решения из-за отсутсвия каких-либо ресурсов. ИС она тогда ИС когда работает в реальном времени. Зачем руководителю знать что до банкротства осталось 2 дня если на него уже подали в суд ? Зачем утром знать о том что товар закончился еще вчера в обед ?

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

> 9. Сложность системы легко скрывается от персонала

Не надо скрывать сложность системы - сложность не надо создавать. Система должна быть проста и понятна даже для малоквалифицированного персонала. И в этом ОО очень хорошо помогает.

> 10. да, к sql нужен "тягач", ну не обязательно на с/с++, однако - этот тягач более-менее универсален и скрывает от меня механизм оптимизации и выполнения запросов. И это дает мне определенную свободу действий и возможность больше времени уделить другим проблемам. Конечно, при построении большой системы я на каком-то этапе получу проблемы, однако ведь и тут есть выбор...

А мы их уже получили и выбора НЕТ.

> Насколько я понял, тебе нравится клип за то, что там все можно оптимизировать до небалуйся. Да, sql-сервер в этом плане оптимизировать несколько сложнее. Однако это ведь не означает, что клип после этого - панацея ?

Я этих слов (про панацею) не говорил и не надо мне их приписывать. Клипу учить не надо - xBAse знают достаточное кол-во программеров и есть куча литературы и преподов. И главное - на xBase пишут именно бизнеспрограммеры а не вебмастеры и учить их азам бухучета не придется. Это очень даже неплохая альтернатива фрайчайзерной сети 1С. И еще неизвестно что лучше - опытные проверенные годами волки или неоперившиеся студенты.

Ну вы и сцепились Кстати слабое место dbf больше сами файлы и индексы доступ к которым имеет кто угодно и как угодно что касается морды к базам то clipper удобнее добавил запись все видят в SQL надо делать обновления не совсем понятно как и когда когда много пользователей у clippera проблемы а уж если чтото падает .... что касается программистов то каждый второй кто занимается компьютеризацией российской действительности работает или c clipperom или с foxpro john

>Ну вы и сцепились Кстати слабое место dbf больше сами файлы и индексы доступ к которым имеет кто угодно и как угодно

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

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

Я уважаю создателей Clip, прежде всего за экзистенциальную волю.
Но на мой взгляд, язык xBase пошел по неверному пути еще в 1987-м.
Изначальный язык был динамическим, гибким и простым. Он мог бы (и
должен был) развиться в сторну "скриптовых" языков (Tcl, Python, Perl),
при этом стать многоплатформным, стандартным и открытым.

Вместо этого создатели Clipper завели его в эклектичное болото
"полустатических" языков. Они соблазнились мелкими сиюминутными
прагматическими преимуществами, но пуще всего - модой, ведь они
знали, что "компилятор - это круто" и "объекты - это круто"
(рассуждения на уровне Бивиса и Баттхеда, на коем они и находились).

Сегодня нет ни одного успешного примера сочетания статики и динамики
в одном языке (достаточно вспомнить эппловский Dylan и что с ним стало).
Думаю, это не случайно. А про ООП точнее всего сказано в "Gentle
Introduction into Haskell". Это эклектичный набор методов и идей,
из которых одни не новы, а другие не полезны.

Поэтому лично я, если бы хотел развить язык xBase, забыл бы про Clipper,
вернулся бы к старому dBASE и гулял оттуда (конечно, это отнюдь не
принесло бы мне популярности среди сегодняшних клипперистов).
А начал бы я с разработки навигационного сервера, выполняющего запросы
на доступ к записям по одной. Такой сервер сделать очень просто, он даже
не обязан быть многопотоковым, так как время обработки любого запроса мало.
И гораздо надежнее в работе с БД, чем терминальный сервер + разделяемые
файлы dbf. А для BTree и транзакций можно взять готовую BerkeleyDB.

Но самый красивый язык для навигационного доступа к БД я видел вовсе не в
xBase, а за много лет до того, в языке запросов иерархической СУБД ИНЕС.
Поэтому мне неинтересно возрождать xBase. Для практических задач меня
вполне удовлетворяют Tcl + MySQL, но настоящие языки для прикладного
программирования еще предстоит создать (и отнюдь не на основе C и его
ублюдочных потомков с уродливыми названиями).

Господа Разработчики. У меня есть несколько вопросов. Насколько я понял, Вы доработали DosEmu под свои нужды. 1. Как обстоит дело с запуском приложений FoxPro в DosEmu? Насколько помнится, с этим в свое время (2-3 года назад) были проблемы. 2. Поделитесь опытом, как Вы организуете печать с DosEmu и доступом через терминал на своем локальном принтере (на клиенте может стоять произвольная ОС)? Теперь о Clip-е. 3. Как Вы формируете принтер-независимые отчеты на русском языке в своей системе? Имеется ли для этого некий генератор печатных форм, или предполагается использовать для этого что-то типа a2ps?

Ну и последний вопрос ко всем посетителям сайта. Поделитесь, как Вы решаете вопрос печати отчетов в своих прикладных задачах (н-р, в том-же бухучете). Какой используете для этого инструментарий? На мой взгляд, это - одна из серьезных проблем по переносу приложений из под Win на Linux.

Alexnic

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

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

По опыту эксплуатации ADS получается что мелкие запросы типа seek,skip очень сильно тормозят.

> И гораздо надежнее в работе с БД, чем терминальный сервер + разделяемые файлы dbf. А для BTree и транзакций можно взять готовую BerkeleyDB.

И послать нахрен совместимость по данным ?

> но настоящие языки для прикладного программирования еще предстоит создать (и отнюдь не на основе C и его ублюдочных потомков с уродливыми названиями).

Есть мысли и не жалко их подарить - выкладывай - посмотрим что можно сделать.

> Господа Разработчики. У меня есть несколько вопросов. Насколько я понял, Вы доработали DosEmu под свои нужды.

Угу.

> 1. Как обстоит дело с запуском приложений FoxPro в DosEmu? Насколько помнится, с этим в свое время (2-3 года назад) были проблемы.

Также плохо потому-что он нас не интересует, ну и скромные попытки разобраться с фокс+досему привели к тому что фокс в расширенном режиме использует недокументированные функции расширителей памяти - воевать с этим делом не по нашей части

> 2. Поделитесь опытом, как Вы организуете печать с DosEmu и доступом через терминал на своем локальном принтере (на клиенте может стоять произвольная ОС)?

какая угодно - в досе используем клиент Ka9 и печатаем на нем через ftp, под виндой печатаем через smbclient

> Теперь о Clip-е. 3. Как Вы формируете принтер-независимые отчеты на русском языке в своей системе? Имеется ли для этого некий генератор печатных форм, или предполагается использовать для этого что-то типа a2ps?

есть транслятор txt|html|man|.. to tex/ps, а дальше по накатанной дорожке.

>Ну и последний вопрос ко всем посетителям сайта. Поделитесь, как Вы решаете вопрос печати отчетов в своих прикладных задачах (н-р, в том-же бухучете). Какой используете для этого инструментарий? На мой взгляд, это - одна из серьезных проблем по переносу приложений из под Win на Linux.

В моей старой проге используется обычный текстовый вывод, особо изощренные отчеты генерируются либо в HTML либо сразу в TEX формате.

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

Видимо для завершения разговора:

за март с нашего домашнего ftp скачано 6500 файлов (это не означает что это все качали клип) из них:

670 - готовые виндовые бинарные пакеты с полным клипом

700 - пакет со всеми сырцами

600 - пакет с компилятором и стандарными библами в сырцовом виде

Качали отовсюду - буквально весь глобус в логах прописан :)

Особенно активны украина и бразилия - на них приходится почти 50%.

И среди всего этого хозяйства примерно половина - это последняя версия именно clip-0.99 и всего лишь за неделю :)

Особо неверующим могу и логи прислать.

>Ну и последний вопрос ко всем посетителям сайта. Поделитесь, как Вы решаете вопрос печати отчетов в своих прикладных задачах (н-р, в том-же бухучете). Какой используете для этого инструментарий? На мой взгляд, это - одна из серьезных проблем по переносу приложений из под Win на Linux.

Я например генерирую файлы PDF с помощью библиотеки pdflib, которая вызывается из любого языка (я использую Tcl и Python). Это несколько громоздко (и конечно не для текстовых терминалов), но решает все проблемы переносимости и качества отчетов. Для более простых форм генерирую HTML.

>По опыту эксплуатации ADS получается что мелкие запросы типа seek,skip очень сильно тормозят.

Для навигационного сервера я не вижу другого пути, как постараться
увеличить эффективность мелких запросов. Для этого есть разные пути,
вплоть до перенесения клиентских процессов на сервер и связь с
клиентским интерфейсом через X11, VNC (или если угодно telnet либо
наоборот SunRay). Либо отказаться от навигационной идеи и перейти
на SQL (думаю, именно эти проблемы и стали главной причиной
сегодняшнего преобладания реляционной модели, а вовсе не те,
что обычно называют).

>И послать нахрен совместимость по данным ?

Для серверной СУБД это не главное. Много ли совместимых по данным
серверов SQL?

>Есть мысли и не жалко их подарить - выкладывай - посмотрим что можно сделать.

По крайней мере ясно, что нужны разные языки для разных моделей БД
(например табличные, иерархические) и структуры в памяти нужно
приблизить к структурам БД. В случае xBase мне кажутся заслуживающими
внимания идеи, изложенные в http://www.geocities.com/SiliconValley/Lab/6888
(о введении обобщенной таблицы в язык как основного объекта-контейнера
и применении табличной метафоры всюду, где только можно), а также
опыт M-технологии, где изначально почти не было разницы между persistent
и не persistent данными. Очень важно сделать действительно удобный
и стандартный графический интерфейс. Сегодняшний кризис как xBase,
так и M-технологии вызван во многом тем, что у них обоих был удобный
текстовый интерфейс, но так и не появилось сравнимого графического.

> По крайней мере ясно, что нужны разные языки для разных моделей БД (например табличные, иерархические) и структуры в памяти нужно приблизить к структурам БД. В случае xBase мне кажутся заслуживающими внимания идеи, изложенные в http://www.geocities.com/SiliconValley/Lab/6888

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

> Очень важно сделать действительно удобный и стандартный графический интерфейс.

Тоже есть мысли как это сделать.

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

И ошибка была сделана лет 30 назад еще на заре ООП :)