А это смотря чё тебе надо. Обычно пляшут от того что умеют.Умеют ковыряться в Access - пишут все в нем. Получается в 99% паршиво, но все-же иногда работает. Умеют на Дельфях компоненты таскать - делают толстого клиента.

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

kot275А одному реально осилить написание тонких клиентов и двух-трехзвенных решений?Ээээ... в принципе реально...
В 80ые была телепередача, ... не помню как называлась, там показывали людей которые делали самодельные автомобили, амфибии, даже вертолеты были. Вот взял человек и сделал себе машину сам. И ездит на ней. Все смотрели и восхищались.
Намек понятен? :)

kot275 Я много читаю это форум. Ту получается одни пишут сервера приложений, другие тонких клиентов. Или один пишет первое звено, второй второе, третий третье.Командой это действительно делать проще и быстрее. Естественно если лидер в группе есть опытный.

kot275 Мой основной сервер FireBerd, там есть возможность написание хранимых процедур. Но не все на них можно реализовать. Возможно, это функционал у него слаб. Может, порекомендуете что-то на эту тему? Может другой сервер БД?ээээ..... я не большой спец по этому серверу. Последний раз с ним работал еще 90-х, да и видел его в живую в те-же времена. Так что я все же посоветую сменить на что-либо более распространенное, на что будет проще найти спецов, когда будешь набирать свою команду. А что именно - смотри по рынку труда. FB это все-же детище Борландов и если в округе сплошняком дельфисты, то FB можно будет и оставить.

ChopWhite OwlСамый надежный - всю бизнес-логику делают на хранимых процедурах.очень спорное утверждение,
есть задачи, которые относятся к бизнес-логике, например печать документов, которые в хранимки не засунешь,
а размазывать бизнес-логику по разным слоям...С чего это вдруг печать документов стала частью бизнес-логики? Это часть бизнес-процесса, да. Но не логики.
Каким шрифтом будет распечатана накладная никак не влияет на то как эта накладная будет обсчитываться. Достаточно вспомнить о том, что одна и та-же накладная может быть нужна в нескольких видах: как список товара для кладовщика (которому нафиг не нужна цена товара, но важен его вес и габариты), либо как список товара для бухгалтера, и там уже цена все а вес ничто. Но в любом случае этот товар должен быть учтен - и вот это уже задача для ХП.

Вывод документов это как раз уже задача клиента. Либо тонкого, когда всё (включая расположение объектов и шрифты) читается с сервера - например web-клиент и html-able СУБД типа SQL Anywhere. ХП определяют что и как рисовать, а браузер уже занимается раскраской пикселов.
Либо на средне-тонком клиенте, который держит определения графического представления бизнес-объектов у себя. Примеров приводить не буду - ты сам их знаешь раз уж поднял этот вопрос.
Но в обоих случаях печать документов это вещь отделенная от методов обсчета бизнес-объектов.

kot275Я как-то размыто вопрос задал. Попробую немного его сфокусировать.Это называется "сфокусировать"????

kot275 Нужен программный код на котором будет написано общение пользователя с БД. Так называемое система управлении базой данных(СУБД).Нет. СУБД это та часть которая хранит данные. Общение с пользователем это уже интерфейс.

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

kot275простой запрос к серверу БД, он возвращает массив данных(или по научному курсор),Нет. Массив данных возвращаемый СУБД и курсоры это две очень разные вещи. Первое это несколько строк, а второе это указатель на одну строку. Не надо их путать.

kot275 дальше мне надо нарисовать интерфейс. По первому варианту, я бегу в цикле по полученному набору данных и рисую картинку пользователю. По второму варианту, мне рисует это сам компонентs(это в Delphi например), ну там DataSet+dbGrid разные. Думается там тоже цикл, но утверждать не берусь,Да, там тоже цикл, но.... Обычно там цикл основанный на курсоре, но каждый курсор это открытый запрос к СУБД. Вполне работоспособно если доступ к базе идет в монопольном режиме и если ты показываешь только одну табличку за раз. Если надо делать многопользовательское приложение или показывать несколько табличек на экране одновременно - дельфевые компоненты становятся чрезвычайно неудобными.
Так что лучше вытягивать весь датасет в массив в памяти, а потом уже рисовать его на экране.

