Далее, MUMPS сервер СУБД обычно выступает для БД «кеширующим сервером глобалов и рутин». Рутины компилируются в байткод (при этом есть возможность вызывать С разделяемые библиотеки), и кешируются MUMPS сервером. Данные многомерных ассоциативных массивов (глобалов) тоже кешируются. Физически это выглядит как подкачка страниц BTree хранилища, в котором хранятся произвольные байтовые, битовые строки.

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

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

Индексы делаются вручную. Запросы делаются вручную. Для всего этого вручную пишутся нужные рутины.

К СУБД можно подсоединиться телнетом или по ssh и напрямую в REPL вызывать какие-то команды. Или использовать её как встроенную в приложение. Или вызывать команды через более быстрый callout интерфейс.

Есть несколько популярных реализаций MUMPS СУБД: Intersystems Cache, MiniM DB, опенсорные реализации. Из которых наиболее популярна GT.M. Недавно появился её форк от той же команды основных разработчиков YottaDB.

Cache стоит немного особняком, потому что в своё время, в начале 2000х Intersystems скупил всех основных конкурентов. Получилось тогда на рынке MUMPS СУБД 90% — Intersystems и 10% — все остальные. Они доработали ОО интерфейс к СУБД, сделали ОО язык Cache Object Script. Также «из коробки» Cache умеет и ООСУБД и SQL интефрейс (вдобавок к старому MUMPS интерфейсу многомерных массивов, глобалов). Итого три в одном, и можно выбирать под задачу какой больше нравится.

Cache хорошая реализация, но платная. GT.M и YottaDB опенсорсные, с открытыми исходниками.

GT.M в своё время написали хороший компилятор MUMPS. В итоге байткод рутин не интерпретируется, а компилируется в *.o объектные файлы, подгружается как обычные .so. Также через ZDLL можно подгружать обычные сишные .so.

Есть аналоги ОО языка поверх GT.M (Profile), SQL интерфейса и веб-доступа (JS, Ajax, Node.js).

Недавно появился форк GT.M. Основные разработчики поделились на две команды. Вторая стала пилить форк под названием YottaDB.

В YottaDB появился наконец C API к «хранилищу глобалов» и далее Go API, многопоточка. В планах поддержка Rust (точно) и остальных 10500 языков через C API.

В итоге можно писать приложение баз данных на любом языке, который нравится (не обязательно MUMPS M языке, который выглядит архаично).

Есть простая наглядная обучалка

Странно, что MUMPS технологии активно не используют. На мой взгляд, это прогрессивная технология СУБД родом из 1960-х, ещё до зарождения этого вашего сиквела.

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

NoSQL ещё до зарождения термина NoSQL.

При этом отлично реплицируется, масштабируется, интегрируется с чем угодно.

И вообще, зачем вам SQL если всё равно

а) вы не можете написать приложение баз данных, бизнес-логику целиком на SQL, а пользуетесь каким-то его ограниченным подмножеством?

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

в) хранение данных реализуете не напрямую через SQL, а через какой-то промежуточный слой типа ORM

г) всё равно напрямую вызываете какие-то процедуры СУБД. Какая разница тогда, хранимки диалектов SQL или рутины MUMPS'? При этом MUMPS лучше стандартизирован и универсализирован. На нём можно целиком написать полезное приложение, что более трудоёмко на хранимках или курсорах.

д) используете из SQL только SELECT для отчётов и какой-то CRUD DML для данных ? всё то же самое можно делать и из рутин MUMPS

В общем, а нужен ли вам вообще этот SQL. Или ну его в баню.

книжка по MUMPS

Евгений Каратаев разрабатывает коммерческую проприетарную реализацию MUMPS под названием MiniM. Есть реализации MiniM server под все основные ОС и встраиваемая реализация MiniMono. Работает под Linux, FreeBSD, Android, MacOSX, Windows.

MiniMono бесплатно, MiniM бесплатен на 3 пользователя (далее за деньги). Это ограничение на максимальное количество MUMPS процессов JOBS. В опенсорсном GT.M и его форке YottaDB, насколько известно, таких ограничений нет.

Ещё он написал книгу по MUMPS технологии.

А стандарта SQL как обычно не хватает для полноценных СУБД?

Конечно же, не хватает. По определению: в SQL входит DDL и DML, а также хранимые процедуры (разные в разных реализациях). В итоге, на SQL невозможно написать целиком и полностью приложение баз данных, все его части (или это будет завязано на конкретную реализацию хранимок, T-SQL или PL/SQL).

В MUMPS — можно.

Е. Каратаев, «Чем мне не нравится SQL»

ППКС. Полностью с ним согласен, с каждым словом.

Но доказательств конкретных нет. Всё гладко.

