S.PRПодход поддерживаю! У меня аналогичный.
Штук 20 задач крутится для 50 юзеров.
Delphi 7 + dbExpress + FireBird 1.5
У меня другой подход - использую нормальные средства и при этом тоже нет проблем с установкой. Так одну из программ для 6000 пользователей тоже не нужно устанавливать - достаточно скопировать содержимое каталога и запустить. После этого работает автообновление и т.п., копируются все нужные библиотеки для работы с БД. Такой подход мне нравится больше.
C# + Web Services + ADO.Net + MS SQL2k

S.PRА какой у вас критерий нормальности средств?
Критерий нормальности - это использование как можно более производительных с точки зрения скорости разработки инструментов.
Подчеркиваю - именно с точки зрения скорости разработки, а не скорости работы. Инструменты естественно должны удовлетворять и требованиям по производительности, надежности, прочим требованиям ТЗ. Как правило требования к производительности невысокие, и выбор инструментов очень широкий. Например возьмем случай 50 пользователей. Это небольшое количество пользователей. При более-менее неплохой архитектуре БД, пользователи базу сильно загрузить не смогут для большинства типов приложений. Поэтому использовать тут всевозможные компонеты прямого доступа и т.п. оптимизации - считаю это лишним. Хотя плохой архитектурой БД запросто можно добиться того что все будет основательно тормозить. Но если это случится, то причина почти наверняка - плохая архитектура или только БД, или в целом всего приложения. Компоненты прямого доступа и прочие оптимизации могут улучшить ситуацию, но ненамного. Причина в таких случаях не в лишних интерфесных вызовах, а в архитектуре.
Иногда, и я встречался с такими проектами, действительно важна каждая миллисекунда. В этих случаях в ТЗ расписываются требования к времени вызова каждого метода, и т.п. Тогда действительно нужно думать о всевозможных оптимизациях. Но такие проекты встречаются очень нечасто.

S.PRТребования по производительности высокие ВСЕГДА,
в БД это один из важнейших показателей.
Не верю. Чаще только кажется что требования высокие, при внимательном изучении оказывается что требования по производительности на самом деле невысокие. И для обеспечения требуемой производительности не нужно заниматься всякими оптимизациями и т.п., нужно лишь как можно быстрее сделать работающую систему.

S.PRЭто чтобы быстрее деньги получить
и когда другие дяди будут систему поддерживать.
Заказчику нужна в первую очередь система решающая его бизнес-проблемы.
То что она будет работать на несколько процентов медленнее или наоборот быстрее, при условии что производительность находится в рамках ТЗ, заказчика не волнует.
Как между собой связана ориентация на скорость разработки (при полном выполнении ТЗ) и поддержка системы не вижу.

S.PRНа первых порах да.
Но если бизнес развивается то увеличиваются и бизнес-проблемы
и объемы данных и количество пользователей.
Становится все более актуальной проблема производительности.
А если изначально не было ставки на производительность, то при поддержке системы оптимизация перерастает в главную проблему,
которая может эту систему вообще завалить.
Конечно все зависит от конкретной задачи задачи.
Я например имею ввиду информационную систему масштаба предприятия.
Странно, я тоже говорю о системах масштаба предприятия. Я проектировал и делал такие системы, с многими сотнями пользователей, и особых проблем с производительностью не заметил. Не требовалось бороться за скорость каждого кусочка кода и т.п. При этом пользователи довольны.

Сейчас например я в проекте где скорость имеет очень большое значение. В ТЗ прописаны ожидаемые средние времена транзакций, прописана планируемая нагрузка - 10 000 пользователей и 1000 транзакций в секунду в пиковые моменты. СУБД - MS SQL2k. С учетом того что железо для такой задачи будет относительно слабым, здесь нужно думать о скорости. Но для большинства задач с которыми обычно сталкиваются разработчики, думать о процентах скорости не нужно - достаточно построить грамотную архитектуру системы и БД.

Alexey Sh2 Мимопроходящий : в качестве пользователя может выступать не только дворник, а датчик. например
В той задаче о которой я написал - пользователи это именно физические лица, а не датчики. Да, бывают и такие задачи.