Оптимальная архитектура БД

2All

Хммм... Мне кажется, что понятие Трехзвенки несколько неверное.

Дело в том, что можно, как у вас, реализовавыть физическую трехвенку:
- Клиент
- Промежуточный сервер (app-сервер)
- Сервер базы
при этом либо Клиент вынужден довольно много знать об представлении
данных на уровне app-сервер'а, либо, что еще хуже - непосредственно
об представлнении на уровне Сервера Базы (двухзвенка).


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

Господа, а не учесть ли вам такой плюс 3звенки как высокий уровень масштабируемости? Ведь application server может быть не 1 -by машин а от 1 до n
Собственно,производители ERP систем и идут по этому пути. Сервер баз данных - исключительно БД - хп используются только для оптимизации запросов, но не для бизнес-логики.

2Andrey Bel
Как всегда почти в любом споре скатились к определению
понятий.

Поскольку в определении 2 - 3 звенной архитектуры наблюдаются
разногласия, предлагаю следующий вариант (может весь спор
возник просто из-за разницы терминологий)

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

Мы рассматриваем только следующую архитектуру

2-х звенка - система, где есть БД (в данном случае MS SQL Server)
и клиент
БД - хранит данные и совершает с ними все операции -
занесение, исправление, удаление, выборка (например, через SP -
вариант прямой работы с таблицами уж больно грустный)

3-х звенка имеет несколько другую идеологию
а) есть сервер БД - хранилище данных в нормализованных таблицах,
естественно с операциями типа insert, update, delete, select
оформленных в виде SP или view
б) есть промежуточный сервер - который занимается только
преобразованием бизнес-логики (бизнес-объектов и бизнес процессов)
в 2 и обратно
в) есть клиент, который взаимодействует только с б) на языке
БО-БП

При этом не столь существенно, как будет реализован б)
В нашей практике использовались след варианты
- промежуточный сервер (общение с клиентом на уровне Tcp -пакетов)
- выделенный MS SQL Server
- специальный обработчик клиента (компонент Delphi)
- спец обработчик псевдоязыка (можно реализовать как на сервере,
так и на клиенте)

P.S. Если интересно, могу привести нашу эволюцию технологий
разработки, начиная с середины 80-х гг. Мне, честно говоря,
это временами кажется забавным :)

2 dkstranger:

Мне было бы интересным для общего развития, и чтобы лучше понять логику .

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

Если не хотите писать в форуме - можно по e-mail.

P.S.
"Как всегда почти в любом споре скатились к определению
понятий."

Так не надо же в споре скатываться к определению понятий, а надо любой спор начинать с определения понятий - в любой книжке по спорам и переговорам написано :-)

"(может весь спор
возник просто из-за разницы терминологий)"

Мне кажется, что так и есть :-) (см. выше)

Ну вот ужо и я

Собственно хотелось обобщить:

Сравнивая 3-х и 2-х звенки, нужно учитывать тогда архитектуру системы, а уж в этом контексте сравнивать.

Если говорить о стандартных задачах, системах, подходах - т.е. практически 95% всего, что есть, то тут 2-х звенка гораздо эффективнее всех остальных n-звенок.
Если говорить об эффективности 3-х звенки - то только там, где специально под нее делалась структура системы, причем с самого начала. И к тому же еще, что данную задачу никак нельзя выразить 2-х звенкой. Больше случаев применения 3-х звенки я не вижу.

Если говорить о том, что средний слой разбирается с методами выборки или обработки данных - у нас этим прекрасно занимается ХП.

В итоге мы получаем, что каком либо изменении структуры, которое затрагивает кол-во или вид представляемых данных, так или иначе придется менять клиента - хотя бы немного, но в 3-х звенке придется менять еще и средний слой - однозначно проблем больше

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

2 SQL.RU Admin

Я так много написал - но мой пост пропал при нажатии на кнопку "Предварительный просмотр" :-(((((

Еще раз пистаь не буду. Грустно

2tygra
Если говорить об эффективности 3-х звенки - то только там,
где специально под нее делалась структура системы,
причем с самого начала.
Я почти соглашусь с этим утверждением.
Скажу только, что такое специальное проектирование
называется объектным подходом и, действительно, часто дает
большой выигрыш, прежде всего, в возможности развития системы,
затем, при грамотном подходе, и в производительности:)

Если говорить о том, что средний слой разбирается с методами выборки или обработки данных - у нас этим прекрасно занимается ХП.
В принципе, почти всегда средний слой можно отранслировать
в процедуру и перейти с 3-звенной архитектуры к 2-звенной
(например, сделать таблицу определения бизнес-объектов и передавать их в качестве параметров). Дело в том, что при отсутствии промежуточного
звена очень быстро такие процедуры становятся громоздкими (как я писал в своем примере - у нас уже на 2-3 версии характерная длина такой процедуры достигла 300 строк - а это - только начало).
Плюс далеко не всегда общие блоки таких процедур можно выделить с самого
начала и оформить в виде соответсвующих ХП - значит, при любом чихе
надо исправлять кучу ХП огромной длины.
В данном случае прелесть промежуточного звена как раз в том и состоит,
что он фактически является транслятором из объектного представления в
язык БД (запросы, ХП , view и т.п.) и существенно повышает эффективность
самой разработки (это преобразование делает на программист, а промежуточный сервер).

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


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

В результате предлагаю следующее резюме

1. Для разработчиков, владеющих объектным подходом, 3-звенная
архитектура может дать заметный выигрыш (например, поскольку большая часть рутинной работы ложится на промежуточный сервер)
2. Для разработчиков, не использующих объектный подход, 2 и 3 звенки практически эквивалентны
3. Использование объектного подхода в реальных проектах оправдано -
- прежде всего, для понимания и формализации постановки задачи
- при использовании 3-звенной архитектуры позволяет резко
повысить скорость разработки и, в результате, например,
увеличить производительность или функциональность
(за счет более эффективной реализации достаточно сложных
связей между объектами, а такие связи, на самом деле есть в любом проекте)

2 Toro
Если интересно, предлагаю открыть новый топик,
или напиши мне DKObmen@newmail.ru

Дмитрий

2dkstranger

Не скатились, а начали. :)

То самое, об чем я говорю - взаимодействие БО-БП - должно обисываться языком, приближненным к предметной области. Если оно остается на уровне читать/писать _данные_, то смысла в нем чуть больше чем в 2-х звенке.

По резюме - очередность 3 - 1 - 2.