CLIP 0.99.3 - Clipper/Xbase совместимый компилятор

Браво ИТК, вперед к светлому будущему коммунизма!

МОЛОДЦЫ. Так Держать.

Вот интересно, что держать? Наследуемые приложения.
Так их переписывать надо или избавляться от них.
А мотивация, что на старых компах у нас еще это идет никому не нужна.
Под это начинают новые программы писать, компы то все еще старые :)

В последнем обсуждении на LOR обсуждали 4х процессорный PIII
с 350 пользователями на Clip-е и 286 клиент, а на кой это надо.
Держать 286 дороже в обслуживании и обновлении железа, чем закупить
к примеру Palm. Apache/Perl/PostgreSQL поможет избавиться от Clip-ов,
FoxPro,CLipper ...

Люди, наболело: начальники осуждают выбор Linux и Web, тем что
у нас слабые компы и никто не знает Linux.
PS: сижу в FoxPro 2.6 for DOS, на 4Мб - это поделие работает :)

злобный зритель

Вот именно-то что "злобный" Какое-то сумбурное сообщение у тебя получилось.

А между прочим уже есть люди которые переписывают свои перловские скрипты на клип :) Это не перл поможет избавиться от старых программ а clip поможет избавится от перла :)

uri@itk.ru

От перла поможет избавиться ruby :-))))))

http://www.ruby-lang.org

Что вы к ИТК привязались, для них CLIP это cпособ продлить свои древние шедевры написанные на Clipper. SQL по их мнению это уродец который губит индустрию, а бухгалтерия не лезет в реляционую теорию. Но есть умные люди, которые знают что SQL это ториоз любой большой программы (при этом серьезных специалистов по SQL и SQL серверам в ИТК нет, да им и не надо - это устаревшая технология) Лучший интерфеис к базам данных это GO TOP, SKIP 1 и RETREIVE

>LamerOk:
>От перла поможет избавиться ruby :-))))))
Даже не надейся ...
От паранойи тебе поможет только врач.

Тот самый анонимус.

>бухгалтерия не лезет в реляционую теорию Аргументы, плиз ! Что именно у вас не лезет ?

Занимаюсь писанием прог для бух. и фин. учёта. Писал и на клиппере и на скуле. Ни одному программеру в трезвой памяти не придёт в голову перелазить на клиппер после скуля. Разработка отчёта методами GO TOP, SKIP 1 и RETREIVE - на хрен знает сколько порядков сложнее, чем селектом. Не понимать этого может только человек, никогда не работавший на скуле. SQL- язык ОПИСАТЕЛЬНЫЙ, основанный на эксекюшн плэн. ==> более эффективный при работе с данными. Нужно быть морально устаревшим, чтобы говорить что клиппер круче. ИМХО дело в том, что существует масса программеров из категории "вечно вчерашние". Они всю жизнь писали на клиппере, у них есть определённые разработки которые как-то продаются, и переучиваться на современные технологии им просто в ломы.

>В последнем обсуждении на LOR обсуждали 4х процессорный PIII >с 350 пользователями на Clip-е Удивили, блин. Нормально спроектированный бизнес-сервис клиент-серверной системы "держит" тысячи клиентов.

ЗЫ: Конструктивный флейм приветствуется. :)

Фирма "ИТК" является наверно единственным продолжателем дела Clipper.
Доверять перспективу развития только одной единственной фирме,
по моему мнению НЕправильно.

Согласен с anonymous (*) (2002-05-28 08:45:26.575)
писать бесконечные skip-ы утомляет и ошибок больше в несколько раз.

Сервер 4х процессорный PIII был взят из предыдущего флейма, из
высказываний uri@itk.ru. Это они приводят довод, что мол сохраняем
старую никчемную технику запустив Clip на сервере.
В итоге в сети работает груда старого железа в виде 286 или XT :))

злобный зритель.

ну все перепутали и переврали

- я вас заставляю писать на клиппере вместо сикеля ? - не хотите - не пишите - но и не мешайте писать другим так как им хочется

- кто это опять приравнял clipper == DBF != SQL ? сколько можно объяснять что формат данных, способ работы с данными и компилятор языка - ЭТО РАЗНЫЕ ВЕЩИ, и клип не запрещает пользовать сикель-технологии - даже в заголовке написано ODBC !!!

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

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

- 4xXeon - блин - вы че через строчку читали ? или читаете только те куски текста, которые интересуют ? вырезая их из контекста !!! Я всего лишь писал что "испытываем машину из расчета 350 пользователей" и сравнил то что получили с предыдущим экспериментом с P4. И вообще тестили под DOSEMU - откуда взялось что там РАБОТАЕТ КЛИП ? Думаете что перекомпилить сотню программ и их хорошенько протестить - это дело на пару часов ?

- если кто-то не может избавится от программирования в стиле SKIP - это ваша проблема, а не клиппера - на нем можно писать и в других стилях - зачем вешать на язык собственные НЕЗНАНИЯ ?

- чем заменить 286 и XT ??? Как легко у вас все получается - мне бы ваше самомнение. что толку их менять ? Даже если их все поменять быстрее работать не станут, потому как сетка останется старой. А ее заменить ..... ну и чем можно заменить например 4 км аркнета (один из кусков)? Можно конечно и проги переписать - года 3-4 работы а потом еще столько же отладки - по вашему это дешевле чем поставить хороший сервер и работать с теми-же привычными программами не переучивая людей и не ставя на уши своих программеров ????

Только одно оправдаение у вас - "злобный зритель" !!! Лишь бы сказать чего - даже если и не знаете всех проблем.

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

uri@itk.ru

Привет всем ! полностью согласен со специалистами из ИТК а использую я лично это так на Clip-е пишу интерфесные проги - работающие в терминальном режиме для ввода информации оператором и CGI для просмотра информации пользователями База - Oracle 8.1.7 Отчёты - Crystal Report Вот и всё ! никаких skip а вот по теме: ODBC мне видится как болле универсальный путь доступа к БД но со скоростью я думаю придётся распрощаться В иделе нужны библиотеки под UNIX для доступа к различнам SQL серверам но это не к ИТК а к производителям баз данных

