Необходимо принять решение о том, как работать с базой данных (СУБД) GT.M и так как я новичок в этом, то прошу указать ошибки мышления или выбора :)

Есть так называемый (мной) Storage Backend (классная информация кстати: http://highscalability.com/blog/2012/6/5/thesis-concurrent-programming-for-scalable-web-architectures.html).
Storage Backend предназначен для делегирования функций по работе с базой данных. Что то подобное (или точно такое) - M/DB или MiniM.

Немного поработав с GT.M посредством вызовов C++ Call-Ins ( http://tinco.pair.com/bhaskar/gtm/doc/books/pg/UNIX_manual/ch11s05.html) и слегка копируя идею GlobalsDB Java API я начал разработку своего GT.M C++ Wrapper. Это первый вариант работы с базой данных в Storage Backend.
Второй вариант это Client/Server, например M/Wire. Это вариант я как раз собираюсь опробовать в ближайшее время в полной мере. Но необходимо понять какой вариант лучше для моего Storage Backend.

Я могу размещать Storage Backend на одном физическом сервере с базой данных и значит будет работать мой GT.M C++ Wrapper. Конечно я могу сделать (как в GlobalsDB Java API) создание соединений (опять же каких? TCP? и как я буду выполнять Call-Ins для базы данных, с которой соединился?).
Но я могу реализовать второй вариант, больше бизнес-логики реализовав на стороне базы данных (СУБД) в виде M рутин.

Что выбрать и где я ошибаюсь? Вот в чем вопрос...
PS: никак не могу выделить время на чтение книг-текстов по MUMPS...
Модератор: подправил название темы

DirksDRSergeyLee,

По соседству есть два форума "Проектирование БД" и "Разработка информационных систем".
Там на такие посты ответ короткий - ТЗ в студию!
Какие данные, какая обработка, сколько пользователей, какие запросы - не имея представления об этом невозможно что-то рекомендовать.



Вариант 1. Ставите на каждый сервер свой Wrapper, которые взаимодействуют с GT.M через Ваш любимый Call-Ins, а по TCP взаимодействуют с Супер-Wrapper, к которому подключаются пользователи.

Вариант 2. Плюньте на Call-Ins, подключайтесь к серверам GT.M через TCP. Возьмите за основу M/Wire,
посмотрите http://karataev.nm.ru/cache/mdapi.html , здесь есть примеры клиентских программ.
Упор сделайте не на мампсовские SET и KILL, а на XECUTE и DO, т.е. на вызов прикладных программ и функций.

P.S.Так и не пойму, для чего Вам нужен C++ Wrapper.

Спасибо :)
Ну я так и предполагал :) Но интуиция это такое... А почему C++ Wrapper? Да просто это первое, что я сделал ручками и получилось :) Буду теперь смотреть M/Wire 100% уверенным, что иду в правильном направлении...
Такс) А по поводу ТЗ и другого форума... Я тут уже как бы устроился как дома))) а там еще не был)))
Проектирование БД - это проектирование данных) Информационные системы как бы уже продумано все) она не очень и сложная как по архитектуре, мне как раз нужен был механизм работы с базой данных.

DirksDR,

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

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

Valeriu,

А я передавал своим коллегам эту мысль, но они не внимали ей, пока не возникло несколько ситуаций, после которых начальник отдела (он же основной разработчик фронтенда на PHP) начал решительно ломать систему в сторону "пишем всем на М", что тоже несовсем правильно (наверное).
Я хочу писать на М только логику работы с данными, а формирование страниц по крайней мере на первых порах - на PHP, JavaScript.
Можно конечно формировать страницы (HTML+JavaScript) и на М, но на это надо потратить время - спроектировать каркас, возможность формирования страниц по шаблону (шаблонизатор на М) и прочее.

DAiMorНу при большом желании, можно написать нормальный фрейморк на M, и тогда можно например по $text, вытаскивать шаблон, из своей же рутины, и вставлять нужные поля.
а сейчас нормальное приложение должно возвращать в большинстве случаев только например JSON.
а HTML На основе шаблонов генерируется на стороне браузера.

а я об этом и писал
SergeyLeeно на это надо потратить время - спроектировать каркас, возможность формирования страниц по шаблону (шаблонизатор на М) и прочее.

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

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