Sergey GladilinХочется узнать, а что из этого и в каких случаях реально применяется в сколько-нибудь масштабных приложениях?

следует, что даже приделывание простого индекса к базе требует весьма существенной переработки MUMPS-программы.
В случаях когда предполагается что приложение будет меняться это обстоятельство учитывают и пишут себе небольшой нижний уровень. Большинство индексных структур допускают их использование в различных задачах. Поэтому сначала разработчик подумает, использовать ли специализированные индексы применимые в малом числе задач но работающие быстрее или более общие структуры и несколько функций-операций над индексами но работающие чуть медленнее. Потом проведет макетирование подходит ли выбранный метод под предъявленные требования по времени работы. Чем больше система тем обычно по структуре она ближе к таблицам похожим на sql таблицы. В SQL есть чисто языковые ограничения, например нельзя строить индекс не привязанный ни к одной таблице но по нескольким таблицам и вместо длинных join просто брать данные из индекса. Поэтому обычно ни SQL ни объекты в полной мере разработчиков не удовлетворяют.

SQL и объектный доступ в каше реализованы на mumps. Это вроде описанных выше библиотек. Если в объектном доступе пишут в объектном синтаксисе, то в sql доступе пишут (так называемые) запросы, которые транслируются в те же вызовы нижнего уровня на mumps. В принципе, никто не мешает программисту написать свои библиотеки в своем видении проблемы. В том числе с ведением так называемых метаданных и автоматической корректировкой выполнения. Хоть QBE. Можно также написать свои классы которые будут реализовать свои стратегии хранения.

Однозначного ответа на вопрос "как делают" наверно не смогу дать - в разных системах разработчики могут выбрать разные методы. Иногда проще потратить месяц-другой на свой нижний уровень чем два-три года морочить голову как реализовать эффективно на штатных средствах. Иногда более чем достаточно штатных средств.

Sergey Gladilinналожение индексов на view - это не то, что надо?
Это специфика имплементации.

Sergey GladilinДалее, насколько я понял основную суть ответа, - Вас не удовлетворяет подход к организации базы данных, заключающийся в использовании непроцедурного языка запросов - вместо этого Вы предпочитаете использовать процедурный язык, позволяющйи на низком уровне высокоэффективно копаться в отдельных данных, находящихся в базе?
Не совсем так. Меня удовлетворяет любой подход решающий задачу в том числе с учетом дальнейших перспектив изменений. А будет результат процедурным или нет - это вторично.

Sergey GladilinТогда сразу вопрос - как соотносится процедурный язык с реализацией "клиент-сервер"? MUMPS-программа, реализующая интерфейс с пользователем, работает на машине клиента. Она сама лазает внутрь файла на сервере, в котором физически лежит база данных, или для этого есть серверная часть приложения?
- Если есть серверная часть, то какой используется протокол обмена?
- Если идет обращение к файлу, то какой же объем данных передается по сети при сколько-нибудь сложном поиске в базе?
Нет. То что написано на mumps - это на стороне сервера. Программа не лазает внутрь файла, это делает интерпретатор, когда выполняет обращение к глобалам (то что начинается на ^). База также не обязана лежать на том же сервере где исполняется серверный процесс, данные могут быть там же, на другом сервере или часть там часть здесь (детали зависят от имплементации). Протокол обмена зависит от коннекта и вида клиентского приложения. Можно телнетом, можно вебом, можно частный поверх tcp/ip. Телнет очевидно не будет работать по http, а вебсервис по телнету, логично? Сколько передается по сети - опять же смотря что за приложение. Непример при работе по телнет по сети передаются байты соответствующие нажатию кнопок, а обратно от сервера - эскейп команды. Если это дельфи - клиент, то туда параметры запроса, оттуда - строки в грид например.