и вот ещё ту некоторые нападали на ИТК скажу что они не одиноки и их продукт очень нужен потому что буржуи за эту технологию с вас слупят кругленькую сумму www.fship.com а если вы захотите подсоединиться к ораклу за дрйвер вам придётся выложить ещё такую же сумму на 5 коннектов а на перлах вы сами пишите и всю жизнь изучайте руби делфи яву кларионы постгрисы ... на долго ли вас хватит

>"бухучет не лезет в рамки реляционной алгебры"

Аргументы уважаемый, аргументы. ЧТО ИМЕННО у вас не лезет ? не надо диссертаций, давайте на пальцАх. Мы можем обсудить не сам бухучёт, а ПОСТАНОВКУ бухучёта. Не кривая постановка ложится в скуль как там и была.

>Думаете что перекомилить сотню программ и их хорошенько протестить - >это дело на пару часов ?

Где это в бухучёте взялась сотня прог ? Даже если городить не комплекс, а набор армов это будет: Касса, Учет банковских операций, Учет основных средств,Учет материалов, Расчеты с дебиторами и кредиторами, Главбух, Отдел Кадров, Учет труда и заработной платы. Ну ещё с пяток могет быть. Откуда сотни-тысячи то уважаемый ? Или у вас кассовый приходник и расходник лежат в разных армах ? %)

>зачем вешать на язык собственные НЕЗНАНИЯ ?

И как пройтись по записям под клиппером без скипа ?

>ну и чем можно заменить например 4 км аркнета

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

>проги переписать - года 3-4 работы Переписывать их всё равно придётся, иначе ч.з. 5 лет вы загнётесь, потому что такие древние проги не будут вставлять покупателей. ( конечно возможно что вы просто уйдёте на пенсию )

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

Да гадости никто и не пишет, здесь идёт обсуждение. Если оно вам не нравится, то нахрена тогда постить новости ?

2anonymous (*) (2002-05-28 13:45:40.324):

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

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

>а если вы захотите подсоединиться к ораклу за дрйвер вам придётся >выложить ещё такую же сумму на 5 коннектов

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

- по поводу популярности клипа - на свежем мясе клип имеет 2%, а перл 11.5% - разница есть, но и прошу учесть что клипу всего чуть больше 2 лет от рождения.

- как пройтись без скипа ? - легко, но ликбезом заниматься не собираюсь.

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

- 100 программ !!! или почти около того - это не только бухучет, а много чего - в том числе и производство причем с непрерывным циклом

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

- деньги у них есть и много - не так давно выложили более 20млн зеленых на небольшое перевооружение производства - дело тут не в деньгах совсем - поэтому (одна из причин) и испытывали машину на xeon`ах а не на Duron`ах - причины совсем в другом. Дело именно в том что нет смысла менять 286. НИЧЕГО ЭТО НЕ ДАСТ.

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

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

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

>на что можно заменить 4 км отрезок арснета

ADSL, радиомодем, обычная телефонка наконец. Для рабочего места оператора в клиент-серверной архитектуре этого вполне достаточно.

>Дело именно в том что нет смысла менять 286. НИЧЕГО ЭТО НЕ ДАСТ.

Конечно, если тётке-кладовщице поставить вместо 286 P4, то это действительно ничего не даст. Она будет учитывать рукавицы с галошами с такой же скоростью. А если грамотно перестроить процессы ( я стараюсь избегать слова "реинжениринг" зная что вы его не любите ) то можно сократить число рабочих мест с повышением эффективности системы. И тогда нужны мощные машины для специализированных пакетов. Это будет не просто терминальная "морда", а специализированный под конкретную задачу "дата мининг".

>а вот для коммерческого fship - увы - бабки таки придется выложить.

FSHIP-у платят бабки в конечном счёте не за прогу, а за саппорт. У вас-то его я так понимаю нет ? Опен сорс бесплатен, но это означает, что у него нет НОРМАЛЬНОЙ поддержки. Так что кому как удобно.

Ну я пошёл читать "Блеск и нищета клиент-сервер", потом обсудим...

> "Блеск и нищета клиент-сервер" - вроде это было в компутерре пару лет назад - в этой
> статье описана половина прроблем SQL - по крайней мере мне не придется их перечислять.

Доступна с сайта автора:
http://akop.ru/personal/1856?PARENT_RUBR=akop_art_it

Прочитал статью - НИ СЛОВА про реляционные алгебры и бухучет. Обсуждаются
трудности реализации клиет-серверных технологий в свете СУБД.

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

1. цену забыл сказать

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

3. скорость сети останется таже - значит придется переписывать проги ? 3-4 года работы !!!

>>Дело именно в том что нет смысла менять 286. НИЧЕГО ЭТО НЕ ДАСТ.

>Конечно, если тётке-кладовщице поставить вместо 286 P4, то это действительно ничего не даст. Она будет учитывать рукавицы с галошами с такой же скоростью.

И это тоже одна из причин.

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

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

>а вот для коммерческого fship - увы - бабки таки придется выложить.

> FSHIP-у платят бабки в конечном счёте не за прогу, а за саппорт. У вас-то его я так понимаю нет ? Опен сорс бесплатен, но это означает, что у него нет НОРМАЛЬНОЙ поддержки. Так что кому как удобно.

FSHIP`у платят именно на sowtware и немало.

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

> Ну я пошёл читать "Блеск и нищета клиент-сервер", потом обсудим...

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

http://www.itk.ru/tmp/blesc.txt

>FSHIP-у платят бабки в конечном счёте не за прогу, а за саппорт. У >вас-то его я так понимаю нет ? Опен сорс бесплатен, но это означает, >что у него нет НОРМАЛЬНОЙ поддержки. Так что кому как удобно.

на все вопросы какие я хотел задать я получил квалифицированные и подробные ответы и что немаловажно в течении суток (!) и намного приятней общаться с людьми у которых есть свои живые проекты котрые как я понимаю тоже на clip-e

> Прочитал статью - НИ СЛОВА про реляционные алгебры и бухучет. Обсуждаются трудности реализации клиет-серверных технологий в свете СУБД.

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

uri> - про бухучет + SQL - чуть позже - постараюсь уложиться в пару страниц - а вы для начала поищите статью "Блеск и нищета клиент-сервер" - вроде это было в компутерре пару лет назад - в этой статье описана половина проблем SQL - по крайней мере мне не придется их перечислять.

Для начала прочитайте ..... половина проблем SQL ..... мне не придется их перчислять. Именно для тогго чтобы не переписывать ихние 20 страниц своими словами.

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

Между прочим там есть очень интересная фраза

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

И эта фраза говорит еще больше чем сама статья. :)

Блин ! Только отвлекаете от написания тех самых 2 страниц где будет про SQL+ бухучет

Надеюсь что поняли что это опять uri@itk.ru и в предыдушей мессаге тоже был я

:) нет в предудыщей был не я - успели вклинится :)

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

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

Для "подробнейшей разблюдовки" информации требуется куча "справочников" - надеюсь не надо объяснять что это такое ? по моим представлениям и опыту получается что в информационной системе (далее ИС) требуется около 100 !!! справочников. Не верится ? Ну дык например только госкомстатовских у меня лежит уже около 20.

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

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

Перьвый вопрос - как хранить ?

-- В разных таблицах ? Тогда в документах и проводках куда ссылаться ? Через перекрестные таблицы ? И как запросы строить ? с тремя join в одном запросе ?

-- в одной ? зашибись - это уже почти ОО поверх сикеля !!! О его проблемах читайте в другом месте (уменя нет времени писать еще страниц 20 об этих проблемах)- в любом случае данная технология не решает проблему колва join`ов в одном запросе.

