Ого. Извините, что не появлялся (выходные однако) :)

sigmovА в чем печаль то?
Не совсем понятно желание уйти от проверенной связки MySql+PHP+JS в велосипедные GT.M+(?) или Cache'+CSP(?)...


Мы пишем не просто сайт и MySQL не подходит для нашей задачи. Как и любая реляционная база данных. Изучив весь спектр NoSQL я выбрал GT.M как бесплатное решение для нашей задачи, соответствующее всем требованиям (надежность данных, масштабируемость, доступность, кроме того применение его в финансовой сфере сыграло огромную роль). Cache отбросил изза платности.
И да, нам нужны велосипедные GT.M. И да, GT.M используется в-основном как хранилище данных. И немного М рутин.

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


Свою СУБД создавать не собираемся. Это безумство. Пока достаточно терминала как системы управления.
Cache я вообще не рассматриваю. Я пока за разделение задачи на модули и в основном пишу на С++, поскольку знаю его лучше М. Сокеты, процессы, SSL, криптография и прочее. Хотя, конечно, можно написать подобное и на М, наверное :) Но я пока не рискну. М рутины выполняют задачи по работе с данными.

И хватит ссориться :) Давайте по сущности :) Мне нужен примеры! Не с Cache, а с GT.M.
Жаль не могу говорить суть нашей задачи. Но MySQL используется лишь потому что решение задачи (грубо говоря фронтенд и бекенд) ведется параллельно, а не последовательно. Фронтенд разрабатывался на связке MySQL+PHP. Для работы с GT.M разработали PHP Extension, который через шлюз отправляет запросы и получает ответы от бекенда, а бекенд обрабатывает эти запросы, выполняет М рутины, отправляет ответы.

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

Нет. Любые примеры. Постараюсь по другому подойти к вопросу.
Есть работающая система (пусть web-приложение), использующее широко известный язык запросов SQL (увы, этому в основном учат в ВУЗах, и их в основном использовали последние годы), и некую СУБД на SQL. Вся логика построена на INSERT/UPDATE/SELECT.
Теперь же нужно "перевести рельсы" с SQL на MUMPS. При этом, конечно же не переписывать весь код работающей системы, а подменить вызовы INSERT/UPDATE/SELECT на операторы MUMPS.
Но при переводе рельсов, приходиться использовать структуру реляционной БД, таблицы стали глобалами, и так далее. Раньше SQL БД (MySQL) находилась на том же хосте, что и PHP-приложение, теперь же архитектура такова, что БД (GT.M) и PHP-приложение разнесены по разным хостам (для безопасности). Теперь фронтенд (PHP-приложение, любое приложение) работает с бекендом (и БД GT.M) посредством запросов/ответов через TCP соединение. И для УНИВЕРСАЛЬНОСТИ этих запросов/ответов (API), мы используем структуру БД (таблицы, поля, параметры таблиц и полей) для проверки приходящих запросов.
Вот тут и появились сомнения, что в целом мы неправильно используем идеи MUMPS, тем что ввели структуру БД. Но так как приложение написанное на PHP, уже необходимо вводить в продакшн в течении месяца, и конечно же все как всегда боссы давят на скорость разработки, то мы пока не можем продумать правильную архитектуру PHP-приложения работающего с GT.M базой данных БЕЗ структуры данных, и наш PHP-шник незнаком с MUMPS/GT.M в полной мере, и всю логику строит полагаясь на MySQL.
Скорее нам нужно понимание построения модели данных для MUMPS/GT.M, чтобы постепенно отказаться от SQL-ориентированной структуры БД.
Фух. Наверное все путано. Извиняюсь. Может вскоре посижу и нарисую диаграмму того что есть и того что хочется.

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

И что это за X.Magic? Ссылка есть на него?

misha_shar,

А что именно использовали из MUMPS, GT.M? И наверное писали работу с сокетами на М?