Ничего нового. Время идёт, ничего не меняется:

Пользователи системы обнаружили, что существовавшие тогда в СССР различные ВЦ (вычислительные центры), ПКБ (проектно-конструкторские бюро), НИИАСПУ ( научно-исследовательские институты планирования и управления) и т.д. энергично саботируют продвижение системы MUMPS в СССР. Причина была весьма простой: применение MUMPS позволяло многим пользователям при решении своих несложных информационных задач обходиться без наемных контор-программистов. Большинство этих институтов напирало на использование в информационно-экономических задачах системы ОС-РВ (RSX-11 – системы реального времени для управления технологическими процессами и оборудованием). Причина очевидна – можно было продолжать использовать пакетный режим обработки информации на новейшей технической базе PDP-11. И тем самым обеспечить себе объемы работ и прочие блага.

отсюда

Освоив программирование на PL/1 (Язык программирования №1 во всем мире - проявление американской гордыни) я пребывал в эйфории - мне казалось, что нет такой задачи, которую я не смогу быстро сделать на этих машинах.

...

Начитавшись КОДАСИЛа и применив собственную изобретательность я в одиночку написал на PL/1 собственную реализацию базы данных, которая чудесно соответствовала характеру решаемых мной задач оперативного управления. Ушло на это всего три месяца работы включая всю отладку. Структуру базы данных можно было легко и оперативно изменять в темпе возникновения новых требований производства.

После чего в быстром темпе на эту базу данных нагромоздилась куча задач оперативного управления и, как водится, отчетности перед выше лежащими конторами. Вынужден признать, что реализация оказалась весьма эффективной и стала обрастать все новыми приложениями, подобно старому пню, обрастающему мохом. Когда появился MUMPS, я с изумлением втупил в борьбу с собственноручно созданной технологией, которую никак не давали остановить пользователи и министерский ВЦ (еще бы - они теряли загрузку ЭВМ!).

...

Поскольку в моих дневниках имелись записи о расходе календарного времени на реализацию некоторых задач на языке PL/1, мне было интересно, сколько же времени уходит на ту же самую задачу в MUMPS. Соотношение оказалось впечатляющим: то, на что раньше ушло три месяца, в интерактивном режиме на MUMPS реализовалось за три дня! (Замечу, что сравнение не очень корректное – есть разница между первой реализацией проекта и второй – сказывается накопленный опыт понимания прикладной проблемы).

читать сначала, про историю внедрения MUMPS в СССР

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

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

Я вот не понимаю, почему все мучаются, используют какое-то своё разное подмножество SQL (почти как в С++), какие-то разные диалекты хранимок и мидлвари поверх. И всё ради чего? Ради возможности делать SELECT ... JOIN ... произвольного вида?

У SQL доля функций, скрытых от кодера, на много порядков выше доли функций, с которыми он работает даже в очень крупном проекте, потому сравнение с C++ некорректно. Если в СУБД есть ограничение или возможность, выходящая за рамки стандарта, то диалект без особых колебаний дорабатывается. Например, ограничение кол-ва строк не было прописано в стандарте, и разные СУБД сделали принципиально разные реализации этого механизма, которые не могут быть использованы другим синтаксисом. По этой причине SQL не может стать унифицированым даже при самом большом желании, можно лишь пытаться минимизировать отличия.
У MUMPS всё еще печальнее, и для повышения стандартизации взаимодействия со внешним миром те же InterSystem сделали все-таки SQL фейсы к базе.

При этом отлично реплицируется, масштабируется, интегрируется с чем угодно.

Это основано на каких-то фактах, или на заверениях InterSystems?

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

Каждая база MUMPS уникальна и язык взаимодействия с ней приходится изучать заново. В SQL я знаю, что у меня в фундаменте есть транзакции, таблицы, стандартные операции с ними. Что есть в фундаменте MUMPS? Да ничего - делай что хочешь. Отсюда и проистекают мои сомнения по поводу репликаций, масштабирования, и интеграции.

Какая разница тогда, хранимки диалектов SQL или рутины MUMPS'? При этом MUMPS лучше стандартизирован и универсализирован. На нём можно целиком написать полезное приложение, что более трудоёмко на хранимках или курсорах.

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

У SQL доля функций, скрытых от кодера, на много порядков выше доли функций, с которыми он работает даже в очень крупном проекте, потому сравнение с C++ некорректно.

Очень даже корректно. С++ у каждого свой, и написав кучу лапшекода на каком-нибудь Boost и получится это самое «на много порядков выше». Сейчас хоть не C++03, и RTTI/исключения/... более-менее везде нормально реализованы. Проблема что с С++, что с SQL в том, что а)стандарт избыточно сложный б)стандарт необязательный в)стандарт какой-то «декларативный», куцый, недоделанный — стандартизирует не все функции и задачи баз данных.

