Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 3 4 5 6 7 [8] 9 10 11 12 .. 17   вперед  Ctrl
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
vadiminfo
В двухзвенной:

Клиент - Интерфейс пользователя, Основная логика обработки данных
Сервер БД: Контроль данных на серверной стороне, Доступ к БД.

Поэтому как бы походы клиента в БД выглядят излишними.


Эээээ, батенька, да вы неправильно себе представляете клиент-серверное приложение!!! Вот оно что, вот почему вы за многозвенки то ратуете!!!

Вы немного ошиблись в описании к-с систем, но ошибочка то ваша дорогого стоит.

Вот смотрите, как на самом деле должно быть и есть обычно:

Клиент - Интерфейс пользователя
Сервер БД: Основная логика обработки данных, Контроль данных на серверной стороне, Доступ к БД.


Вон где должна быть вся логика. В БД. И не мудрено, что вы не понимаете, почему к-с лучше.
А ваша схема отвечает файл-серверным системам.

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

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

ЗЫ Может кто еще все еще думает, что логика лежит на клиенте? Хотя уже три страницы говорится о том, что вся логика в БД!!!

-- Tygra's --
11 окт 04, 11:57    [1022753]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
savage79
Member

Откуда:
Сообщений: 27
Повторюсь, не всегда можно все обработать только средствами БД. Иногда бывают случаи когда нужна:

1. обработка по расписанию (с помощью ХП можно выполнить задачи по расписанию?)

2. обработка входных файлов, напимер для систем эл. документооборота, когда клиент может выгрузить на сервер неструктурированный документ, напимер формата word, этот документ должен быть разобран с помощью какой-либо бизнес-логики, выделена нужная информация, напимер из полей excel файла или полей doc файла (договор формата word с полями в который обозначена сумма договора и пр.) (это можно сделать с помощью ХП?)

3. обработка источников данных отличных от БД. (работа с эл.почтой и другими информационными системами)
11 окт 04, 12:54    [1023075]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
автор
1. обработка по расписанию (с помощью ХП можно выполнить задачи по расписанию?)

Да, конечно, это можно сделать с помощью job-ов - настроить выпонение ХП на конкретное время, периодичность и т.д. Оно обычно всегда применяется - хотя бы для бэкапов.

автор
2. обработка входных файлов, напимер для систем эл. документооборота, когда клиент может выгрузить на сервер неструктурированный документ, напимер формата word, этот документ должен быть разобран с помощью какой-либо бизнес-логики, выделена нужная информация, напимер из полей excel файла или полей doc файла (договор формата word с полями в который обозначена сумма договора и пр.) (это можно сделать с помощью ХП?)

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

автор
3. обработка источников данных отличных от БД. (работа с эл.почтой и другими информационными системами)

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

-- Tygra's --
11 окт 04, 13:09    [1023169]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
tygra

Эээээ, батенька, да вы неправильно себе представляете клиент-серверное приложение!!! Вот оно что, вот почему вы за многозвенки то ратуете!!!


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

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

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



tygra

А ваша схема отвечает файл-серверным системам.


К, сожалению, не моя. В файл сервеной на стороне сервера только файлы, а на каждом клиетском компе СУБД. А на файл-сервере только контроль доступа к файлам. Т.е. на клиенте еще и "Контроль данных на серверной стороне, Доступ к БД".

tygra

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




Хорошо, среднее звено заберет логику из БД.
Речь не о том, что нельзя обойтись без среднего слоя. А о преимуществах, которые он может дать в общем случае.
Кто-то, может, скажет, что можно обойтись и файл-серверной архитектурой - клиен серверная не нужна. Все можно и в файл-серверной. Мы же до этого про преимущества говорили.

tygra

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


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



tygra

ЗЫ Может кто еще все еще думает, что логика лежит на клиенте? Хотя уже три страницы говорится о том, что вся логика в БД!!!


Страницы страницам рознь. Есть еще и какие-то традиционные вещи, придуманные теми, кто создавал все эти технологии. Впрочем, даже этот частный случай вроде пока не отменяет тех преимуществ, что я писал.
Хотя, я тоже писал, что из соображений перераспределения ресурсов ХП реализуют часть логики клиентов. Но на сколько это здорово пока не знаю. Однако, чаще клиенту возвращаются курсоры и результаты запросов, которые представляют клиенту абстрактные по отношению к внешней модели данные. А клиент обработывает их уже в соответствии с логикой для пользователя этого клиента. Решает линейные уравнения или просто рисует шахматки и т.д.
11 окт 04, 13:25    [1023266]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
Denis A.
Member