Теперь прикинем что эти все справочники - "деревянные" и для запросов потребуется не три join`а а несколько больше. А если запросы не к листьям а к веткам ? на неизвестном уровне при известном значении только "идентификатор ссылки".

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

Ну и попутная проблема - диалекты сикеля - даже если умудрится и вылизать все сикель запросы для например оракла - это не означает что на мусикеле эта прога будет работать достаточно эффективно. решений тут всего два - пытаться своих клиентов напрягать на то чтобы ВСЕ КЛИЕНТЫ :) пользовали именно нужный сикель (MS SQL) и тогда прога будет иметь ограниченное кол-во потенциальных клиентов. Или второй путь - пользоваться только такими сикель выражениями и прибамбасми которые понимаются многими серверами - но тогда будет резкое ухудшение производительности всей системы. А вот ведь и вру - есть еще третий путь - понаписать оптимизированный сикель код для всех сикель серверов :) в таких случаях обычно говорят - флаг в руки и паровоз навстречу.

Продолжать ? а то время уже поздновато и я не уверен что сегодня еще смогу что-то ответить или понаписать.

2 uri@itk.ru
> ...я разве писал что в ней обсуждаются проблемы бухучета???

Мы не совсем поняли друг друга -

anonymous (*) (2002-05-28 13:45:40.324):
> я говорил немного другое "бухучет не лезет в рамки реляционной алгебры"

Die-Hard (*) (2002-05-28 15:51:31.986):
>> бухучет не лезет в рамки реляционной алгебры
>Поддерживаю вопросы из зала.

anonymous (*) (2002-05-28 16:43:23.704):
> ...про бухучет + SQL - чуть позже ... для начала поищите статью
> "Блеск и нищета клиент-сервер"

Die-Hard (*) (2002-05-28 17:52:23.538):
>Прочитал статью - НИ СЛОВА про реляционные алгебры и бухучет.

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

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

[Ответить] Ответ на: Re: CLIP 0.99.3 - Clipper/Xbase совместимый компилятор от anonymous Re: Re: CLIP 0.99.3 - Clipper/Xbase совместимый компилятор 2 uri@itk.ru > ...я разве писал что в ней обсуждаются проблемы бухучета???

Мы не совсем поняли друг друга -

anonymous (*) (2002-05-28 13:45:40.324): >>> я говорил немного другое "бухучет не лезет в рамки реляционной алгебры"

>>Т.о., согласен, ты не говорил про то, что в статье обсуждается проблема того, как бухучет ложится на реляционные алгебры; мне же было интересно именно это.

Ура ! есть некоторый консенсус :) О начальных проблемах я уже начал писать и уже можно начинать обсуждать - вон оно чуть выше про "справочники" уже лежит

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

если есть проблемы - они лягут на плечи прикладника - а уж бухучет или что-то другое - это МОНОПЕНИСУАЛЬНО

2anonymous (*) (2002-05-28 19:28:52.725):

> а уж бухучет или что-то другое - это МОНОПЕНИСУАЛЬНО
Еще раз - проблема есть, согласен. Решается, как я понял из статей,
грамотными настройками Оракла (и отказом от M$ технологий ;) ).

Согласен, для конкретной частной не очень большой задачи Клиппер предпочтительнее
(Ой! Что сейчас будет!!).

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

К сожалению, в последние годы предприятия этого не понимают.

При чем тут реляционная алгебра?

>>> а уж бухучет или что-то другое - это МОНОПЕНИСУАЛЬНО

>Еще раз - проблема есть, согласен. Решается, как я понял из статей, грамотными настройками Оракла (и отказом от M$ технологий ;) ).

>Согласен, для конкретной частной не очень большой задачи Клиппер предпочтительнее (Ой! Что сейчас будет!!).

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

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

Один ораклеспец сможет в крупной системе разве что удержать оракла от падений и зависаний в клинчах - но увы в одиночку проделать ту работу которые проделали пяток спецов НУ НИКАК НЕ СМОЖЕТ - ту дело даже не в знаниях самого оракла а в знаниях предметной области - а эти знания именно у тех кто в течении 10 лет писал эти самые прикладухи и эти знания не заменить знаниями "как правильно писать сикель запросы".

> К сожалению, в последние годы предприятия этого не понимают.

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

> При чем тут реляционная алгебра?

а про справочники уже типа вопросов НЕТ ? И все решения они прямо тут на любом углу имеются ?

Ну и до кучи "про справочники" - имеется куча таблиц ссылающихся на "справочники" - сделайте мне плиз запрос который достанет из всех этих таблиц ВСЮ ИНФОРМАЦИЮ (документы проводки и пр пр пр) которые ссылаются на .... например на меня как физическое лицо под фамилией URI.

Я не утверждаю что такое не возможно - такое возможно конечно, но сколько усилий потребуется для того чтобы хранить из каких ТАБЛИЦ ССЫЛАЮТСЯ НА URI :) А ведь URI только один член одного из 100 справочников :)

>>сколько усилий потребуется для того чтобы хранить из каких ТАБЛИЦ ССЫЛАЮТСЯ НА URI :) А ведь URI только один член одного из 100 справочников :) <<

"Не, так неззя" (с) Масяня. Член-то член. Тока член может еще замуж выйти и фамилию поменять.

> FSHIP-у платят бабки в конечном счёте не за прогу, а за саппорт.

Ото я сейчас расскажу вам про этот саппорт, и с чем его едят, т.к. не понаслышке о нем знаю.
Пару лет назад возникла у нас необходимость в аналоге клиппера под юникс.
Нашли flagship. Деньги были не вопрос, главное - оно должно было работать.
Скачал я демоверсию и стал переводить один АРМ под flagship. Пару дней убил
и оно запустилось. Сразу поймал кучу глюков и миллион багов. Стал их разбирать
и слать багрепорты автору. Причем выбирал баги серьезные и откровенные, на мелочь
не разменивался. Дык эта... в кажом ответе он сухо благодарил за багрепорт и методично так
напоминал про то, что неплохо бы купить полную версию, в ближайшем релизе которой
найденные мной баги будут исправлены. Я ему отвечал, что мы сами заинтересованы в этом, но
хотим убедиться в работоспособности его софта. После третьего багрепорта он
с нескрываемым раздражением жестко так отрезал: мол пукупайте софтину,
тогда будет вам саппорт, и что бесплатно саппорт он предоставлять не будет...

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

Вот так, делай после этого (немецким) людям добро ;)))

> И как пройтись по записям под клиппером без скипа ?
А в чем собственно проблема? Не нравится слово ``skip''?
Ах, да, while($sth->fetchrow_arrayref()) выглядит конечно красивее ;)

>>Выдержка из статьи:
? понимает, что он видит не полный список (Где запись, которая я точно
знаю, что была? Караул! База испортилась, в программе вирус и проблема
2000 года!)? видит, каким именно условием ограничен текущий список
? понимает, как изменить это условие, и имеет возможность сделать этолегко.
---
Поставьте кнопки "назад 10 записей" "вперед 10 записей"
В SQL введите ограничение на кол-во запрашиваемых записей.
---
Выбирать строки из уже подготовленного запроса (одной таблицы)
или бродить по записям нескольких баз две большие разницы.

Прочитал "Блеск и нищета клиент-сервер". Впечатление двоякое : Во-первых автор безусловно знает предмет и правильно обозначает проблеммы, возникающие при разработке клиент-серверных решений. Во-вторых ВСЕ траблы описанные им имеют вполне конкретные и известные решения. Создаётся впечатление, что автор работал с этим направлением весьма поверхностно, что бы писать статьи по такой тематике. Я готов оспорить почти ЛЮБОЕ положение этой статьи.

По поводу справочников: Обычно создаётся таблица, назовём её ref, она содержит в себе общую часть всех справочников. Это могут быть поля: id записи, поле для признака справочника, дата ввода, краткое описание, полное описание, и поле ParentID для ссылки на "маму" в этой же таблице для "деревянных" спр-ов. Остальная инфа пихается в дочерние таблицы со структурой, специфичной для данного спр-ка. Только не надо ля-ля про кучу джойнов, Пишутся они элементарно. Ну уж точно легче, чем собирать тоже самое дэбэсииками под клиппером и отрабатывает на порядки быстрее.

> Re: CLIP 0.99.3 - Clipper/Xbase совместимый компилятор Прочитал "Блеск и нищета клиент-сервер". Впечатление двоякое : Во-первых автор безусловно знает предмет и правильно обозначает проблеммы, возникающие при разработке клиент-серверных решений. Во-вторых ВСЕ траблы описанные им имеют вполне конкретные и известные решения. Создаётся впечатление, что автор работал с этим направлением весьма поверхностно, что бы писать статьи по такой тематике. Я готов оспорить почти ЛЮБОЕ положение этой статьи.

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

> По поводу справочников: Обычно создаётся таблица, назовём её ref, она содержит в себе общую часть всех справочников.

Я написал тоже самое - "через перекрестную таблицу ссылок"

> Это могут быть поля: id записи, поле для признака справочника, дата ввода, краткое описание, полное описание, и поле ParentID для ссылки на "маму" в этой же таблице для "деревянных" спр-ов.

Ну а дальше-то ? Типа того при работе с деревяшками в сикеле проблем нет ? Ну в оракле вроде нет, а вот в мусикеле ?

И как в данном случае сделать запрос "достать все документы имеющие ссылку на любой лист в ветке ХХХ". Типа такие запросы любой сикель делает как два байта переслать ?

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

И эта "остальная инфа" конечно же легко достается без использования подзапросов и join`ов ? Про клиипер и сики пока умолчим - разговор идет не о нем а о "бухучет не лезет в реляционную алгебру"