Если в СУБД есть ограничение или возможность, выходящая за рамки стандарта, то диалект без особых колебаний дорабатывается.

В итоге мы имеем 10500 разночтений стандарта, и 100500 имплементаций какого-то подмножества в различных СУБД. В итоге, эта новомодная фича «хранимки на обычном языке программирования» (что у оракла, что у постргесса). Почему она вообще нужна? Потому что на самом «стандартном» SQL такое никак не сделать.

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

типичный vendor lock-in во все поля. Так что же стандратизирует этот «стандарт» SQL? Минимум-миниморум из всех функций, которые нужны для написания полноценного приложения баз данных.

У MUMPS всё еще печальнее,

Наоборот, веселее: есть ANSI стандарт, есть MDC комитет по стандартизации и последняя утверждённая им версия. Есть набор расширений в рамках стандарта, которые должна уметь типичная MUMPS система. При этом чётко выделены «стандартные» функции и расширения и implementation-specific.

Функционально, M это полноценный язык программирования. И его, стандартизированного ANSI или MDC вполне достаточно, чтобы написать на нём приложение баз данных, полностью. В отличие от того же SQL.

Возможностей расширений и настроек оптимизации тоже больше. Можно писать расширения на С. Можно переменные делать локальными или глобальными, персистентными и хранимыми в СУБД.

Есть стандартный отладчик и трассировки. Можно залезть в запрос, и посмотреть как он строится (ну то есть, запросы как и индексы всё равно нужно строить вручную. Нет никакого отдельного профилировщика запросов с отдельными способами оптимизации плана, «исчисления хинтов». Запрос это обычная рутина на M, с процедурной обработкой данных. В итоге отлаживается и трассируется как обычный код на M).

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

MUMPS это такой «ассемблер баз данных», по сути.

и для повышения стандартизации взаимодействия со внешним миром

что означает эта фраза? для взаимодействия с внешним миром SQL интерфейс не обязателен и не нужен.

и для повышения стандартизации взаимодействия со внешним миром те же InterSystem сделали все-таки SQL фейсы к базе.

они их сделали из маркетинговых соображений. Есть основная модель данных MUMPS , «прямой доступ» на глобалах, разреженных многомерных ассоциативных массивах. Поверх этой модели данных можно запилить свою любую. Например, те же SQL интерфейсы реляционок изобретали неоднократно. Это не единственный, и не обязательный интерфейс.

Затем также из-за маркетинговых соображений после макросов добавили ОО расширение M. Появились классы, свойства и методы. Персистентные хранимые объекты. Физически эти объекты всё равно транслируются в многомерные глобалы с прямым доступом.

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

Логически это три (или больше, если запилить своё) альтернативных представления, моделей данных. А физически все они представляют собой глобалы.

Есть ODBC интерфейс, к глобалам, например. И прочее.

SQL там не нужен, и не обязателен. Но если хочется SELECT написать — есть такая возможность.

При этом отлично реплицируется, масштабируется, интегрируется с чем угодно

Это основано на каких-то фактах, или на заверениях InterSystems?

На фактах. Медицинских. И логических. Можно почитать те же примеры внедрения Cache. Сколько одновременных рабочих мест, какие требования к быстродействию, распределённых серверов.

Можно почитать, например про Ensemble и его архитектуру, в котором Cache c глобалами является основой федеративных баз данных.

Можно почитать ту же книжку по M про возможности интеграции с чем угодно. Всё это текст, можно коннектиться телнетом и плеваться текстом. Можно одной командой M скопировать (MERGE) глобал с другой машины, с его рабочего пространства. С точки зрения языка остальная логика абсолютно прозрачна. Некоторые глобалы хранятся в текущей базе данных, некоторые удалённо берутся с другого сервера. Для чего настраиваются пространства имён. Есть репликация и прочее.

Можно посмотреть на примеры реализации веб-сервера, почтового и прокси на том же M. Код в несколько экранов.

Можно посмотреть на веб-сокеты, EWD.js про GT.M+Node.js и интеграцию с JS и асинхронщиной. Тоже довольно просто реализовано.

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

этот «язык взаимодействия» — это хранимые процедуры, рутины. их стандартизированный интерфейс.

сами данные имеют структуру. Можно прочитатать «Extreme database programming with MUMPS Globals» про то, как отображаются на глобалы списки, деревья, графы, массивы.

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

Что есть в фундаменте MUMPS? Да ничего - делай что хочешь.

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

Транзакции есть (команды TSTART,TCOMMIT, TROLLBACK). Блокировки есть (LOCK, LOCK +, LOCK -). Блокировки на элемент глобала и его поддеревья.

