Ищу туториал или мануал

Конечно вы пошутили

Конечно . Вот так сидишь , почитываешь лорчик, натыкаешься на одно слово . В мозгу что-то щёлкает , и накатывают воспоминания .

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

+1

Там в этом xbase есть замыкания и epoll

Владимир

Достойный уважения пост.
https://groups.google.com/forum/#!topic/harbour-users/dny3ZMRSPU4 Turbo Prolog for Harbour

Разработчик приводит код на Clipper, который функционально идентичен коду на Prolog.

Владимир

https://groups.google.com/forum/#!topic/harbour-users/lZGlFSZ23No A mod_harbour for Apache

https://groups.google.com/forum/#!topic/harbour-users/vvbPA5BmHIA Very nice mod_harbour app for the phone !!!

PS: «У кошки четыре ноги. Позади у нее длинный хвост. Но трогать ее не моги, за ее малый рост.»

Владимир

https://sourceforge.net/projects/letodb/files/

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

Многие программисты 1С 8.x утверждают, что проекты на 1С 7.7 /DBF-ой/ «летают» по сравнению с 1С 8.x.

Проблема DBF как и многих других технологий в основном из-за «криворукости» многих программистов.
К примеру у многих умение создать хорошую архитектуру проекта скорее «номинальное».
А потом все валят на «зеркало».

Многие программисты 1С 8.x утверждают, что проекты на 1С 7.7 /DBF-ой/ «летают» по сравнению с 1С 8.x.

Именно так и есть. SQL даёт лишние накладные расходы. Закрытие месяца на 1С 7.7 занимает 3 секунды, закрытие месяца для той же организации на 1С 8 занимает около 2-3 минут. Алгоритмы те же (определяются законодательством и правилами бухучёта).

Проблема DBF как и многих других технологий в основном из-за «криворукости» многих программистов.

Не совсем. В навязывании идеи, что всё, что не гарантирует ACID, то не база данных. Также как проблема всех легковесных графических библиотек в навязывании идеи, что всё, что не реализует в полном объёме стандарты Unicode и возможности не хуже, чем CSS, то не графическая библиотека.

Вот с async/await + MQ скоро будет фактический отказ от прямого многопоточного программирования. Несмотря на то, что нормальная работа через разделяемую память в разы эффективней.

Мода всегда побеждает здравый смысл.

Владимир

Общеизвестно, что 1С не эффективно использует работу с SQL.
Например.
cntLoop = 0;
...
cntLoop = cntLoop + 1;

В DBF версии /в нутрях 1С/ это переменные типы Variable и
прибавление 1 - добавление 1 к переменной типа cntLoop.

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

Откуда здесь будет производительность?
КОШМАР.

За что всегда хвалю фирму 1С:
- за интересный подход при котором базовые объекты определены в метадата базе;
- простота работы с любым объектом;
- ...
- ...

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

Общеизвестно, что 1С не эффективно использует работу с SQL.

Это касалось версии 7.7. Там сначала было всё написано для DBF, а потом сверху нахлобучен SQL. Справедливости ради, энтузиастами был написан 1С++ с уже вполне вменяемой архитектурой для SQL.

В 1С 8 вся конфигурация крутится вокруг запросов SQL. Разве что SQL русифицированный и с дополнительными возможностями (тип поля любой объект 1С, работа с иерархическими справочниками, итоги).

Потому что все строки модуля перед выполнением конвертируются в эквивалентные операторы SQL.

Вот этого никогда не было. SQL там имеет к коду не больше отношения, чем в Java Hibernate.

Любопытно, что ни кто ни когда не говорил о том, что любая конфигурация 1С по существу реализует - псевдо дерево.

Почему псевдо? Оно и официально называется дерево метаданных.

Владимир

Вот этого никогда не было. SQL там имеет к коду не больше отношения, чем в Java Hibernate.

Промониторьте MSSQL-ую конфигурацию 1С 7.7 /мне приходилось это делать/ ...
Более того каждая "." в именах переменных реализуется через SQL запрос.

Более того каждая "." в именах переменных реализуется через SQL запрос.

Не каждая, а только с типами Справочник и Документ. Можно спокойно работать с таблицами значений, списками значений и никакого SQL мешаться не будет.

И даже со справочниками. Кусок кода

С = Спр.Код + "/" + Спр.Наименование.

Спр.ВыбратьЭлементы();
Пока Спр.ПолучитьЭлемент() = 1 Цикл
   Если УдовлетворяетСложномуУсловию(Спр) = 1 Тогда
      Возврат Спр.Код;
   КонецЕсли;
КонецЦикла