Теперь добавим к запросу "документы из ветки" еще и такое что:

Документы тоже имеют разную структуру - значит если их хранить в одной таблице по принципу справочников то запрос типа "достань все документы за ХХХ дату" приведет к тому что в запрос попадет чо попало и как при этом считать структуру конкретного документа ? Отдельным запросом ? А в документе имеется пара десятков ссылок на разнородные справочники у которых "тело" тоже придется доставать отдельным запросом - итого для вывода списка документов из 20 элементов - потребуется порядка 400-500 запросов к серверу ?

Я прав или нет ?

А в предыдущем треде про клип я показал (в общих чертах) что запись накладной из 10 строк тянет за собой порядка 10000 транзакций :)

>А в предыдущем треде про клип я показал (в общих чертах) что запись >накладной из 10 строк тянет за собой порядка 10000 транзакций

Просмотрел предыдущий тред, ничего не нашёл. Рипит, плиз. Фраза про сто тысячь транзакций для сраной накладной меня заинтересовала.

>запрос типа "достань все документы за ХХХ дату" >А в документе имеется пара десятков ссылок на >разнородные справочники

Объясняю в клиент-серверной архитектуре есть два понятия: журнал документов и документ. Так вот на запрос "достань все документы за ХХХ дату" придёт узкая выборка по документам с минимумом справочной информации, а уже при открытии конкретного документа приходят полные данные. Какие, нахрен, 400-500 запросов ?