Индексы делаются вручную. Для чего нужно почитать книжку.

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

Что-то типа ORM на M тоже можно сделать простыми рутинами.

Да ничего - делай что хочешь.

И это даёт особенную гибкость. Ну да, база MUMPS schemaless, то есть можно изменять что угодно, как угодно, когда угодно. Но обычно всё-таки делают какие-то индексы, какие-то запросы и какие-то рутины типа ORM для изменения. Которые можно повторно использовать. В отличие от SQL.

Отсюда и проистекают мои сомнения по поводу репликаций, масштабирования, и интеграции.

Читайте книжки — там всё написано.

Читайте документацию вендора, примеры конкретных применений. И я не говорю именно про Cache, хотя там хорошая документация. А про те же GT.M, YottaDB.

Те же исходники на мумпсе на том же гитхабе, например. Например, ту же VistA FileMan и прочее, или ещё какой конкретный код на M.

Семантика >> синтаксис.

так вот семантики в голом SQL и не хватает.

Я видел довольно серьёзные приложения «чисто на хранимках». Но когда чтение файла или запуск внешней команды или работу с сокетами пытаются делать на SQL хранимках, это уже попахивает извращениями.

А код на M — это обычный язык программирования. Только данные многомерные.

И потом, сейчас в той же YottaDB можно через C API и без MUMPS как языка программирования обойтись, используя глобалы через API. Тот же GlobalsDB от InterSystems что-то похожее делает: взяли MUMPS, отодрали язык M, оставили хранилище глобалов, и сверху присыпали жаваскриптом.

И вот оно, радуйтесь — новомодное хипстерское NoSQL.

Есть несколько вариантов «объектно-ориентированного MUMPS»: Cache Object Script проприетарный, MUMPS II, Magic, Profile и прочие ООсубд языки.

Сейчас вполне можно взять их за образец, либо можно запилить свой, на YottaDB и C API.

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

Для какой именно задачи «удобен SQL» ? ну разве что SELECT ... JOIN ... расписать запросы к любой БД любой структуры, на несколько страниц.

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

Серебрянные пули не нужны для крупных модульных проектов.

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

И это просто ещё одна технология в toolchain разработки баз данных. Незаслуженно забытая, на мой взгляд.

Да, код на M выглядит странно. «Ассемблер баз данных», лол. Ну так и не используйте M как язык. Используйте глобалы как хранилища структурированных, многомерных данных и свой хипстерский ООсубд недоязычок, ну или напрямую C API как в YottaDB.

И вообще, зачем вам SQL

ACID?

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

Таблицы, многомерные и нереляционные. По сути записи ключ-значение. Для них поддерживается ACID

А для связей 1:1, 1:М, М:М поддерживается? Или писать?

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

Оптимизация запросов? Планы запросов? Всё вручную? Использование уже загруженных в память данных соседним запросом - тоже вручную писать, отслеживать и отлаживать? Репликация?...

Тут львиная часть кодеров даже sql знать не хочет, подавай им ОРМ и баста. А им «закат солнца вручную»? Тормоза ОРМ-ов скоростью пули покажутся...

Что же за тенденции такие: одним сайты на си писать, другим операционки на JS-е, третьим SQL не надо, хотим как в dbf-ах всё руками делать...

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

Так тогда почти все NoSQL неполноценные...

это да.

Что же за тенденции такие: одним сайты на си писать, другим операционки на JS-е, третьим SQL не надо, хотим как в dbf-ах всё руками делать...

зато работает так, как ты сам написал. без всякого неожиданного поведения.

это если написать и отладить, сложность же подобных проектов говорит о том, что на 99% доведены они до прилично работающего состояния не будут

но они есть

да ради ТНБ, чего только на свете нет! Но в массе своей SQL никакой «мумпс» не заменит - «а у них мощностей не хватит»

Проблема что с С++, что с SQL в том, что а)стандарт избыточно сложный б)стандарт необязательный в)стандарт какой-то «декларативный», куцый, недоделанный — стандартизирует не все функции и задачи баз данных.

Ты ведешь сравнение на поверхностном уровне «феррари такая красненькая, а камаз - желтенький».
В C++ все действия программы описываются самим языком. В SQL запрос является описанием команды для огромного черного ящика из миллионов строк кода, и именно этот черный ящик первичен, а язык запросов - вторичен. Там, где были какие-то общие детали реализации - там сделали одинаковый синтаксис языку. Но различия реализаций все равно огромны, и устройство базы на одной СУБД обычно нельзя просто так перенести на другую, независимо от различия/одинаковости диалекта SQL.