Откуда: Челябинск
Сообщений: 353
Чота все перешли во флейм и забыли, что не бывает абсолютных вещей. Любое решение прежде всего делается для РЕШЕНИЯ задачи. Трехзвенка - это не панацея от любых проблем, также как и двухзвенка. Если бы эти технологии не были нужны они бы просто не появились. Случаи - они разные бывают. Искусство программиста - найти золотую середину.

Спор считаю бредом, так же как и любое другое мнение, хыхы ;)
11 окт 04, 13:27    [1023277]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
Ну зачем же выписывать из каких-то книг странные определения.

Мы говорим не об определениях, а о реальных системах.
А реальные нормальные клиент-серверные системы держат всю логику в БД.

И есть вопрос как раз - какие преимущества дает средний слой кроме лишней работы? Приду с обеда - напишу полнее....

-- Tygra's --
11 окт 04, 13:33    [1023319]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
tygra

Ну зачем же выписывать из каких-то книг странные определения



Их странность не так уж и очевидна.

tygra


А реальные нормальные клиент-серверные системы держат всю логику в БД.



Это можно истолковать и как обоснование трехзвенки для реальных нормальных систем. Логика на ХП - это серверная часть приложения. Даже то, что она в БД уже можно рассматривать как сервер приложения в БД. Т.е. средний слой в БД. В Оракле 8 EJB реализуется так, что контейнер в БД. Т.е. логически трехзвенка, физически двухзвенка. Почему бы теперь его не вынести из БД в некоторых случаях? Оракл 9 и вынес ее.

tygra

И есть вопрос как раз - какие преимущества дает средний слой кроме лишней работы?


Одно из, которых мы и пытаемся оценить. То что Вы всю логику запихали в БД, отменяло преимущество тонкого клиента в трехзвенке. Означает, что в некоторых случаях (примитивная логика клиента) это преимущесто трехзвенки не проявляется.
А вот на большую независимость клиента от СУБД и наоборот это вроде мало влияет.
Вызовы ХП на сервере приложений. Меняете СУБД, исправляете на сервере приложений что-то, но клиенты ничего не знают об этом - их менять не надо. Поясните это.
11 окт 04, 14:01    [1023464]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
Ну вот я и пообедал (привозным корпоративным обедом, бее...)

автор
Не я, однако, это - традиционная двухзвенка (не поленился толстую книгу открыть и переписать). Обратите внимание на термин "традиционная".

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

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

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

автор
А традиционно представления, что нечего в БД делать логике клиента(тов).

О какой такой логике клиентов идет речь? Есть логика системы - при чем тут клиент. И давайте будем отталкиваться от того, что современная к-с система подразумевает хранение максимального объема логики в БД.

автор
Там информация, а на клиенте логика ее обработки согласно внешней модели данных для того юзера, для которого этот клиент.

А вот это уж совсем неправда. Такой подход был и есть к файл-серверным системам. Потому что там не могло ничего обрабатываться в БД - не было ее как таковой.

автор
Боюсь, что Вы скорей обосновываете пользу многозвенки, чем ее опровергаете.

Так вот как раз наоборот :)

автор
На клиенте логики быть не должно

Точно! У меня и еще десятка-другого человек из этого форума ее там и нет.

автор
а в БД она как бы не совсем на своем месте.

А вот тут то вы и ошибаетесь! Как раз там ей и место. Как раз там она у нас всех и находится.
Тут понимаете ли получается вот что: те, кто разрабатывают к-с системы, опираются не на древние определения, а реально разрабатывают, и так, чтобы было как можно лучше, проще и удобнее. И получается, что именно сейчас вот это лучше, проще и удобнее - когда логика вся лежит в БД.
То, что вы никогда не разрабатывали к-с систем, или имеете негативный опыт разработки, или пользовались при разработке определением из книг, совсем не значит, что все системы именно такие убогие.

автор
Но в любом случае в двухзвенке некоторая часть логики в серьезных приложениях оказывается на клиенте (Вызовы ХП и какая-то обработка данных, которые они вернули).

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

В третьих....
Ну поверьте, поверьте мне и нам, нет никакой логики на клиенте в наших системах, ну нет ее там, нет!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Вся логика в БД, вся, вся, которая только может там быть!!!!!!!!!!!!!!!


Давайте вы теперь именно с такой стороны будете сравнивать к-с систему и многозвенку, ну пожалуйста, не надо определений никаких из книг!!! :)

===========

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

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

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

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

К, сожалению, не моя. В файл сервеной на стороне сервера только файлы, а на каждом клиетском компе СУБД. А на файл-сервере только контроль доступа к файлам. Т.е. на клиенте еще и "Контроль данных на серверной стороне, Доступ к БД".