Sergey Gladilin Это специфика имплементации
Поясните, пожалуйста, что имеется в виду. Решает ли наложение индексов на view проблему построения индекса, который "не привязанный ни к одной таблице но по нескольким таблицам и вместо длинных join просто брать данные из индекса" ?
Думаю, что да, решает. Если СУБД это поддерживает и оптимизатор грамотно использует, то это большой плюс этой СУБД.

Sergey Gladilin Не совсем так. Меня удовлетворяет любой подход решающий задачу в том числе с учетом дальнейших перспектив изменений. А будет результат процедурным или нет - это вторично.
Расскажите, пожалуйста, чем, кроме как процедурностью (в смысле возможности и необходимости самому выбирать от какого к какому узлу базы перейти и как таким образом организовать в базе поиск) M-системы отличаются от SQL-систем.
Пробую понять. В процедурном языке не рассматриваем процедурность, что в нем останется? Ну разве что общие вещи для СУБД - транзакции, ввод-вывод, управление процессами и прочие атрибуты.

Sergey Gladilin База также не обязана лежать на том же сервере где исполняется серверный процесс, данные могут быть там же, на другом сервере или часть там часть здесь (детали зависят от имплементации)
Т.е. внутри M-системы таки есть свой фиксированный протокол запросов между MUMPS-интерпретатором и собственно сервером? Можно ли его использовать, если клиент написан на MUMPS?
Клиент на mumps - это или про msm-ws или я не знаю про что, нужно смотреть документацию на него. Между серверами поддерживается свой протокол распределенного кеширования. Какой - зависит от имплементации. Например в каше поддерживается DCP и ECP, в msm - DDP.

Sergey GladilinВопрос и к "ну я" и к MC--ALEX - запросы и ответы, передаваемые по сети, в Вашей системе насколько сложны? Действительно ли разработка своего языка/протокола запросов и ответов имеет преимущества перед использованием стандартного языка вопросов и ответов SQL?
Вот примерные коды из моей текущей задачи:
CacheConnect.Execute( \'d ClearData^UTZ07(resglob,3,\' + month + \')\');
На сервер уходит байт 50, обратно - байт 20 подтверждение. Функция выполняет пересчет данных отчета.
CacheConnect.Execute( \'d GetData^UTZ07(resglob)\');
На сервер тоже около 50 байт, обратно - примерно от 20 байт до нескольких мегабайт. Сколько придет - зависит от данных, в каком формате - решаю я сам. В качестве ответа приходит кросстаблица.

Sergey GladilinСразу хотел бы также задать вопрос про производительность. Вот здесь:

/topic/54920&pg=3#396080

"ну я" предлагает задачу, демонстрирующую случай, когда M-системы имеют значительное преимущество в производительности перед SQL. В ответах в той ветке я так и не нашел объяснений, почему это происходит. Можете ли Вы рассказать, каким образом в данной задаче можно организовать хранение данных в MUMPS и каким образом организуется поиск в этой структуре данных для обеспечения указанной производительности?
Пока не могу, это составляет внутренние секреты некоторых компаний.

Sergey GladilinСразу хотел бы также задать вопрос про производительность. Вот здесь:

/topic/54920&pg=3#396080

"ну я" предлагает задачу, демонстрирующую случай, когда M-системы имеют значительное преимущество в производительности перед SQL. В ответах в той ветке я так и не нашел объяснений, почему это происходит. Можете ли Вы рассказать, каким образом в данной задаче можно организовать хранение данных в MUMPS и каким образом организуется поиск в этой структуре данных для обеспечения указанной производительности?
Могу лишь сказать что mumps - это обычно не самоцель для адептов, а многофункциональный инструмент. Попробуйте решить эту задачу как таковую, а потом решение перепишите на mumps и sql.

Sergey GladilinЕсли я правильно понял, то Вас привлекает именно процедурность (в описанном выше смысле) MUMPS'а, т.к. как Вы считаете ограничения, появляющиеся из-за непроцедурности, слишком серьезными?
Это зависит от задачи. Для некоторых задач SQL хватает за глаза, зачастую даже голову ломать не нужно.