Либо вытаскиваем всю таблицу в запрос, либо по запросу на каждую строку.

В 1С 8 оптимизировали: запрос вытаскивает по 16 (вроде) строк через top и offset. В результате на PostgreSQL тормозит адски (он не кэширует запросы). В итоге написали рекомендацию программистам конфигураций не пользоваться выборкой, а использовать исключительно запросы.

Владимир

Добавочка.
Проще всего напишите цикл сложения 100 натуральных чисел и посмотрите сколько select будет выполнено.

Владимир

Почему псевдо? Оно и официально называется дерево метаданных.

Реализовать дерево можно и с использованием массива ... /речь шла об 1С 7.7/

Владимир

В навязывании идеи, что всё, что не гарантирует ACID, то не база данных.

Есть такое.
Так тема об xBase, то вот расскажу как можно было работать с DBF и не беспокоиться об ACID /один из вариантов/.
Ну вот к примеру производится расчет табелей и по каким-либо причинам он не был завершен.
У меня это решалось просто - запускаем заново расчет табелей /и все/.
И такой подход был реализован для любых расчетов, ...
Все работало как часы.
Выключили компьютер на «пол пути», компьютер нажимает кнопку «Сделать все» и получает с 100% уверенностью требуемые отчеты, ...
Насчет кнопки «Сделать все» не выдумка.

PS: А если был «криворукий» проект /проекты/, то терялись бы.

Владимир

Правильно.
Выключили компьютер на «пол пути», бухгалтер жмет кнопку «Сделать все» ...

Проще всего напишите цикл сложения 100 натуральных чисел и посмотрите сколько select будет выполнено.

Процедура Выполнить()
  Сум = 0;
  Для Сч = 1 по 100 Цикл
    Сум = Сум + Сч;
  КонецЦикла;
  Сообщить(Сум);
КонецПроцедуры

Ни одного. У Вас другие данные? А что в select написано?

Владимир

Да может и так ...
Если находите полезным, то попробуйте добавить строки типа Контрагенты.Группа.Код сколько select будет использовано для доступа к реквизиту Код.
По идее с использованием join можно и одним select обойтись, но у 1С все не так.

В inet имеется не мало статей где «восхищаются» количеством select в простейших текстах модулей.

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

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

По идее с использованием join можно и одним select обойтись, но у 1С все не так.

Два select. А в Java аналогичный доступ через две точки один select сделает? Теоретически через join можно, но тогда надо хотя бы переменные типизировать. Ведь в момент доступа через точку в переменной Контрагент может быть ссылка на абсолютно любую таблицу. Более того, если это не Группа.Код, а Партия.Дата, то можно внезапно получить JOIN на все таблицы документов, например. А в MSSQL больше 265 таблиц объединять нельзя. Упс.

Владимир

С 1С 7.7 у вас как - «Жизнь заставила» + «Такова моя селяви»?

С 1С 7.7 у вас как - «Жизнь заставила» + «Такова моя селяви»?

Люблю необычные технологии: 1С (7.7, а теперь 8), лисп, Racket, erlang, forth.

А теперь ещё и основной заработок. Программисты не знают бухгалтерию, бухгалтеры не знают программирование. И среди 1С-ников очень мало хороших программистов (им западло и от русскоязычных терминов на смех пробивает).

Владимир

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

Владимир

Добавочка.
На одном из форумов рассказывали о «продвинутом» пользователе.
Возникла у user-а проблема ... /в далекие времена MSDOS/ Короче user удалил все содержимое диска C.
Объяснил это так:
«В Norton Commander у меня два диска C, вот я один из них и удалил».

Да для скалярных величин много select не будет, а если в цикле
будет использоваться что-то типа Итог = Итог + xxxxxxxx.yyyyyyy; то xxxxxxxx.yyyyyyy будет порождать каждый раз select.
Ладно, проехали.
Код 1С 7.7 разрабатывался в середине 90-х ...
Здесь главное, что архитектура 1С 7.7 продемонстрировала полезность использования метаданных объектов при разработке проектов.
За одно это им - РЕСПЕКТ.

Владимир

Это одно и то же. DBase/Clipper/Foxbase/Foxpro. А дальше Microsoft решил, что ему неинтересно (так как конкуренция с MS SQL и MS Access) и 64-разрядной версии Foxpro уже не существует.

Вообще то они правильно сделали.
DBF хорош и в многих случаях его использование целесообразно /впрочем то же можно сказать и об xml, json, .../.
Говорить ныне что dbf «стар и его использование маразм» лишь подтверждает то, что разработчик не понимает того, когда какой формат данных «уместно» использовать, а когда нет.

Забыл привести свой ID.

Владимир

