SergeyLeeЗадались мы командой вопросом "Как делали и делают правильные системы и приложения на основне MUMPS баз данных?". "Баз данных" я взял в кавычку, потому что не знаю как правильно назвать все это...
Первое, что Вы должны решить: собираетесь ли Вы использовать СУБД или хотите создавать приложения БД без использования СУБД? Во втором случае не вполне ясно на чем основаны Ваши предположения о востребованности того, что Вы хотите создать.
В первом случае, учитывая, что MUMPS - это, в первую очередь, среда для создания СУБД, Вам нужно сначала изучить теорию БД.
Понять основные принципы БД 13254920 .
Понять смысл MUMPS, как интегрированного языка БД 13632149 и понять зачем Вам С++.
Понять какую МД Вы будете использовать в создаваемой СУБД 13577413 .
Cache - это система, которая уже близка к СУБД. Пока, это не СУБД, конечно, но она намного ближе к СУБД, чем реляционные системы хранения и обработки данных (РСХОД), такие, как уже упомянутая здесь MySQL, например.
Свою СУБД разумно создавать так, чтобы она работала и в среде GT.M, и в базовой среде (условно, COS) Cache.

MX-9Бредятинапропущено...

...
Свою СУБД разумно создавать так, чтобы она работала и в среде GT.M, и в базовой среде (условно, COS) Cache.

Свою СУБД вообще НЕРАЗУМНО создавать

".. все уже украдено до нас "
Я же ясно указал на вариант создания приложений БД без использования СУБД, которым Вы, вероятно, и воспользовались, создав какую-нибудь конкретную прикладную систему на MUMPS без использования СУБД))

Проблемы высшего образования (в частности, его ориентация на популярные, но не лучшие, технологии) здесь много раз обсуждались. Зачем их опять обсуждать в форуме по Cache???
Обсудите их, пожалуйста, если это так необходимо в форуме по MySQL)))

sigmov... а в Cache' с говнокодом написаны базовые классы - хошь не хошь но использовать придется.
Момент истины, так сказать, в бессмысленном споре не по теме))
Зачем использовать плохой код???
Вот на этот простой вопрос ответить, действительно, невозможно))

sigmovБредятинапропущено...
Момент истины, так сказать, в бессмысленном споре не по теме))
Зачем использовать плохой код???
Вот на этот простой вопрос ответить, действительно, невозможно))Верно. И мой посыл автору о том же - что не стоит уходить с MySql + PHP в быдлячие Cache'+CSP
Модератор: Подбирайте выражения. Первое, оно же последнее предупреждение перед баном.
Ваша проблема в том, что Вы не освоили, пока, технологию БД
13970413
Поэтому нервничаете, уходите от темы (речь шла про MUMPS) и допускаете нелепые высказывания))
СУБД на MUMPS + PHP работает во всех отношениях лучше, чем РСХОД MySQL + PHP.
Но Вы считаете, что это не главное, а главное, что ядро MUMPS (COS) содержит некий плохой код, а ядро MySQL , соответственно, хороший)). Вероятно, вы глубоко разобрались в этом коде, и он Вам очень близок. Так и используйте эту плохую технологию с хороших кодом. В разделе "Сравнение СУБД" откройте тему сравнения кодов ядер, и обсуждайте там свои, безусловно интересные, вопросы.