В итоге, эта новомодная фича «хранимки на обычном языке программирования» (что у оракла, что у постргесса). Почему она вообще нужна? Потому что на самом «стандартном» SQL такое никак не сделать.

PL/SQL, PL/pgSQL и ISO SQL/PSM являются близкими диалектами. Заныривая вглубь сервера уже не получится достаточно унифицировать язык, потому ребята в постгресе решили «пишите на чем хотите».

типичный vendor lock-in во все поля. Так что же стандратизирует этот «стандарт» SQL? Минимум-миниморум из всех функций, которые нужны для написания полноценного приложения баз данных.
Наоборот, веселее: есть ANSI стандарт, есть MDC комитет по стандартизации и последняя утверждённая им версия. Есть набор расширений в рамках стандарта, которые должна уметь типичная MUMPS система. При этом чётко выделены «стандартные» функции и расширения и implementation-specific...
MUMPS это такой «ассемблер баз данных», по сути.
Затем также из-за маркетинговых соображений после макросов добавили ОО расширение M. Появились классы, свойства и методы. Персистентные хранимые объекты. Физически эти объекты всё равно транслируются в многомерные глобалы с прямым доступом.

Есть проблема: стандартный M ужасен, что-то уровня упомянутого ассемблера, это пережиток прошлого и на нем прикладные решения нынче никто не пишет (я не говорю про энтузиастов, которым и brainfuck норм), ведь даже на среднем масштабе (по современным меркам) программа M становится неподдерживаемой горой спагетти. Потому, все современные решения, связанные с MUMPS, пишут при помощи модификаций языка, ровно как никто не пишет проги на ассемблере - почему-то все предпочитают C++.
И здесь получается vendor-lock намного хуже, чем с SQL, потому что с SQL нужно учитывать особенности конкретной СУБД при портировании, а в MUMPS - только переписывать систему заново, ведь у каждого вендора свой диалект и свои особенности реализации.

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

Нахрена мне нужен этот чорный ящик, с неожиданным поведением и быстродействием?

И здесь получается vendor-lock намного хуже, чем с SQL

Нет, не получается. Если не завязываться на Cache и его Cache Object Script, а смотреть в стандартный MUMPS.

потому что с SQL нужно учитывать особенности конкретной СУБД при портировании,

Потому что стандарт SQL убог по определению. По функциональному назначению.

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

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

«диалекты MUMPS» сильно не отличаются. Фактически, это команда new и ещё пара команд. Всё остальное везде стандартное. Потом, на уровне диалектов чётко выделены функции из стандарта, функции % из расширений, Z и ZZ-расширения.

В итоге просто читая код понятна степень его соответствия стандарту.

Ну и учитывая что полноценных реализаций MUMPS, всего 2.5: Cache, GT.M, YottaDB, MiniM — код между ними портировать несложно. И как правило, и не нужно — хватает стандартного M в виде реализации стандартов ANSI и MDC.

Раньше, кстати, пытались стандартизировать расширения в том же MDC. Например, CHUI / TUI стандартизировали. Пытались и GUI стандартизировать, и текстовый REPL. Но эти стандарты не доделали.

В целом «стандартный M» на несколько порядков стандартнее и предсказуемее чем «стандартный SQL» (который всё равно ничего не умеет).

Есть проблема: стандартный M ужасен, что-то уровня упомянутого ассемблера, это пережиток прошлого и на нем прикладные решения нынче никто не пишет (я не говорю про энтузиастов, которым и brainfuck норм), ведь даже на среднем масштабе (по современным меркам) программа M становится неподдерживаемой горой спагетти.

Конструкций языка в целом достаточно. Да, нет например пространств имён, полноценных замыканий и продолжений. Какой-то колхоз со стеком и NEW вариантами, рутины можно написать как сопрограммы с множественными точками входа. Напрямую лямбду никак не написать, нужно как-то извращаться, например.

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

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

Но, опять же. Для задач быстро что-то такое написать этого FOCAL-подобного языка (как на БК.0101) — достаточно.

Потому, все современные решения, связанные с MUMPS, пишут при помощи модификаций языка,

Каких именно «модификаций» ? Cache Object Script — это свой проприетарный велосипед.

Эти модификации языка не нужны. Можно писать код прямо на стандартном M.

ровно как никто не пишет проги на ассемблере - почему-то все предпочитают C++.

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

Потом в каком-нибудь Qt не хватает возможностей «стандартного С++» и для moc они изобретают свой велосипед — компилятор сигналов и слотов, с коллбеками.

Так нужен ли там этот сложный, громоздкий именно с++?

спагетти. Потому, все современные решения, связанные с MUMPS, пишут при помощи модификаций языка