-- Tygra's --
11 окт 04, 14:21    [1023572]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
Последний абзац считать недействительным - случайно нажал кнопку "Опубликовать" :))

===

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

Я и пытаюсь найти достоинства, но никак не нахожу. Лично для себя.

автор
Это можно истолковать и как обоснование трехзвенки для реальных нормальных систем. Логика на ХП - это серверная часть приложения. Даже то, что она в БД уже можно рассматривать как сервер приложения в БД. Т.е. средний слой в БД. В Оракле 8 EJB реализуется так, что контейнер в БД. Т.е. логически трехзвенка, физически двухзвенка. Почему бы теперь его не вынести из БД в некоторых случаях? Оракл 9 и вынес ее.


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

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

-- Tygra's --
11 окт 04, 14:26    [1023599]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
Да чтож ты будешь делать, опять не в ту кнопку :)

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


Уже пояснил выше. Слишком дорогое решение для призрачных надежд.
Сколько систем, вами написанных, незаметно перешли на другой сервер? И как незаметно это было?

==============
Ох, наверное завершу я тут, а то устал. Да и работать надо :)

-- Tygra's --
11 окт 04, 14:29    [1023611]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Т.е. получается, что Вы не против трехзвенок, а под двухзвенкой понимаете логическую трехзвенку, и не интерпрайзный сервер приложений типа ХП. Но против физических трехзвенок и их энтерпрайзных технолгоий EJB, CORBA, WEB - сервисы и неинтерпрайзных. У нас просто опять путаница в терминологии. А Вы говорите зачем переписывать определения? Чтобы лучше понять о чем мы говорим.
11 окт 04, 14:29    [1023612]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
Но все же резюмирую:

Единственное "достоинство" многозвенки - это незаметная для клиента подмена апп-сервера для работы с другой СУБД.

В 90% случаев это достоинство не имеет значения.

-- Tygra's --
11 окт 04, 14:31    [1023618]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
автор
Т.е. получается, что Вы не против трехзвенок, а под двухзвенкой понимаете логическую трехзвенку, и не интерпрайзный сервер приложений типа ХП. Но против физических трехзвенок и их энтерпрайзных технолгоий EJB, CORBA, WEB - сервисы и неинтерпрайзных. У нас просто опять путаница в терминологии. А Вы говорите зачем переписывать определения? Чтобы лучше понять о чем мы говорим.


Немного не так.

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

Так пойдет?

Может кто еще получше даст определение - я не очень то в таких вещах. :)

-- Tygra's --
11 окт 04, 14:39    [1023673]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
savage79
Member

Откуда:
Сообщений: 27
tygra

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

Фактически получается, что сервер БД выполняет функции сервера приложений, или другими словами, сервер приложений встроен в СУБД, как верно подметил vadiminfo.
Да и многие ли СУБД могут выполнять то, что написал tygra? Какой процент из всех существующих СУБД? Сервер приложений, в данном случае более универсальное средство.
11 окт 04, 14:41    [1023682]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
Yo!
Guest
>Может кто еще получше даст определение - я не очень то в таких вещах. :)

эт видно, хоть бы книжку прочел прежде чем столько глупости писать ...
11 окт 04, 14:43    [1023700]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Гм, как то путанно все вышло :) Давайте определимся, кто что и под чем понимает:
1. Все пришли к выводу, что на клиенте бизнес-логику хранить не хорошо (и слава богу). Клиентское приложение должно красиво рисовать рюшечки, гриды, отчеты и вообще вести простой и безоблачный образ жизни :)
2. Все сошлись во мнении, что бизнес-логика должна писаться на средстве, которое заточено под это и имеет ряд особенностей, таких как безопасность и права доступа, управление транзакциями, возможность промежуточного кэширования данных и т.д.
3. Все согласны с тем, что слой бизнес-логики должен контролировать действия клиентов, отслеживая ненарушения истинности данных с точки зрения логической модели БД и позволять быстрый и прозрачный доступ к чтению и изменению данных клиентами.