sigmovНу собственно поэтому я и предлагаю дождаться ответа автора о причинах "плачевности".... А потом уже продолжить спор.
Спор о кодах (сравнение кодов) ведите в другой теме, пожалуйста.
sigmovОткуда же сие сведения?
Это факт, а не сведения. При использовании СУБД приложение БД проектируется, а не программируется. А при использовании СХОД программируется. Каждый раз, одно и тоже. Или применяется архитектура "модель верхнего уровня+маппинг+РМД", причем с маппингом по всем трем аспектам.
sigmovВот уж не знал что ядро MUMPS = COS.... Всегда полагал что разработка InterSystems это лишь надстройка над MUMPS.
Вы много чего не знаете, что проявилось уже, и является очевидным)) Поэтому, вероятно, и додумываете что-то по своему. Например, применили знак равенства хотя суть заключается лишь в том, что IS не использует аббревиатуру MUMPS. Поэтому я написал в скобках, а Вы приписали знак равенства. Пожалуйста, откройте тему в разделе "Сравнение СУБД", если хотите что-то сравнивать. Это же очевидно, что так нужно сделать, если хотите сравнивать))

SergeyLeeМы пишем не просто сайт и MySQL не подходит для нашей задачи. Как и любая реляционная база данных.
Это не так. Советую прислушаться к тому, что пишет SergeyLee:
"Но MySQL используется лишь потому что решение задачи (грубо говоря фронтенд и бекенд) ведется параллельно, а не последовательно. Фронтенд разрабатывался на связке MySQL+PHP."
SergeyLeeИзучив весь спектр NoSQL я выбрал GT.M как бесплатное решение для нашей задачи, соответствующее всем требованиям (надежность данных, масштабируемость, доступность, кроме того применение его в финансовой сфере сыграло огромную роль). Cache отбросил из-за платности.
Можно понять так, что Вы выбрали MUMPS, как технологию. Замечу, что никакую конкретную МД MUMPS не поддерживает. Вероятно, Вы предполагаете работать с БД без использования СУБД.
SergeyLeeИ да, нам нужны велосипедные GT.M. И да, GT.M используется в-основном как хранилище данных. И немного М рутин.
Теперь очевидно, что СУБД Вам не нужна. И Вы решаете некую частную, секретную задачу. И будете использовать частную БД на глобалах MUMPS c прямым доступом. То есть, нет МД, и соответственно нет ни структуры, ни ОЦ, ни ЯМД.
SergeyLeeСвою СУБД создавать не собираемся. Это безумство. Пока достаточно терминала как системы управления.
Безумство, скорее, Ваш подход - создание приложения БД без СУБД. Но для частной, секретной задачи - вполне нормально.
SergeyLeeCache я вообще не рассматриваю. Я пока за разделение задачи на модули и в основном пишу на С++, поскольку знаю его лучше М. Сокеты, процессы, SSL, криптография и прочее. Хотя, конечно, можно написать подобное и на М, наверное :) Но я пока не рискну. М рутины выполняют задачи по работе с данными.
Чем больше ЯП, тем хуже архитектура))

Alexey MaslovSergeyLee,
боюсь, не дождётесь вы здесь примеров, т.к. GT.M-щиков тут почти нет. Возможно, здесь что подскажут. Иногда заглядываю на этот форум, но кроме упоминаний бесплатной мед.системы VistA, других тиражируемых M-продуктов (кроме продуктов самой FIS) что-то не припомню.
Непонятно, каких примеров. Например, вот какой путь проделало крупное приложение на X.Magic: MSM (DOS)->Cache(Unix)->GT.M(Linux). Но, автору темы нужны, вероятно, примеры web-приложений на GT.M.