вот например Profile. ООсубд язычок, альтернативный проприетарному Cache Object Script. Где-то на гитхабе была открытая реализация (как бы не в репозиториях YottaDB).

«Объектно-ориентированные» модификации языка транслируются в стандартный M. И совершенно одинаково выполняются везде.

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

Нахрена мне нужен этот чорный ящик, с неожиданным поведением и быстродействием?

Тебе не нужен - не используй. Но 100500 остальных пользователей SQL на твои проповеди не купятся, зря стараешься.

100500 кодеров не могут осилить хотя бы SQL, да. не говоря уже о чём-то большем.

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

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

На фактах. Медицинских. И логических. Можно почитать те же примеры внедрения Cache. Сколько одновременных рабочих мест, какие требования к быстродействию, распределённых серверов.
Можно почитать, например про Ensemble и его архитектуру, в котором Cache c глобалами является основой федеративных баз данных.

Я что, должен сам искать? Тогда я нашел:
https://en.wikipedia.org/wiki/Epic_Systems#UK_experience
Клиника в Британии купила продукт крупнейшего разраба на Cache - Epic. В итоге работа в клинике встала, руководители клиники уволены. В Дании ввели эту систему, и теперь врачи только на нее и жалуются, потому что мешает работать, а не помогает.
В Питере есть контора, которая пишет СУБД для западных мед учереждений с высокопроизводительным доступом на чтение, и там SQL.

А ещё есть VistA которая написана с 1980 года. Куча историй успеха, исходники на гитхабе, 200+ мегабайт кода на М.

Отдельные проекты ничего не показывают про саму технологию. Ну у этих не получилось — у других получилось же.

И тогда ты должен знать, что MS SQL и Oracle обскакивают мускуль и постгрес в полтора-два-три и больше раза в зависимости от запроса.

Ссылки на исследования есть? Особенно интересует сравнение MS SQL и PostgreSQL. При том нормально настроенных, поскольку из коробки постгря идёт настроенная не на максимум производительности, а на возможность запуститься на Самом Древнем Утюге.

да, особенно интересно как конфиги настраивал по сравнению с дефолтным.

И потом, сейчас в той же YottaDB можно через C API и без MUMPS как языка программирования обойтись, используя глобалы через API. Тот же GlobalsDB от InterSystems что-то похожее делает: взяли MUMPS, отодрали язык M, оставили хранилище глобалов, и сверху присыпали жаваскриптом.

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

Для какой именно задачи «удобен SQL» ? ну разве что SELECT ... JOIN ... расписать запросы к любой БД любой структуры, на несколько страниц.
Всё остальное SQL делает плохо. SQL просто не удобен, для разработки нормального приложения баз данных целиком.

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

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

Может быть даже и позволяет, но какова трудоемкость? На разработку PostgreSQL потрачено сотни тысяч человекочасов - у меня нет таких ресурсов для разработки нужного мне «более производительного решения».

Таблицы, многомерные и нереляционные. По сути записи ключ-значение. Для них поддерживается ACID

А для связей 1:1, 1:М, М:М поддерживается? Или писать?

Это NoSQL, там всё N:M:O:P... В Cache есть инструменты для создания ACID решений, но ручками тоже придется поработать.

Так тогда почти все NoSQL неполноценные

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

зато работает так, как ты сам написал. без всякого неожиданного поведения

Это и есть неожиданное поведение. Все люди ошибаются.

Нахрена мне нужен этот чорный ящик, с неожиданным поведением и быстродействием?

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

Нет там никаких особенностей и диалектов. Есть чётко определённое в стандарте поведение (в отличие от декларативного и неполного SQL). Есть на уровне стандарта требования к полноте реализации, что должно быть сделано обязательно. Есть понятная оценка полноты реализации.
Если не завязываться на Cache и его Cache Object Script, а смотреть в стандартный MUMPS.

А стандартным MUMPS пользоваться никто не будет по причинам, которые я тебе уже написал, и котоыре ты почему-то проигнорировал. «Гладко было на бумаге - да забыли про овраги». Я просто для сидящих тут поясню, что такое программа на MUMPS:

Q N R,Q,C,D,E,W,B,G,H,S,T,U,V,F,L,P,N,J,A S N=$G(N),Q='N,F=Q+Q,P=F+F,W=$L($T(Q))
 S W=$E(W,Q),S='N_+N,W=W-F*S,L=$G(L),R=$C(Q_F_P),R(F)=$C(F+Q_F),R(P)=$C(W-F) W #
 S T=$E($T(Q+F),F,W\S)_$C(W+S+F) X T S B=$P(T,$C(P_P),F),C=B\(W*W),D=B-(C*W*W)\W
 F G=S-Q:F:S+F+Q S E=B-(C*W*W+(D*W)),H=$E($T(Q),G),@H=$S(@H<S:'Q,Q:N)_@H,T=C_D_E
 F A=Q:Q:W\S S J=$E(T,A),C(F)=$S(J>(F+Q)&(J<(S-F)):Q,Q:+N),C(P)=$S(J#F:Q,Q:+N) D
 .S C(Q)=$S(J<(S-F):+N,Q:Q),C(F+Q)=$S(J>Q&(J<(S-F))&(J'=(P+'L))&(J'=(P)):Q,Q:+N)
 .S H('L)=L F  S H(N?.E)=$O(C(H('$G(N)))) Q:H('+L)=L  S F(A,H('L))=C(H(W[(W\S)))
 F U=Q:Q:P W !,R F V=Q:Q:P+F W $S(F(V,U):'Q,Q:$C(P_(W\S))) W:'(V#F) $C('N_F_F+F)
 W !!,R(F)_C_R(P)_D_R(P)_E_R(F) X $RE($E($T(Q),Q+F,P+Q))_R(P)_'N W # G:N=L Q+F Q

:D Q^ROU


|..|..|..|
|..|..|.0|
|..|.0|0.|
|..|00|..|

 00:13:24

Ну и учитывая что полноценных реализаций MUMPS, всего 2.5: Cache, GT.M, YottaDB, MiniM — код между ними портировать несложно

Да, только портировать нужно будет не отдельные детали интерфейса, а весь код базы данных на этом Brainfuck-е.

Так нужен ли там этот сложный, громоздкий именно с++?

Я терпеть не могу C++, я просто привел пример высокоуровневого языка, который применяют взамен низкоуровневому, несмотря на то, что высокоуровневый убог и проблематичен, но на высоком уровне все равно проще писать большие проекты.

А ещё есть VistA которая написана с 1980 года. Куча историй успеха, исходники на гитхабе, 200+ мегабайт кода на М.

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

Куча историй успеха, исходники на гитхабе, 200+ мегабайт кода на М.

Это не положительное описание. 140 Мб кода для системы (спецом скачал и посчитал) со скромным функционалом, который нашинкован в тысячи самостоятельных велосипедов. Сами взгляните: https://github.com/OSEHRA/VistA-M/tree/master/Packages/Dietetics/Routines

Владимир

Не использую Firebird.
Пришлось однако «вникнуть» при переводе нескольких проектов Delphi + Firebird в 1С 7.7 /такова моя селяви/.

Но вот любопытно на ЛОР Firebird вообще ни когда не флеймится.
Почему так?

Но вот любопытно на ЛОР Firebird вообще ни когда не флеймится.

В моих тредах регулярно на него скатываются. Firebird в основном в офтопике используется, и в основном в делфи, так-то он особо никому не нужен. Сам разраб его забросил, и по сравнению с другими FOSS-проектами у него нет никаких преимуществ. У него нет репликации из коробки, например.
У меня за годы работы с ним возникло стойкое впечатление, что его в спешке нафаршировали фичами, в надежде, что «когда-нибудь потом доделаем, а пока оставим задел на vendor-lock для нашего стэка». Но «когда-нибудь» так и не настало, и в итоге код отдали на растерзание сообществу.

Владимир

Firebird не заброшен, а активно развивается.
Дооолго они правда не могли реализовать Firebird 3.0.
Ныне у них уже на подходе Firebird 4.0 с репликацией из коробки.
Разработчики этой СУБД «толкутся» на sql.ru.
Но там стиль обсуждения такой, что ЛОР против них - «малое, милое дитя».

Дело в том, что делфи популярен в СНГ и китае, потому что в этих странах все плюют на стоимость лицензии, которая для коммерческого пользования составляет $2000+. Разрабы еще предполагали, что будут регулярно доить с тебя деньги за новые версии.
Есть как минимум три библиотеки прямого доступа к FB: InterBase Express, FIBPlus, IBObjects. Собсна, практически все библиотеки прямого доступа предназначены для Firebird, таким образом, Delphi весьма удобно для FB.
А вот теперь назови мне другую среду/язык, в котором используют FB? Реально единственное возможное применение я вижу в качестве Embedded базы с MVCC, что есть редкость, но не в последнюю очередь это редкость потому, что кому вообще может понадобиться MVCC в embedded базе?

Но там стиль обсуждения такой, что ЛОР против них - «малое, милое дитя».

Здесь просто банят.

Владимир

Не агитирую за использование Firibird, а так для продолжения диалога.

К примеру в 1С 7.7 используя ODBC можно выполнить любой SELECT, INSERT, ...
Впрочем c использованием ODBC можно работать с Firebird с PHP и еще 100 языках.
Кстати драйвер ODBC для Firebird позволяет использовать TSQL, ...

Библиотеки прямого доступа к FB: InterBase Express, FIBPlus,
IBObjects, ... действительно разработаны с использованием Delphi
и их основное преимущество - возможность полностью управлять транзакциями.
Впрочем /если не ошибаюсь/ TSQL также позволяет полностью управлять транзакциями.

PS: Firebird гвоздями не прибит к Delphi.

ODBC является родным интерфейсом Microsoft, и я не сомневаюсь, что MS SQL оптимизирован для ODBC. Чего не скажешь про остальные базы, и Firebird в частности.
InterBase Express, FIBPlus, IBObjects позволяют получать доступ непосредственно к функциям и структурам данных клиентской библиотеки (gds или fbclient), что дает возможность минимизировать издержки и управлять кучей деталей реализации, как то, например, план и статистика выполнения запроса, тип/подтип/кодировка поля, ну и всё управление изоляцией и транзакциями. Через ODBC тоже сделали полноценную поддержку транзакций при помощи SQLExecDirect(«SET TRANSACTION LOCAL...»), но это уже вторичный интерфейс, в котором нужно разбирать содержимое текста, создавать промежуточные объекты, и всё это вместо простых вызовов isc_start_multiple-isc_commit_transaction:
https://firebirdsql.org/file/documentation/reference_manuals/driver_manuals/o...
По этой причине тот жеFIBPlus, хоть и не поддерживается уже не знаю сколько лет, стабильно уделывает UniDAC и IBDAC, в которых реализован опосредованный доступ:
https://forums.devart.com/viewtopic.php?t=30590
https://forums.devart.com/viewtopic.php?t=23932
T-SQL - это язык для хранимых процедур, и Firebird его поддерживает, хоть и с отличиями. К транзакциям он не имеет отношения.

Firebird гвоздями не прибит к Delphi.

Не прибит. Но больше он никому не нужен. Вот, посмотри на список серьезных потребителей Firebird, и удивись словами Russia и Delphi в описаниях:
https://firebirdsql.org/file/documentation/papers_presentations/html/who-uses...

Владимир

InterBase Express, FIBPlus, IBObjects позволяют получать доступ непосредственно к функциям и структурам данных клиентской библиотеки (gds или fbclient), что дает возможность минимизировать издержки и управлять кучей деталей реализации, как то, например, план и статистика выполнения запроса, тип/подтип/кодировка поля, ну и всё управление изоляцией и транзакциями.

Все эти вопросы и более решаемы с использованием T-SQL /то бишь в хранимых процедурах/.
Можно ли их решать на стороне клиента без использования Delphi не знаю /такого рода необходимость у меня не возникала/.
Было желание поучаствовать в развитии Firebird, но к счастью sql.ru отбил у меня эти глупые мысли напрочь.

Но там стиль обсуждения такой, что ЛОР против них - «малое, милое дитя».

Что с ним случилось? Надцать лет тому как всё было весьма терпимо и пристойно, и даже с троллями возились какое-то время...

Владимир

Ни кто из корпораций не заинтересован создать эффективные RAPID системы, языки программирования, ...

Все как в анекдоте.
Адвокат отец поручил сыну /новоиспеченному адвокату/ на радостях самое лучшее дело.
Сын постарался и через неделю «обрадовал» отца в том, что дело закрыто.
Отец ему говорит - «Это дело кормило нашу семью 20 лет, а ты за неделю все разрушил».

Владимир

В этом мире изобилуют разные цвета /черный, серый, ..., белый, .../.
Наверное сгустил краски об под форуме Firebird на sql.ru, но на нем
любому быстро растолкуют кто он есть и где его место.
Там community с своим понятием, что такое хорошо и что такое плохо.
В этих понятиях /например/ нахамить тому кто не придерживается их точки зрения /вариации на тему/ - НОРМАЛЬНО .

PS: «Не ходите дети в Африку гулять» /и правильно/.

Владимир

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

Бизнес - «не мое».
Почему?
Потому что человек становясь «успешным» бизнесменом незаметно теряет бесценный дар - ДУШУ.

Бизнес - «не мое».
Почему?
Потому что человек становясь «успешным» бизнесменом незаметно теряет бесценный дар - ДУШУ.

Это всё пафосные отговорки нерешительных неудачников. Да, иногда приходится быть мудаком, если хочешь быть успешным бизнисменом, но быть мудаком не трудно, например, когда тот, у кого ты выбиваешь условия сделки, говно каких поискать.

Владимир

Пафос это когда говорит одно, а делает другое /впрочем в пафосе много разных оттенков/.
Вот превосходный пример https://www.youtube.com/watch?v=ZRKJxAqkKmg Чаплин. Огни Большого города. Эпизод #01