будет использоваться что-то типа Итог = Итог + xxxxxxxx.yyyyyyy; то xxxxxxxx.yyyyyyy будет порождать каждый раз select.

Также как и в Java. А вот DBF эффективно кэшировался в ОЗУ.

Сегодня вот посмотрел /в частности/ исходный код _towlower_l() из CRT Microsoft.
Это же вычисление 2 + 2 с использованием тройного интеграла.

В https://github.com/harbour/core/ работа с строками не идеальна, но в hbapicdp.h для каждой code page можно определить

// -------------------------------------------------------
// --- 
//
typedef struct _HB_CODEPAGE {
...

 const HB_UCHAR      *upper;                               // Адрес где находятся upper chars
 const HB_UCHAR      *lower;                               // Адрес где находятся lower chars

...

Для получения lower символа просто берем код символа из таблицы.
И все!

Вот вроде все знают об том, что фундамент у дома должен быть хороший.
А у Microsoft даже для работы с строками фундамент «кривой».

Владимир

Это же вычисление 2 + 2 с использованием тройного интеграла.

Возможно, там учитываются всякие юникодные тараканы. Например, “Straße” в верхнем регистре должно стать “STRASSE”. Для преобразования в нижний 02BC 004E (ʼN) должно преобразовываться в 0149 (ʼn). Как будешь по таблице угадывать, что надо два «символа» взять?

Вот для осознания глубины проблемы: https://habr.com/ru/post/147387/

Windows native использует только TCHAR /UNICODE/. Но в Windows имеется также API для работы с CHAR.
Так вот для функций использующих locale CHAR всегда конвертируется в TCHAR, затем
выполняется затребованный функционал и результат конвертируется назад к CHAR.
Если не ошибаюсь, то такой подход используется для любой функции в native коде Windows.

Текущих задач ВАЛОМ, но желание не пропадает разработать библиотеку для работы с строками.
То, что имеем - печаль и боль.

Владимир

выполняется затребованный функционал и результат конвертируется назад к CHAR.

В целом, это логично. “Straße” можно и в iso-8859-1 написать. А значит надо либо делать выжимки из юникода для каждой кодовой страницы, либо (что проще) делать все преобразования через юникод.

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

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

Великолепно!
Как мне одна бухгалтерша говорила:

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

PS: Бухгалтера - огромнейшая вселенная глупости, ...

Владимир

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

Вот моя первая инструкция:

Инструкция по разработки проекта HelloWorld:
 -  запустить IDE;
 -  три дня смотреть на экран и ничего не делать;
 -  добавить в код вывод сообщения "Hello World";
 -  проверить функциональность проекта;
 -  затем всем поведать о разработанном проекте /с не менее 10 тредами флуда/.

Владимир

В треде о Метапрог высказываются суждения типа «Rust и D еще массы еще не используют».
Для прикладных задач, наверное такие суждения верны, а для системной разработки скорее всего нет.
Не использую Rust, D и Go лишь по причине того, что для разработки API мне вполне хватает C/C++.

Владимир

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

Не расстанусь с комсомолом - буду вечно молодым

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

Не возраст старит душу человека.

Конечно. Возраст – это цифири в паспорте.

SQL даёт лишние накладные расходы. Закрытие месяца на 1С 7.7 занимает 3 секунды, закрытие месяца для той же организации на 1С 8 занимает около 2-3 минут. Алгоритмы те же

вдругорядь прозреваю: на каком-нибудь MUMPS-е ещё быстрее работало бы.

на каком-нибудь MUMPS-е ещё быстрее работало бы.

Сомневаюсь. В MUMPS всё строками хранится. А значит, любая арифметика содержит дополнительное преобразование и числовые данные дольше читаются.

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

Кстати, можно провести аналогии между языками и СУБД. DBF аналог Си (ключевое требование zero cost abstractions), MUMPS аналог PERL (всё является строками, максимальная гибкость), SQL аналог F#/Haskell (сборщик мусора, декларативные конструкции, гарантии инвариантов на операциях, сложный компилятор).

Вот с async/await + MQ скоро будет фактический отказ от прямого многопоточного программирования. Несмотря на то, что нормальная работа через разделяемую память в разы эффективней.

Мода всегда побеждает здравый смысл.

Это не мода, а здравый смысл и есть. Работа через разделяемую память масштабируется ровно до тех пор, пока вам хватает одного сервера. А когда вам его хватать перестанет, вы придёте к тому же MQ. Не говоря уже о том, что асинхронный io позволяет эффективнее использовать процессорные мощности и упрощает разработку и поддержку системы в целом.

Но в будущее, конечно, могут смотреть не только лишь все.

В MUMPS всё строками хранится.

зато числа в канонiчном представлении сразу – отсортированные строки. то есть, логически это хешмапы ключ-значение строки в бинарные строки.

потом, МУМПС иерархические. тут тоже что-то можно использовать.

потом, глобалы и локалы. для оптимизации.

потом, функции могут обрабатывать бинарные строки и блобы. то есть, результат зависит от интерпретации. и если интерпретировть не надо – можно написать свои такие функции.

то есть, физически это BTree+ с бинарными строками, которые интерпретируются как угодно. BCD, например для денежных типов.

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

но это ж всё равно только данные. те же индексы например – CDX отдельно. а потом ещё код какой-то нужен, который в DBF не хранится и хранится отдельно. а тут в мумпсах «кеширующий сервер глобалов и рутин», и индексы воссоздавать или какой-то ОО слой изобразить на рутинах можно невозбранно.

опять же, можно подключать ZDLL и свой FFI. с функциями, интерпретирующими бинарные блобы.

MUMPS аналог PERL (всё является строками, максимальная гибкость),

вот если сравнивать PERL (и самопальные ОО системы на perl4/perl5) и его костыли с $_, my и прочим. то да, немного похоже. но в перле что-то на уровнях вложенности контекстов можно накрутить, а в мумпсе как в фокале всё чисто строки, и «стек контекстов» – какое-то извращение из-за того что в языке по сути нет нормальных замыканий потому что оно строчно-ориентированное а не как в лиспах ориентировано на выражения (где first class object может быть символом, функцией, замыканием).

с вложенными контекстами там извращаются по сути, что в MUMPS классическом, что в Perl4/Perl5.

в постклассическом – CacheObject Script добавилось ООП. нечто похожее, но менее проприетарное: PSL aka Profile Script Language под GT.M, MAGIC (какая-то ООП система, ещё более закрытое и проприетарное чем COS).

в YottaDB (форк GT.M обновлённый перезапуск от тех же разработчиков, команда разделилась) добавили наконец нормальный C API и Go, планируют добавлять Rust Python Perl. уже есть JS, как через C API так и отдельно.

в общем, на M как на недоязычке свет клином не сошёлся. идея – язык отдельно, хранилище отдельно. мухи и котлеты – отдельно. вполне здравая.

вообще, ещё на Lua какая-то база похожая на MUMPS была. вот Lua также напоминает язык из LambdaMOO: тоже ООП, акторы, что-то на метатаблицы похожее только свой велосипед.

и там и там – своя БД, свой язык.

SQL аналог F#/Haskell (сборщик мусора, декларативные конструкции, гарантии инвариантов на операциях, сложный компилятор).

Prolog/Datalog и Semantic Web с RDF внезапно представляют сладкую парочку. настолько что готовых модулей дофига.

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

ну то есть, опердень при закрытии должен по идее из DBF перебирать вообще всё, а какой-нибудь FOR $ORDER – только по отсортированному, и что-то с предыдущих иерархий уже использовать.

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

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

Во-первых, с точки зрения производительности надо с по-разному относится к процессам на своём узле и на чужом узле. Во-вторых, прямая отправка данных через RPC в этом случае всё равно эффективнее любого MQ. Примеры эффективного распределённого приложения: Plan 9, DNS.

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

По сравнению с чем? С однопоточной программой - да. С классической многопоточной - нет.

и упрощает разработку и поддержку системы в целом.

Вот это основной аргумент. Причём под этим флагом что только ни делали: вводили блок-схемы, отказывались от блок-схем, вводили ООП, отказывались от ООП (наследования), вводили ФП, вводили сборщик мусора, отказывались от сборщика мусора, … Универсальный аргумент, потому что субъективный.

те же индексы например – CDX отдельно. а потом ещё код какой-то нужен, который в DBF не хранится и хранится отдельно.

CDX и стандартная библиотека для работы подразумевается неотъемлемой частью DBF-системы. Также как в компиляторе Си подразумевается препроцессор и линкер, хотя они тоже хранятся отдельно.

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

Но не бесплатно. Всё это требует ресурсов, даже если этими возможностями не пользоваться.

тогда уж векторный какой-то

Я не про синтаксис, а про вагон требований к СУБД/языку, которые используют кучу ресурсов, а обеспечивают только невозможность выстрелить себе в ногу.

опердень при закрытии должен по идее из DBF перебирать вообще всё, а какой-нибудь FOR $ORDER – только по отсортированному

Никто не мешает в DBF сделать индекс или вообще отсортировать строки прямо в таблице.

Там в этом x

Какой вы симпотный ;)

Владимир

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