SergeyLee... Постараюсь по другому подойти к вопросу.
Есть работающая система (пусть web-приложение), использующее широко известный язык запросов SQL (увы, этому в основном учат в ВУЗах, и их в основном использовали последние годы), и некую СУБД на SQL. Вся логика построена на INSERT/UPDATE/SELECT.
Теперь же нужно "перевести рельсы" с SQL на MUMPS.
SQL это ЯМД, ориентированный на конкретную МД, на котором, впрочем, нельзя написать приложение БД. MUMPS ни на какую МД не ориентирован.
SergeyLeeПри этом, конечно же не переписывать весь код работающей системы, а подменить вызовы INSERT/UPDATE/SELECT на операторы MUMPS.
А чтение (поиск, индексы)?
И потом, нужно стремиться к тому, что никакого кода не было у "работающей системы".
SergeyLeeНо при переводе рельсов, приходиться использовать структуру реляционной БД, таблицы стали глобалами, и так далее.
Еще раз повторю, что отношение (таблица) это элемент структуры РМД, а глобал - это не элемент структуры какой-либо МД. Таблицы не могут сами по себе стать глобалами. Не игнорируйте этапы, о которых я Вам написал.
SergeyLeeРаньше SQL БД (MySQL) находилась на том же хосте, что и PHP-приложение, теперь же архитектура такова, что БД (GT.M) и PHP-приложение разнесены по разным хостам (для безопасности). Теперь фронтенд (PHP-приложение, любое приложение) работает с бекендом (и БД GT.M) посредством запросов/ответов через TCP соединение. И для УНИВЕРСАЛЬНОСТИ этих запросов/ответов (API), мы используем структуру БД (таблицы, поля, параметры таблиц и полей) для проверки приходящих запросов.
Вы используете РСХОД для хранения "словаря данных" (базы метаданных)? Вы вынуждены это делать, раз не используете СУБД на стороне MUMPS. Но из этого следует,что Вы используете либо РМД, либо EAV.
SergeyLeeВот тут и появились сомнения, что в целом мы неправильно используем идеи MUMPS, тем что ввели структуру БД.
Не то слово. Назовите основную причину, по которой Вы не используете РСХОД.
SergeyLeeНо так как приложение написанное на PHP, уже необходимо вводить в продакшн в течении месяца, и конечно же все как всегда боссы давят на скорость разработки, то мы пока не можем продумать правильную архитектуру PHP-приложения работающего с GT.M базой данных БЕЗ структуры данных, и наш PHP-шник незнаком с MUMPS/GT.M в полной мере, и всю логику строит полагаясь на MySQL.
MGWSI (The M/Gateway Services Integrator) – интеграционный сервис, обеспечивающий взаимодействие GT.M с PHP http://gradvs1.mgateway.com/main/.
SergeyLeeСкорее нам нужно понимание построения модели данных для MUMPS/GT.M, чтобы постепенно отказаться от SQL-ориентированной структуры БД.
Соответствующие ссылки я Вам дал.

SergeyLeeИ что это за X.Magic? Ссылка есть на него?
Вам это не нужно. Она ориентирована на корпоративные системы для сотен или тысяч пользователей, а не на web.

SergeyLeeЧтение данных это запрос find, аналог SELECT, в котором я указываю какие поля получить, какие фильтры поиска применить и затем еще добавлю сортировку.
Немного уточню. Какие из каких таблиц какие поля получить... В котором я учитываю FK/PK, используемые для связывания таблиц...
Это вряд ли получится. Но идея понятна.
SergeyLeeЧто такое РСХОД?
Вы все игнорируете)) Ваше дело. Реляционная система хранения и обработки данных. Например, MySQL.
SergeyLeeВы работали с MGWSI? Я - нет. Коллега - да, и у него не получилось. У меня может и получится, но это все равно не то что нам надо.
Тогда зачем Вы написали первые три предложения и половину четвертого в этом абзаце???
SergeyLeeУ меня не таблицы становятся глобалами, правда я не знаю, что вы имеете здесь в виду, а глобал организован как колоночная структура данных: ^Database(table,id,field)=value, где table - имя таблицы, id - первичный ключ этой таблицы, field - поле и value - значение поля.
Понятно. Однако, (простой) ключ в записеориентированной РМД - это одно из полей, а идентификатор в объектно-ориентированной МД, элементы которой Вы используете, - это не одно из полей - как видите он находится вне остальных полей. А FK, судя по всему, Вы будете располагать среди полей, все-таки. Это плохой не симметричный подход. Но сойдет, конечно.
Желаю творческих успехов в очень нелегком деле, которое Вы затеяли))