dma_caviar, ну не знаю... Как бы, если планируется работа относительно большого количества пользователей - параметры сервера тоже должны быть соответствующими. Хотя насчет DataExpress пока ничего не скажу - интенсивной вставкой/чтением ни разу не тестировал, но мне кажется что тест выдержит даже хилый комп. Из практики: некоторые пользователи умудряются криво выстраивать структуру, которая в свою очередь может вызывать тяжелые запросы. Защиты от дурака нет (но ее в принципе не встречал и в других программах).

Вот к примеру специально для DX сделал мини-сервис на базе самого дешевого VPS.

Параметры:


виртуализация OpenVZ (самая фиговая то бишь).

Текущая нагрузка в состоянии покоя:


Пока еще "провалить" его работу не получалось...

Дмитрий Мухvovka3003конструктор баз для одного или небольшой группы пользователей
vovka3003микропредприятия — до 15 работников включительно
да, именно так... микропредприятия и персональное использование
Мне кажется что мы тут с вами вместе пальцем в небо тычем. Я - от того, что мне просто не на чем проверить реальные показатели, вы - от того, что скучно и надо бы хоть что-то, но сказать...
DataExpress - это если можно так выразиться - "надстройка над Firebird". Те же SQL запросы, но обернутые в интерфейсную оболочку. То есть по сути вы заявляете что Firebird не вытянет больше 15 усеров... Так?

dma_caviar,
авторДело даже не в нагрузке, а в бизнес процессах. Когда в конторе сидит человек 100, то он там сложнее. И возникают потребности, которые в конструкторе не учтены.Не исключено. Даже сказал бы - гарантировано. Проект на стадии развития и практически каждый день новый найденный баг или недоработка, какая-то хотелка или предложение...
авторИли например два оператора открывают одну заявку. Один что-то там правит и сохраняет. Потом второй сохраняет и затирает изменения первого. С этим конечно можно жить, это просто пример того что с 15ю юзерами возникнуть не может.
В DX предусмотрена базовая блокировка записей в сетевом режиме. Если запись пытается открыть другой юзер - он сможет сделать это только в режиме чтения, если за время между получением списка записей и попыткой открыть запись были внесены изменения - программа запрашивает обновление данных. Т.е. затереть чью-то запись можно разве что умышленно...
авторКстати, как у вас сделано когда в сущности есть детализация? Она сохраняется вместе с заголовком после того как все заполнят или после сохранения заголовка каждая строчка детализации сохраняется отдельно? Тоже важный момент.
Если речь о таблице внутри какой-нибудь записи (например - список товаров в счете), то в DX такого вывода 2 вида:
"Таблица" - работа с данными с ней происходит в кэше и сохраняется набор только в месте с родителем.
"Запрос" - таблица вывода данных другой родительской сущности с возможностью отбора и фильтрации по данным текущего родителя. В этом случае таблица работает независимо от родителя как самостоятельная сущность.
иную логику сохранения можно организовать но уже скриптом (или расширением).
авторЕще когда в конторе человек 100, то наверняка возникнет необходимость в интеграции с чем-либо. Например с Астериском или сайтом, откуда заявки поступают. Тут понадобится API. Опять же, раз уж заморачиваться с платформами-конструкторами, то есть смысл чтобы и API управлялся из конструктора. И если вызов API будет интенсивным, то тоже могут всплыть проблемы. Мы например в итоге запилили свой API сервер, с возможностью в конструкторе выносить отдельные функции на разные сервисы и разные физические серверы.Это уже отдельная история и в принципе реализуемая. Встроенный скриптовый движок позволяет работать с OLE, DLL, функциями WinAPI. Также в API имеются встроенные http-клиент и http-сервер. С ними можно извращаться насколько хватит фантазии. Насчет нагрузочной способности - опять же - не скажу. Не было реально больших проектов на которых это можно было бы протестировать.

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

dma_caviarВот скриптовый движок это плохо. Там кодеры наколбасят такого, во что потом ни один другой кодер не захочет вникать (см опыт 1С).В отличие от "чистого кода" других систем и IDE - в DX есть возможность его преобразования в функцию выражений или "Действие".

Как это выглядит можно посмотреть по ссылкам:

http://dataexpress.wiki/programmirovanie_v_dx:razrabotka_rasshirenij
https://forum.mydataexpress.ru/viewtopic.php?f=16&t=832
https://forum.develop-soft.ru/dx_ext

ну а от говнокода, конечно никто не застрахован.

dma_caviarvovka3003в форму добавляете запрос, даете ему источник
Это как в Access? Это тупиковый путь.
По хорошему форма это просто разметка расположения элементов, не более того и запросов или источников по идее у нее никаких быть не должно.
В DX немного хромает терминология. Слово "Запрос" и "Источник" - это все визуально настраиваемая часть.
Я уже устал делать видеоролики... :) Наверное проще качнуть да поюзать прогу...

dma_caviarПо хорошему форма это просто разметка расположения элементов, не более того и запросов или источников по идее у нее никаких быть не должно.
Опять с чем-то сравниваете..?

dma_caviarvovka3003пропущено...

Опять с чем-то сравниваете..?
С https://ru.wikipedia.org/wiki/Model-View-Controller
Ну да... В принципе оно же в DX...

dma_caviarЯ понял, я и говорю как в Access. Монолит формы и логики. Если что-то сложное делать, будет хрень.Я уже плохо помню акцесс, но она у меня ассоциируется со словом "геморрой". Когда же зашёл в DX - первая мысль: "Во! оно!". И не ошибся.
Есть конечно и минусы и обратная сторона медали но где их нет?

dma_caviar,

Ну, значит не оно...