>И эта "остальная инфа" конечно же легко достается без использования >подзапросов и join`ов ?

А кто говорит, что без подзапросов и джойнов ? Конечно ими, родимыми. Если вас они пугаю, меня - нет. У меня текст запросов доходит до 50 экранов, и что характерно - читаются на порядки легче чем тоже в клиппере.

>сикель позиционируется как "напиши запрос и пусть сервер решает как >его выполнить быстрее"

У меня есть механзмы воздействия на эксекюшн план, например хинты для оптимизатора какие индексы использовать. Да и одно и тоже можно сделать разными способами, естественно с разным результатом. Если программер по пояс деревянный - при чём сдесь скуль ?

И вообще, никто и не говорит, что под скулем может писать уборщица. Понятно что и там нужно работать. Да есть заточка под конкретный сервер. Дык выберете соответствующий сервер для конкретной задачи и работайте с ним. Вы ведь тоже не можете быстро переписать свои клипперовские проги под клип при всей его супер-пупер совместимости !

Позволю себе высказаться.
>конкретный диалект и релиз сервера.
Почему бы не использовать инструмент, максимально заточеный под конкретную задачу? Проблема переноса Oracle->другойSQL не сложнее переноса
Clip->другойЯзык. В любом случае "привязка к инструменту".
Аргументы "к Clipу прикрутить любую СУБД" опровергаются в той же статье - 
на SQL НЕЭФФЕКТИВНО писать интерфейсы, эквивалентные Clip-ским.

>лучше чем "писать на клиппере"
Это таки лучше. Иногда. Если задача "красиво" ложится в реляционную модель.
Если нет - может быть и не лучше. В таком случае нужен другой инструмент.
Пример: XPath для поиска "всех документов, ссылающихся на URI":
'//*[@href="URI"]/ancestor::document'
Для деревянных структур "самое то". Но это уже другие базы данных.

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

не знаю как у ИТК, но в целом опернсоурс небесплатен. Вопрос в том, что какраз сделано перераспределение денег. В одном случае платишь много сразу, и мало за поддержку, в другом - ничего сразу, и больше за поддержку. Есть мнение, что в случае оперсоурс сумма "итого" будет меньше. Примеров пока мало, но я думаю чем дальше, тем будет больше.

Если у ИТК получится, то это будет еще один пример :)

б ОЕПБСЧ НВЕПЕДЭ УНВС НРБЕРХРЭ МЮ ПЕОКХЙС Н РНЛ, ВРН хрй - ЕДХМЯРБЕММШЕ, ЙРН ОНДДЕПФХБЮЕР йКХООЕП. щРН ЯНБЯЕЛ МЕ РЮЙ. оНЛХЛН СФЕ СОНЛХМЮБЬЕЦНЯЪ Flagship, ЕЯРЭ Harbour (http://www.harbour-project.org/) - Open source йКХООЕП-ЯНБЛЕЯРХЛЮЪ ЛСКЭОКЮРТНПЛЕММЮЪ ЯХЯРЕЛЮ, ЕЯРЭ Xbase++, VO, culi.net ( йКХООЕП ОНД .NET ). йПНЛЕ РНЦН, Computes Associates МЕДЮБМН ГЮЙКЧВХКХ ДНЦНБНП Я GrafSoft, ОН ЙНРНПНЛС ОЕПЕДЮЧР ЩРНИ ТХПЛЕ ОПЮБЮ МЮ ДЮКЭМЕИЬСЧ ПЮГПЮАНРЙС Clipper Х VO - ВЕЛ РЕ Х МЮЛЕПЕМШ ГЮМХЛЮРЭЯЪ. р.Е., Я йКХООЕПНЛ ОН-ОПЕФМЕЛС ЮЙРХБМН ПЮАНРЮЕР ЛМНФЕЯРБН КЧДЕИ БН БЯЕЛ ЛХПЕ - Х НРМЧДЭ МЕ РНКЭЙН ДКЪ ОНДДЕПФЙХ ЯРЮПШУ ОПХКНФЕМХИ. вРН ФЕ ДН Unix ОКЮРТНПЛШ - РН, МЮ ЛНИ БГЦКЪД, Clip ГДЕЯЭ ДЕИЯРБХРЕКЭМН МЮХКСВЬХИ БШАНП ХГ Clipper - ЙКНМНБ. бРНПНЕ. яНБЕПЬЕММН МЕОНМЪРМН, ОНВЕЛС ПЮГЦНБНП Н йКХООЕПЕ ЯБЕКЯЪ Й ЯОНПС Н ЯОНЯНАЕ ДНЯРСОЮ Й ад. йКХООЕП - ЩРН ЪГШЙ ОПНЦПЮЛЛХПНБЮМХЪ Х, ЙЮЙ Х МЮ КЧАНЛ ДПСЦНЛ ЪГШЙЕ, БШ ЛНФЕРЕ ХЯОНКЭГНБЮРЭ ЯЮЛШЕ ПЮГМШЕ ЯПЕДЯРБЮ ДНЯРСОЮ Й ад - Х SQL, Х ЕЦН ПНДМШЕ seek/skip. Oracle ФЕ - ЩРН ясад :), ЯПЕДЯРБН УПЮМЕМХЪ, ЛНДХТХЙЮЖХХ Х ОПЕДНЯРЮБКЕМХЪ ДЮММШУ, Ю МЕ ЪГШЙ ДКЪ МЮОХЯЮМХЪ ЙКХЕМРЯЙХУ ОПХКНФЕМХИ. щРХ ЯЮЛШЕ ЙКХЕМРЯЙХЕ ОПХКНФЕМХЪ, ХЯОНКЭГСЧЫХЕ Oracle БШ ЛНФЕРЕ ОХЯЮРЭ Х МЮ pl/sql, Х МЮ я, Х МЮ ъБЕ, Х МЮ йКХООЕПЕ. ОПХВЕЛ йКХООЕП Б ЩРНИ ЙНЛОЮМХХ БШЦКЪДХР НРМЧДЭ МЕ УСДЬХЛ НАПЮГНЛ.

юКЕЙЯЮМДП йПЕЯХМ http://www.geocities.com/alkresin/

>>А в предыдущем треде про клип я показал (в общих чертах) что запись >>накладной из 10 строк тянет за собой порядка 10000 транзакций

>Просмотрел предыдущий тред, ничего не нашёл. Рипит, плиз. Фраза про сто тысячь транзакций для сраной накладной меня заинтересовала.

Не 100 а "порядка 10". Если коротко то смысл примерно следующий - для каждой строки в накладной надо сделать:

- сформировать проводку (даже чаще бывает что проводок более 3) - каждая проводка как известно состоит из двух частей в каждой части может быть до 7 (как в 1С) субконто, каждое субсонто - дерево в 5-8 уровней. Для каждого счета*субконто*ветки*листьев надо пересчитать "регистры", регистры могут быть по дням, декадам, неделям , месяцам, кварталам и состоят из 6-12 цифр,

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

- сделать отметки и перестроить "регистры" в "столе заказов" и "планировщике закупок" - этот пункт можно опустить как экзотический :)

Естественно это сильно зависит от построения системы учетной политики и пожеланий руководства о детализации аналитической информации - вполне возможно что при некоторых условиях может быть и 100тыс :)

>запрос типа "достань все документы за ХХХ дату" >А в документе имеется пара десятков ссылок на >разнородные справочники

Объясняю в клиент-серверной архитектуре есть два понятия: журнал документов и документ. Так вот на запрос "достань все документы за ХХХ дату" придёт узкая выборка по документам с минимумом справочной информации, а уже при открытии конкретного документа приходят полные данные. Какие, нахрен, 400-500 запросов ?

Да что вы говорите ! Вот это и есть "программер сказал низяяя" и сделал так как можно - вот это и есть "бухучет не лезет в РА - ее туда ногами запихивают"

Кто и как будет определять этот минимум который хранится в журнале ? Программер ? - значит будет жесткая структура журанала - а ты вот дай поуправлять структурой этого журнала хотя бы главбуху :) И какая тут получится "ненормальная форма" ?

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

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

И вообще в ссылочной таблице может и должен храниться только id_doc - иначе это уже "ненормальная форма" придется синхронизировать "журнал документов" и "хранилище документов" потому как в любой момент дата в журнале может оказаться совсем не той которая имеется в документе. Это не сложно но это уже выходит за рамки классики РА. Фактически я уже доказал свое утверждение.

400 запросов получаются так: 1 запрос на получение "списка документов" в каждом документе 20 параметров - все параметры ссылки на справочники - 20*20 -> 400

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

>> А кто говорит, что без подзапросов и джойнов ? Конечно ими, родимыми. Если вас они пугаю, меня - нет. У меня текст запросов доходит до 50 экранов, и что характерно - читаются на порядки легче чем тоже в клиппере.

Не пугают пока текст запроса не станет более 10 строк. Кстати в том же клипе мои функции не превышают 20 строк и умещаются на одном экране - и читать удобно и понятно без комментариев. Ваше право писать запросы любой длины - но это скажется только отрицательно на качестве программы.

50*24 - 1200 строк в запросе - у меня весь склад умещается примерно в такое кол-во строк, со всеми мордами и типовыми отчетами.

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

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

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

Почему я должен выбирать сервер ? Это дело того кто у меня покупает программу - может у него уже давно закуплен DB2 и спецы имеются а к нему приду с требованиями ставить оракла - как ты думаешь куда меня пошлют ? А может вместо оракла вполне достаточно мусикеля ? Зачем всех под одну гребенку ? Потому-что вот тут пришлось ногами попинать и вот тут подкрутить - а иначе производительность падает в разы ! А страдать должен покупатель твоей программы ?

> Вы ведь тоже не можете быстро переписать свои клипперовские проги под клип при всей его супер-пупер совместимости !

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

> не знаю как у ИТК, но в целом опернсоурс небесплатен. Вопрос в том, что какраз сделано перераспределение денег. В одном случае платишь много сразу, и мало за поддержку, в другом - ничего сразу, и больше за поддержку. Есть мнение, что в случае оперсоурс сумма "итого" будет меньше. Примеров пока мало, но я думаю чем дальше, тем будет больше. Если у ИТК получится, то это будет еще один пример :)

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

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

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

А также к нам приезжают учится как Линуксу так и Клипу - естественно это тоже не бесплатно.

2anonymous (*) (2002-05-29 13:23:17.498):
> Итого - 401 запрос - это при условии что документы хранятся в "нормальной форме" и
> содержат в себе только ссылки и не дублируют информацию из справочников и других документов.
> А именно этого и требует классическая РА.

и т.д.
Все ж я не понимаю, при чем здесь специфика бухучета. Все эти аргументы
применимы к ЛЮБОЙ нетривиальной структуре, многократно обсуждались Коддом и оппонентами,
и конценсус давно достигнут :)

> Это не сложно но это уже выходит за рамки классики РА. Фактически я уже доказал
> свое утверждение.

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

> Все ж я не понимаю, при чем здесь специфика бухучета.

Специфика Бухучета (именно с большой буквы) именно в том что имеется много разнородной информации и много связей между различными таблицами причем обычно двусторонних и M:M - все эти качества и приводят к тому что "бухучет запинывают ногами в РА" при этом ставя кучу ограничений по кол-ву связей уровней и тп. Что ты см же и продемострировал в примере о "журнале документов"

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

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

> Все эти аргументы применимы к ЛЮБОЙ нетривиальной структуре, многократно обсуждались Коддом и оппонентами, и конценсус давно достигнут :)

Консенсус между кем и кем ? Между Коддом и консультантами ? Лучше бы консенсус был найден между "требованиями к Бухучету" и "реальной функциональностью ИС" - а такого консенсуса никогда не будет - его можно получить только в очень ограниченной системе и именно отсюда растут ноги вопросов "купить готовое или писать самим" "конструктор или набор АРМов" и тп. Именно так и ищется консенсус !!! А то что беда сидит в самой несовместимости Бухучета и РА - об этом если и догадываются единицы программеров - но и сделать ничего не могут - потягатся с такими авторитетами как Кодд мало кто может - и даже если кто-то заработает такой авторитет как Кодд - то нафига ему дергаться и спорить с монстрами существующего рынка ? Задавят как котенка .

> Это не сложно но это уже выходит за рамки классики РА. Фактически я уже доказал > свое утверждение.

> Вообще говоря, нормальная форма относится к структуре хранения данных, а РА - к структуре запросов. Никто не мешает в процессе запроса отказываться от нормальной формы, в конце концов, человекочитаемый результат запроса НЕ находится в нормальной форме.

Давай вернемся чуток раньше - ты уже согласен с тем что для удобоваримого представления информации на экране придется грузить сервер кучей запросов ? И что произвольный доступ к информации будет ограничен тем что заложено программером в СТРУКТУРЕ ссылочных таблиц ?

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

uri@itk.ru

2anonymous (*) (2002-05-29 14:53:46.407):
Ты отвечаешь в мое лице всем сразу, обобщенному "ты"? :)

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

Кодд не был ученым-теоретиком, он многое сделал для практической реализации своих идей. Труды Кодда отличаются предельной четкостью и ясностью изложения, он обычно не словоблудствует, а доказывает почему он считает реляционный подход более эффективным чем сетевая или иерархическая модель (все таки он математиком был). uri@itk.ru - человек который с умным видом говорит о Бухучете с большой буквы, который дескать плохо ложится на РА и SQL в частности. Кроме голословных утверждений и намеков - ничего, масштаб личности которому далеко до Кодда. Разводить пустые базары - это то что в ИТК умееют делать лучше всего (кроме написания компиляторов, конечно).

>Для каждого счета*субконто*ветки*листьев надо пересчитать "регистры

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

>перестроить склад и его аналитические "регистры" которых тоже немало >в хорошей инфосиcтеме

Ну, батенька, а что вы хотите. Если вы заводите двадцать аналитик, чё-ж вы хотите ?

>регистры могут быть по дням, декадам, неделям , месяцам, кварталам

Регистры должны быть ежедневными, тогда все остальные собираются тривиально.

>400 запросов получаются так: 1 запрос на получение "списка >документов" в каждом документе 20 параметров - все параметры ссылки >на справочники - 20*20 -> 400 >Итого - 401 запрос

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

>мои функции не превышают 20 строк

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

>50*24 - 1200 строк в запросе - у меня весь склад умещается примерно >в такое кол-во строк, со всеми мордами и типовыми отчетами

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

>А при том что умных программеров намного меньше чем тупых админов >чем проще требований к ПО и админу - тем лучше проект

При чём сдесь админ ? Если я нормально прописал запрос, в него тыщу лет никто не полезет. В особенности админ.

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

>Старые программы уже давно перекомпилированы и работают без единого исправления исходников

Предлагаю на спор откомпилить исходники досовского арма писанного под клиппером на вашем клипе.Ставлю литру, что геморроя будет выше ушей. Не с доступом к данным, а с гуйнёй.

>достать все документы имеющие ссылку на любой лист в ветке ХХХ

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

Ну я примерно понял к чему вы клоните. Объектная диби и всё такое. Видал я попытки реализаций подобных заморочек, все они умирали когда дело доходило до получения не тривиальных отчётов. Время их подготовки шло по экспоненте... Я прикладник, и на теорию мне плевать. Что толку от красивой идеи, если у неё нет приличной реализации.

ЗЫ: лет пять назад к вам приезжали ребята из теринбургского "ПРОКС"а, говорят вместеэ-э-э попивали.... Передают приветы. :)

Сори, конечно Екатеринбургского "ПРОКС"а.

> Ты отвечаешь в мое лице всем сразу, обобщенному "ты"? :)

Ну если обидел - извиняюсь - слишком много анонимусов и все в одном лице - не долго и перепутать :)

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

А спорил не с Коддом а с человеком который заявил "поддерживаю вопросы из зала" (по крайней мере неанонимно). Если не крупный спец - зачем спорил ?

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

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

>Кодд не был ученым-теоретиком, он многое сделал для практической реализации своих идей. Труды Кодда отличаются предельной четкостью и ясностью изложения, он обычно не словоблудствует, а доказывает почему он считает реляционный подход более эффективным чем сетевая или иерархическая модель (все таки он математиком был). uri@itk.ru - человек который с умным видом говорит о Бухучете с большой буквы, который дескать плохо ложится на РА и SQL в частности. Кроме голословных утверждений и намеков - ничего, масштаб личности которому далеко до Кодда. Разводить пустые базары - это то что в ИТК умееют делать лучше всего (кроме написания компиляторов, конечно).

1. Я изначально предупреждал что в этой теме хватит материала для написания докторской и у меня нет времени на "правильные и четкие формулировки" и пишу я тут то что думаю а не то что переработано редактором - вы же хотите чтобы на паре страниц все описать !

2. решений для двух вопросов "хочу все знать про uri" и "как хранить справочники и документы" не прозвучало - по крайней мере те решения которые прозвучали имеют кучу ограничений - это говорит в мою пользу а не в вашу

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

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

5. (конкретно последнему анонимусу) хорошо жить по принципу "у джентельмена всегда есть что сказать" и когда аргументы заканчиваются пускать в ход "кулаки" надев черную маску и прикрывашись Тайсоном :) Так держать всегда и везде !

Ну вообщем как и любой другой тред - этот тоже плавно перешел в "обмен любезностями"

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

>>Для каждого счета*субконто*ветки*листьев надо пересчитать "регистры

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

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

>>перестроить склад и его аналитические "регистры" которых тоже немало >в хорошей инфосиcтеме

>у, батенька, а что вы хотите. Если вы заводите двадцать аналитик, чё-ж вы хотите ?

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

>>регистры могут быть по дням, декадам, неделям , месяцам, кварталам

>Регистры должны быть ежедневными, тогда все остальные собираются тривиально.

возможно. А это принципиально ? Ну немного уменьшится кол-во транзакций но не на порядки.

>>400 запросов получаются так: 1 запрос на получение "списка >документов" в каждом документе 20 параметров - все параметры ссылки >на справочники - 20*20 -> 400 >Итого - 401 запрос

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

Я разве так ставил вопрос ? я просто показал что для формирования списка из 20 документов потребуется до 400 запросов к серверу - к этому утверждению есть претензии ?

>>мои функции не превышают 20 строк

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

Ничего подобного. В любом стиле программирования кол-во кода прямо пропорционально кол-ву функциональности. Насколько описательный,читабельный и компактный - это больше зависит от "писателя" а не от языка, в любом языке есть возможность написать один раз модуль и потом много раз его пользовать в том числе и на клипере можно написать функцию select(<fields_list,<from>,<where>,<sort>,...) и пользовать ее вместо прямого обращения к таблицам записям и полям, точно также можно написать get_doc(doc_id) для того чтобы скрыть физические параметры хранения в том числе и источник DBF|SQL.

> Предлагаю на спор откомпилить исходники досовского арма писанного под клиппером на вашем клипе.Ставлю литру, что геморроя будет выше ушей. Не с доступом к данным, а с гуйнёй.

Откомпилировать или запустить чтоб работало ? Что за гуйня ?

> Как решить знаю, нужно проверить. Результат вывалю. Сто пудово отработает на порядок быстрее, чем под клиппером

И как будем проверять ? Если уж сделаешь тестовую БД - пришли и мне. Примерную цифру для клипа могу и щаз сказать - примерно по 0.01сек на каждый возможный лист - это время на "выборку" и примерно 1 сек на чтение 10000 документов попавших в выборку. Это при объеме "документов" в 1млн записей. - естественно индексы любые какие надо . Машина обычная - Ц450/128М.

> Ну я примерно понял к чему вы клоните. Объектная диби и всё такое.

Ни к чему я не клоню - моих решений тут еще не было никаких.

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

О какой красивой идее идет речь ? :)

> ЗЫ: лет пять назад к вам приезжали ребята из теринбургского "ПРОКС"а, говорят вместеэ-э-э попивали.... Передают приветы. :)

Было бы странным если бы сидели трезвыми как дураки :) В конце-то концов в России живем :) Ну и привет им тоже.

2anonymous (*) (2002-05-29 19:48:43.557):
>> Ты отвечаешь в мое лице всем сразу, обобщенному "ты"? :)
> Ну если обидел - извиняюсь - слишком много анонимусов и все в одном лице - не долго
> и перепутать :)
Я ни чуть не обиделся, просто таким образом решил обратить внимание на твою
невнимательность :)

> Если не крупный спец - зачем спорил ?
Ну, я немного практически сталкивался, знаком с теорией и стараюсь "держать руку на
пульсе". В последнее время стали появляться подобные (неаргументированные)
высказавания ("бухучет не ложится на реляционные БД") - ну, мне ж интересно! - я и
спросил. Кстати, (почти :)) не спорил :0

И все мне ясно стало - аргументов нет ;)

BTW, а ты считаешь себя КРУПНЫМ спецом ;-)?

BTW, я целиком и полностью поддерживаю (морально :)) написание Клиппер -
транслятора и считаю что это ДЕЙСТВИТЕЛЬНО важным.

Ой беда с ними... Одни мутные высказывания. "Устраивать ликбез не собираюсь", "Я ещё ничего не предлагал", "это не место для обсуждения бухгалтерии"...

>> Если не крупный спец - зачем спорил ?

>Ну, я немного практически сталкивался, знаком с теорией и стараюсь "держать руку на пульсе". В последнее время стали появляться подобные (неаргументированные) высказавания ("бухучет не ложится на реляционные БД") - ну, мне ж интересно! - я и спросил.

Понятие Бухучет - само по себе сильно зависит от понимания его программистами - если взять например кассц и рассматривать ее оторванно от всего остального - то легко ее засугуть в РА, но это не означает что и весь Бухучет тоже легко лезет в РА.

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

> Кстати, (почти :)) не спорил :0

> И все мне ясно стало - аргументов нет ;)

Тогда где тот анонимус который спорил ? Я не слышу ни потверждений про 400 и 10000 запросов ни их отвергания - что это значит ? Признание этих фактов или что ? Если не согласен - выкладывай с чем именно не согласен и поедем дальше.

> BTW, а ты считаешь себя КРУПНЫМ спецом ;-)?

Ну по крайней мере более 10 лет тем и занимаюсь что пишу Бухучет и не только. Хуже того - именно этим и ни чем другим. Собственно компилятор Клип писал не я - я писал в нем примерно 15% кода и в основном это код юзерного интерфейса и классов, которые писаны именно на клипе

> Ой беда с ними... Одни мутные высказывания. "Устраивать ликбез не собираюсь"

За меня высказались и в принципе правильно - то что цикл со словом skip ничем принципиально не отличается от цикла со словом next или со словом each - и в клиппере слово скип легко можно заменить на что угодно, или сменить ему смысл - все это позволяет делать препроцессор - кому интересно - загляните в std.ch и посмотрите во что транслируется слово skip :) Для особо "вредных" могу специально написать функцию select() которая вернет tRowSet и с которым можно будет работать в вашем любимом стиле. Никаких ограничений клип в данном случае не накладывает.

Разве это сложные категории ? Доступные только профи и недоступные начинающим писакам ?

Это высказывание является мутным ?

> "Я ещё ничего не предлагал"

А разве я выкладывал тут свои конкретные решения из области Бухчета ?

> "это не место для обсуждения бухгалтерии"...

А разве здесь место для этого ? Просто какому-то анонимусу очень хочется насолить и завязать драку а потом за углом хихикать.

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

С другой стороны, существует проблема разделения функций между центральной машиной (сервером, хостом, мейнфреймом и т.п.) и рабочим местом (клиентом, терминалом). Необходим стандартный протокол обмена, и SQL дает такой протокол, не идеальный, но достаточно хороший для многих случаев. А для навигационного доступа нет стандартного протокола (во времена тупых терминалов - был, теперь нет). Работа через файл-сервер - тупик, это не масштабируется, достаточно уже того, что любой клиент может испортить БД. Запросы к серверу на уровне одной записи (SKIP) неэффективны (кстати навигационные программы вовсе не обязаны писаться уровне SKIP, даже на языке xBase (а есть для этого языки и помощнее), тут речь не о программе, а о протоколе обмена). Эффективное решение мне видится только в выполнении (почти) всей логики приложения, включая интерфейс, на сервере, и посылке готовой картинки клиенту (как это и было на тупых терминалах). Готовые решения для этого есть (например VNC, Sun Ray). Но ни одно из них нельзя назвать стандартом, они плохо совместимы с Windows как серверной платформой (конечно, глупо использовать ее как серверную платформу, но ведь используют). Вдобавок такая технология плохо поддержана программными инструментами - в частноти средства на языке dBase на это не рассчитаны. Объектно-ориентированный протокол, предлагаемый создателями Cache', интересен, но тоже оставляет желать. Так что есть, над чем думать.

Кстати о Ruby. Мне тоже противен Perl, но любителям "объектов" я бы советовал получше познакомиться например с ML или Haskell. И в частноти подумать, так ли уж удобен "полиморфизм через наследование" для их реальных задач, ведь полиморфизм достигается и другими способами.