Но не тут-то было. Сложности, носящие принципиальный характер, никуда не делись - их просто искусно замаскировали, точнее, протоптали и заасфальтировали некоторое количество обходных дорожек и обсадили их красивыми формочками, Help'ами и Wizard'ами. При этом в любой реальной разработке добраться по этим дорожкам до цели почти никогда не удается. Приходится выходить на обочину или вообще на бездорожье, и тут-то и выясняется истинная цена всей этой красоты.

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

В первой части мы рассмотрели историю развития современных средств быстрой разработки клиент-серверных приложений СУБД как продуктов масс-культуры, а также распространенные иллюзии, которые их поставщики старательно сеют в головы пользователей. В этой части мы рассмотрим некоторые типичные проблемы, с которыми приходится сталкиваться практически всем разработчикам реальных систем.

И вторая часть:
http://offline.computerra.ru/1999/303/3781/

На самом деле есть еще такая вещь, как View, - это тот же запрос, но подготовленный средствами SQL-сервера. Из клиентских программ с ним можно работать почти как с таблицей, но редактировать, естественно, нельзя...

К пониманию необходимости динамического порождения SQL-запросов рано или поздно приходят все разработчики, кроме разработчиков базового инструментария. Видимо, им самим не приходится пользоваться своими творениями.

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

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

Длинные отчеты, не меняющие данные, но привязанные к определенному моменту времени, также нужно защищать. Если мы хотим получить состояние склада на 14:00, а соответствующий отчет генерируется полчаса, то за это время в систему введут еще десяток проводок, и мы получим отчет, не соответствующий никакому моменту времени.

Если позволите, краткое резюме.