Уф, теперь смотрим:
Способ создания слоя бизнес-логики № 1
- использование встроенного языка хранимых процедур СУБД позволяет в полном обьеме, достаточно легко и полнофункционально реализовать все, что перечесленно в этих 3-х пунктах. В качестве недостатков можно отнести алгоритмичность языка, что однако перекрывается огромным достоинством - интрепретируемостью языка хранимых процедур и динамическим SQL. Я, например генерю триггеры и процедуры по шаблонам с поддержкой макросов (на лично разработанном под это средстве, но любое Case умеет то же), что позволяет описывать повторно используемые скрипты - от запросов до целых секций кода, где каждая таблица в БД имеет свое расширенное мета-описание в метаструктуре на достаточно высоком логическом уровне - например, у таблицы выставлено, что она является хранилищем аттрибутов обьектов некой родительской таблицы, изменяющихся во времени. Будут сгенерированы все нужные ХП и триггера - контроль, возвращение значений обьектов и их текущих аттрибутов, ХП добавления, изменения и удаления записей с нужной раскидкой по обоим таблицам. Клиентскому приложению остается только воспользоваться сгенерироваными ХП и даже не знать о том, что обьект на самом деле поделен на 2 таблицы. К слову у меня в проекте большая часть логики (под 200 хранимых процедур и 150 триггеров) сгенерировано автоматически и одним взмахом руки (по F5) я могу централизованно изменить или дополнить в них логику, просто отредактировав макет :)

Способ создания слоя бизнес-логики № 2
- использование апп-сервера и высокоуровнего ООП языка. Фактически то же самое, что и способ № 1, только вся реализация вместо интрепретируемого языка, макетов и т.д. ведется посредством компонент, ООП и других прелестей высокоуровневых языков и возможностей апп-серверов.

Итак что видим - интерфейс (назначение) у обоих способов одинаковое, имплементашион (реализация) естественно разная.

Тут вспоминаем IBM DB2 и глубокомысленно задаем себе вопрос - БД на этой СУБД, где нет языка хранимых процедур и все пишется через внешние Си или Java процедуры - это к чему относить ?

Из этого вопроса возникает следствие - все мы программируем как минимум на 3-х звеньях, отделяя данные, бизнес-логику и клиента. Только одним нравиться это делать по SQL-ному, так как если посмотреть триггера и ХП, то окажется, что там от алгоритмического языка маловато будет - все запросы, да запросы. А другим нравиться все на классах, контейнерах и компонентах делать. Из сего вывод - сравнивать 2-х и 3-х звенку в данном контексте бестолку, давайте уж сравнивать подходы - алгоритмически-запросные и ООП-компонентные.

P.S. Уф, надеюсь выразился понятно и внятно :)
11 окт 04, 15:16    [1023843]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
savage79
tygra

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

Фактически получается, что сервер БД выполняет функции сервера приложений, или другими словами, сервер приложений встроен в СУБД, как верно подметил vadiminfo.
Да и многие ли СУБД могут выполнять то, что написал tygra? Какой процент из всех существующих СУБД? Сервер приложений, в данном случае более универсальное средство.

В догонку - как минимум, у двух из известных мне СУБД, языки хранимых процедур PL/SQL Оракла и WatcomSQL Sybase ASA позволяют писать достаточно мощный по функционалу код (вплоть до обработки исключений, области видимости переменных, поддержки и работы в скриптах с обьектами Java, хранению Java обьектов в полях таблиц и полноценной работе с их методами и полями прямо из SQL и т.д.). TSQL от MSSQL пока в этом плане отстает, но с выходом 2005 версии сократит разрывы и ограничения, особенно если учесть интеграцию в него поддержки C#.
11 окт 04, 15:23    [1023888]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
savage79
Member

Откуда:
Сообщений: 27
ASCRUS

P.S. Уф, надеюсь выразился понятно и внятно :)

Cказано все верно и я полностью с этим согласен. Тока к сожалению не все разработчики понимают, что бизнес логику на клиенте хранить не надо. Пример тому это всем хорошо известная пресловутая 1С. )
11 окт 04, 15:25    [1023897]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
---------------
Guest
savage79
Тока к сожалению не все разработчики понимают, что бизнес логику на клиенте хранить не надо. Пример тому это всем хорошо известная пресловутая 1С.
Да все они понимают. Только вы себе представляете инерцию продукта с такими тиражами как у них ? Да еще учитывая необходимость поддержки разных версий.
11 окт 04, 15:34    [1023931]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
Yo!
эт видно, хоть бы книжку прочел прежде чем столько глупости писать ...

Тут уже были определения из книжек... Устарели они Да и я по поводу давания определений, а не по предмету, туг на язык :)

2 ASCRUS
Тоже полностью согласен

2 savage79
Не только 1С. Есть и на нашем форуме люди, которые хранят логику на клиенте. Не будем на них показывать пальцем. :)

В общем, победила дружба :)

-- Tygra's --
11 окт 04, 15:49    [1024023]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
автор