krvsaРаз уш пошел разговор про GT.M. - какие внешние интерфейсы он поддерживает? Терминальные подключения? Вебовские с какой-то связкой или своя разработка (как CSP)?

Есть внутреннее что-то вроде GT.CM Client/Server, но я не понял зачем и как использовать это.
Есть разработка от M/Gateway - MWire, TCP протокол. Это я использовал. Но все это медленно.
Есть внутренняя возможность Call-Ins, которую я собственно и использовал для работы с GT.M на C++. Есть также реализации поддержки других языков - Java, Erlang, Node.js.

Также есть от той же M/Gateway реализации m_php, m_python и некоторые другие. Но это подходит для непосредственного использования команд GT.M в PHP, Python. Плюс есть EWD (Enterprise Web Developer (EWD) is our advanced web application delvelopment technology and Ajax framework.). Но я это не изучал. Некогда :)

Есть еще странно-загадочный PIP... Но там так и написано - только профи и только на свой страх и риск... Я пока не профи...

misha_shar,

мы уже сделали и TCP соединение между клиентской частью и серверной частью. и сделали-проработали протокол запросов-ответов. это все на C++. на стороне GT.M - вызовы М-рутин для работы с данными. сделали в итоге три типа запроса подобных SQL INSERT (add), UPDATE (edit), SELECT (find)... запросы-ответы в формате JSON. это как раз на этой недели и тестируем. отдельные запросы работают хорошо :) осталось протестить весь сайт, напичканный этими запросами :) хорошо то, что в PHP были отделены классы работы с моделями данных от контролеров и представлений (паттерн MVC).

misha_sharАбсолютно правильное поведение. Так какие еще проблемы?
Не проблемы, а сомнения :)
1. GT.M (Cache) по сути shemeless (безсхемные тобишь), а мы для правильности передачи полей в запросах для верности ввели проверку их согласно структуре данных. Тоесть если в таблице users есть поле user_name, а в запросе кто-то неправильно напишет имя поля - user_mame (например). В Cache кажется есть что то типа словаря? Я сделал глобал в котором сохранил структуру данных: таблица-поля, и в М рутинах провожу проверку полей.
2. Второе сомнение родилось в спорах, что круче (быстрее, правильнее, удобнее) - вызывать в С++ коде отдельные операторы М или сразу рутину М? При этом основа спора была такова - в М-рутину передаются параметры в виде строки с разделителем, затем строка парсится и параметры дальше участвуют в М рутине, и М рутина возвращает результат в таком же формате - строка с разделителями. На формирование/парсинг параметров и формирование/парсинг результата уходит много времени. И поэтому вместо вызова М рутины делать вызовы отдельных операторов в С++ коде, при этом параметры и результаты не нужно формировать/парсить (из/в JSON).

Блок А.Н.SergeyLee,
Я все равно не понял, почему вы мечетесь? У вас есть работающее или почти работающее приложение на php+mysql,
Почему вы хотите все поломать? Тем более, я так понял, у вас не хватает времени.
Почему вы так против sql? В подавляющем большинстве случаев это отличный язык манипуляции данными.

Не мечемся. Может не правильно выразился. Или неправильно поняли. Решение изначально было продумано для работы с GT.M. Но в силу того, что я с GT.M не был еще знаком, решили сделать макет приложения, используя php+mysql, чтобы показывать заказчику внешний вид. Поэтому мы не ломаем, а заменяем.
Кроме того макет работал на одном хосте. А решение будет работать на двух хостах. И вообще то облачные хосты. И это не моя часть работы.
Я не против SQL. Я в основном программист C++, с базами данных работал давно, конечно же SQL. Последнее время использовал SQLite для нужд standalone C++ приложений. Наш специалист по базам данных сказал, что MySQL плох в плане масштабируемости и надо искать решение в мире NoSQL. Я нашел GT.M, заодно и Cache. Что то не так? GT.M поддерживает репликацию, которая нам необходима.