Представь что тебе надо работать с архивом. Архивом заведует специальный человек - архивариус. Ты ему говоришь: пойди в архив и принеси папки с делами за прошлый месяц. Он идет, копирует все дела за прошлый месяц и плюхает тебе на стол стопку папок с копиями. Ты в этой стопке копаешься, что-то делаешь. А в это время твой коллега отправляет архивариуса за делами за тот-же самый месяц - архивариус снова делает копии и отдает твоему коллеге его стопку. А если тебе нужно сделать изменение, ты пишешь бумажку и отдаешь ее архивариусу с командой: положи ее в папку номер АБВГД или убери из папки ФЫВА бумажку с заголовком ЙЦУКЕН. Это метод работы с массивами данных которые ты вытянул из базы целиком прежде чем работать с ними.
А теперь представь что ты говоришь архивариусу: дай первую папку за прошлый месяц - арихвариус бежит в архив приносит тебе папку и стоит возле твоего стола пока ты не вернешь ее, потом бежит за второй папкой за прошлый месяц... и на каждую папку ты даешь отдельную команду и архивариус бегает в архив и при этом приносит тебе не копию, а саму папку. Добавить или поправить какую-нибудь бумажку в этой папке становится очень просто.... Но в это время твой коллега сидит и скучает, потому что папки по одной появляются у тебя на столе. И архивариус бегает по твоим заказам и у него нету времени выслушать заказ твоего коллеги. Это метод работы с курсором.

kot275Особо умные DataSet помимо явно прописанного запроса еще и генерируют свои. Например, вытаскивают из метаданных БД название полей, автообновляют набор данных.Ни в коем случае не используй их! Это тот случай когда архивариус не только стоит возле твоего стола, но еще и советует как именно надо читать эти папки. А если ты читаешь их "не так", то следует немедленный удар дубинкой по голове.

kot275 Циклы ведь вещь медленная.С чего это вдруг?
Медленны не циклы, а то что внутри них. Сам по себе цикл это всего-лишь команда "повтори!" а вот что именно надо повторять - вот это уже может быть быстрым или медленным.

kot275 Везде пишут циклы медленные и лучше обойтись без них.Это писали идиоты.

kot275На MS Access обычно клиента по MS SQL и пишут. Еще под Opacle видел, но как сказали сами разработчики, это знатное извращение, но заказчик так захотел.Любое использование MS Access это извращение.

MS Access это прямой идеологический потомок однопользовательских систем типа FoxPro, Paradox, Clipper, etc. Но если эти СУБД изначально задумывались и работали как однопользовтельские СУБД. То MS Access это чрезвычайно тормозная однопользовательская база, в многопользовательском окружении.

П-ЛWhite OwlЛюбое использование MS Access это извращение.

MS Access это прямой идеологический потомок однопользовательских систем типа FoxPro, Paradox, Clipper, etc. Но если эти СУБД изначально задумывались и работали как однопользовтельские СУБД. То MS Access это чрезвычайно тормозная однопользовательская база, в многопользовательском окружении.
Это утверждение неверно. У аксеса много недостатков, есть очень яркие преимущества, но в многопользовательском окружении она "тормозит", если ее неправильно использовать. Вы наверняка мало знаете про аксесс АДП на базе МС СКЛ.

Так что для определенных случаев использование аксес - оптимальный выбор.Да, про "аксесс АДП" я не знаю ничего.
Зато я знаю о том как пишутся клиенты на других фреймфорках. И да, в моей практике был один клиент к большой СУБД написанный на Акцессе и пара баз целиком основанных на Акцессе...
По моему личному мнению, оптимальным выбором MS Access будет только для одной задачи: есть много данных в формате MS Access и надо с ними поиграться, а в нормальную базу переливать данные лениво. Во всех остальных случаях использование MS Access это извращение.