Тут вспоминаем IBM DB2 и глубокомысленно задаем себе вопрос - БД на этой СУБД, где нет языка хранимых процедур и все пишется через внешние Си или Java процедуры - это к чему относить ?


Уважаемый ASCRUS наверно не в курсе - но все это есть в DB2.
Была лишь разница в способе реализации по сравнению с другими базами данных.ХП были с версии 5. Сохраненку можно было писать на SQL/PL и на серваке она преобразовывалась в C - код. Нужен был С++/ Java компилер на стороне сервера. А начиная с версии 8.2 (Stinger) - появилась поноценная реализация внутренней машины SQL/PL языка. И теперь необходимость в компиляторе на стороне сервера отпала.

Но, говоря по честному, то, как был реализован COMPOUND SQL в DB2 - это было очень похоже на урезанный встроенный компилер SQL/PL. Вобщем IBM

Замечу всеже, что сохраненки на С/C++ работают все равно быстрее чем с помощью внутренней машины SQL/PL. И они особенно полезны при громоздких вычислениях на стороне сервера.
11 окт 04, 15:51    [1024033]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
gardenman

Уважаемый ASCRUS наверно не в курсе - но все это есть в DB2.
Была лишь разница в способе реализации по сравнению с другими базами данных.ХП были с версии 5. Сохраненку можно было писать на SQL/PL и на серваке она преобразовывалась в C - код. Нужен был С++/ Java компилер на стороне сервера. А начиная с версии 8.2 (Stinger) - появилась поноценная реализация внутренней машины SQL/PL языка. И теперь необходимость в компиляторе на стороне сервера отпала.

Но, говоря по честному, то, как был реализован COMPOUND SQL в DB2 - это было очень похоже на урезанный встроенный компилер SQL/PL. Вобщем IBM

Замечу всеже, что сохраненки на С/C++ работают все равно быстрее чем с помощью внутренней машины SQL/PL. И они особенно полезны при громоздких вычислениях на стороне сервера.

Ну еще лучше. Думаю постоянное эволюционное развитие языка хранимых процедур во всех СУБД доказывает, что это тоже перспективное направление и никто сломя голову не бросится отказываться от него :)
11 окт 04, 16:00    [1024091]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
ссылка на эту тему
11 окт 04, 16:00    [1024092]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
Yo!
Guest
размещение логики на апп-сервере по всем статьям выгодней и имет всего один небольшой минус ...

маштабирование - явно апп сервер предоставляет больше возможностей.
секьюрити - клиенты не имеют прямого доступа, субд находится в dmz ... апп сервер предоставляет гораздо больше возможностей.
мощнее язык - java vs t-sql (не забывем что sql никто не отменял, речь о процедурных расширениях) спецы дешевле, кода меньше, выбор больше. на все задачи уже есть патерны и фреймворки.
хотя конечно можно java вызывать из t-sql но смысла от этого маловато.

фишка апп сервера что есть уже готовые фреймворки там есть все. все уже изобретено, практически на все случаи жизни. нужно просто посмотреть как это делается http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpatterns/html/MSpatterns.asp

есть все один небольшой минус :) он работает не эфективно и делает кучу бесполезных действий ...
11 окт 04, 16:23    [1024221]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
автор

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

Так пойдет?





Нет так, наверное, не совсем получится глапдко. Клиен серверная система означает всего лишь, что в системе есть клиенты и сервера. Другое дело что понимать по двухзвенной и трехзвенной архитектурой. Там на первом месте распредеклений функций. Где находится логика приложения клиента. На сервере - признак трехзвенной архитектуры. ПО сути то, что Вы называете двухзвенкой можно назвать как нетрадиционной двузвенкой, так и нетрадиционной трехзвенкой. Там есть признаки и того и другого из традициооных. Однако, с точки зрения распределения функций это ближе к трехзвенкам.

Идея того, что данные не отделены от логики восходит к универсальному программированию и было харатерно для самых первых систем с БД. Плоская файловая модель. Это более устаревшее, если мы это учитываем. Реляционная модель специально и создавалась для их наибольшего разделения данных от прог, поскольку стало ясно, что независимость данных имеет значения в условиях, когда много разных по природе клиентов работают с одними и теми же данными. У БД есть логическая модель, которая хранится с данными. Но логика клиента это другое. Это связщано с внешней моделью данных, которох может быть много в одной системе.

То, что есть для них один модуль, тоже не известно насколько хорошо согласуется с идеями модульной декомпозиции.


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

И определения из книжек не устарели. Недавно изданные.
11 окт 04, 16:34    [1024280]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 3 4 5 6 7 [8] 9 10 11 12 .. 17   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить