Трехслойка vs Двухслойка

← →
paul_k © (2006-01-31 12:21) [80]

Nikolay M. © (31.01.06 12:14) [77]
написано "для Access/MySQL/MS SQL/Cache" :)
SalesLogix 5.2
Interbase, MsSql, Oracle

> Вот Диасофт 5NT, например, умеет работать на MS SQL и
> Sybase ASE,

У них встроенный макроязык. разницей Sybase/Ms програмисты не парятся. Ну кроме ограничений использования мелкомягкого exec(<строка>)

← →
Курдль © (2006-01-31 12:21) [81]

> Nikolay M. © (31.01.06 12:17) [78]
> Опять же все зависит от того, как писать. Если логика лежит
> частично в тригерах, частично в ХП и никак недокументирована,
> то тут за счастье поддерживать костыли, чтобы все это не
> рухнуло, не то что на другую СУБД перейти.

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

← →
ANB © (2006-01-31 12:22) [82]

> Здесь тоже сыграло роль здравое начинание - писать по максимуме
> на ANSI SQL.

1. Сильно урезаются возможности
2. Увеличиваются тормоза

← →
Nikolay M. © (2006-01-31 12:23) [83]

> paul_k © (31.01.06 12:21) [80]

Буду знать. Сам в Диасофте, случайно, не работал? :)

← →
Nikolay M. © (2006-01-31 12:26) [84]

> Курдль © (31.01.06 12:18) [79]
> Вы хотите сказать, что left outer join работает менее оптимально,
> чем *= или = (+)?

Нет. T-SQL MS SQL-я позволяет, например, указывать в хинтах несколько индексов, обязательных к использованию в запросе, а в Sybase - только один. И таких нюансов - море.

← →
Dok_3D © (2006-01-31 12:26) [85]

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

Угу угу. Это ж каким черепом нужно обладать чтобы написать среднее звено, которое будет управлять транзакциями эффективнее, чем промышленная СУБД!

Но масштабировать такие системы и правда проще, что греха таить ...

← →
Курдль © (2006-01-31 12:27) [86]

> ANB © (31.01.06 12:22) [82]
> 1. Сильно урезаются возможности
> 2. Увеличиваются тормоза

1. Какие возможности сильно урезаются? ... connect by prior? И все?
2. Практика не показала увеличения тормозов, сопоставимых с пропускной спостбностью каналов (особенно внешних).

← →
seg (2006-01-31 12:28) [87]

Вы хотите сказать, что left outer join работает менее оптимально, чем *= или = (+)?

Этот синтаксис поддерживается, а вот такие функции как NVL, DECODE, не говоря уже о пакетах есть только в Oracle. Попробуй написать сложный запрос, который одинаково бы работал на SQL и Oracle.

← →
ANB © (2006-01-31 12:29) [88]

> msguns © (31.01.06 12:05) [71]
> >ANB © (31.01.06 11:55) [65]
> >Напряженно привести ситуевину, которую нельзя разрешить
> на оракле.
>
> Интернет.

Целая куча пакетов даже в 8, которая работает с интернетом

← →
paul_k © (2006-01-31 12:29) [89]

Nikolay M. © (31.01.06 12:23) [83]
неа. в Аладдине работал.. (у вас депозитарий и спецдеп от них) Идеологии в принципе схожие..

а с диасофтом сейчас потихоньку ковыряюсь..

← →
Курдль © (2006-01-31 12:30) [90]

> Nikolay M. © (31.01.06 12:26) [84]
> Нет. T-SQL MS SQL-я позволяет, например, указывать в хинтах
> несколько индексов, обязательных к использованию в запросе,
> а в Sybase - только один. И таких нюансов - море.

В первый раз услышал хоть о каком-то преимуществе MS SQL перед Sybase :) (хотя с ASE я не работал, однако слышал о его недостатках перед ASA).

← →
ANB © (2006-01-31 12:31) [91]

> Попробуй написать сложный запрос, который одинаково бы работал
> на SQL и Oracle.

Повесишься

← →
Dok_3D © (2006-01-31 12:32) [92]

2 ANB © (31.01.06 12:29) [88]

Ну что ты все про ORACLE, в самом деле :). Знаем, что "прога кульная".
Но, ты знаешь, она многозвенная.

← →
Reindeer Moss Eater © (2006-01-31 12:32) [93]

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

← →
Nikolay M. © (2006-01-31 12:32) [94]

> paul_k © (31.01.06 12:29) [89]
> неа. в Аладдине работал.. (у вас депозитарий и спецдеп от
> них) Идеологии в принципе схожие..

Угу, знаю :)

> paul_k © (31.01.06 12:29) [89]
> а с диасофтом сейчас потихоньку ковыряюсь..

Аналогично по мере необходимости. Еще та... мнэ... дыра :)

← →
paul_k © (2006-01-31 12:34) [95]

Nikolay M. © (31.01.06 12:32) [94]

> Еще та... мнэ... дыра :)

не надо о грустном...
Хотя текстовый построитель отчетов они веселый придумали. Да и ещё задумок хороших много.. а между задумками. именно оно...
И хорошо, что трехзвенку лепить не стали..

← →
Курдль © (2006-01-31 12:35) [96]

> paul_k © (31.01.06 12:29) [89]
> а с диасофтом сейчас потихоньку ковыряюсь..

И как? Сильно тошнит? :) Я с ним в банке работал... Н-да...

> seg (31.01.06 12:28) [87]
> Этот синтаксис поддерживается, а вот такие функции как NVL,
> DECODE, не говоря уже о пакетах есть только в Oracle. Попробуй
> написать сложный запрос, который одинаково бы работал на
> SQL и Oracle.

Пакеты - для серверной логики. Я же ранее говорил, что основная бизнес-логика исполняется на уровне апп-сервера. NVL и DECODE тупо переводятся в ISNULL и IF THEN ELSE.
Написать сложный запрос, который одинаково бы работал на SQL и Oracle попробовал. Работает :)
(Я ж писал, что перевод завершился и занял наделю работы и 3 недели тестирования).

← →
Nikolay M. © (2006-01-31 12:36) [97]

> Курдль © (31.01.06 12:30) [90]
> В первый раз услышал хоть о каком-то преимуществе MS SQL
> перед Sybase :) (хотя с ASE я не работал, однако слышал
> о его недостатках перед ASA).

Что значит Sybase? Sybase - это фирма, выпускающая три совершенно разных СУБД: ASA, ASE и IQ.

Насчет преимущества. Часто натыкался на грабли, что пытался в ASE применить конструкцию по аналогии из MS SQL, она не работала, а в форумах находил всегда один и тот же ответ: "в ASA такое есть, а в ASE нет" :(

← →
seg (2006-01-31 12:36) [98]

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

Могу сказать, что процедуры, написанные на PL/SQL не будут работать на других серверах и наоборот, а от к-во звеньев это ваще никак не зависит.
Это все равно, то перенести программу с С на Дельфи.

← →
Petr V. Abramov © (2006-01-31 12:37) [99]

"Толстый" клиент вполне может меньше весить, чем IE :)

← →
Nikolay M. © (2006-01-31 12:37) [100]

> paul_k © (31.01.06 12:34) [95]
> И хорошо, что трехзвенку лепить не стали..

Чур тебя :)))

← →
Digitman © (2006-01-31 12:37) [101]

> Dok_3D © (31.01.06 12:26) [85]
> Угу угу. Это ж каким черепом нужно обладать чтобы написать
> среднее звено, которое будет управлять транзакциями эффективнее,
> чем промышленная СУБД!

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

← →
seg (2006-01-31 12:38) [102]

Написать сложный запрос, который одинаково бы работал на SQL и Oracle попробовал. Работает :)

Запрос в студию!

← →
Desdechado © (2006-01-31 12:43) [103]

К упоминавшейся масштабируемости промежуточного звена:
- если не хватает мощности SQL-сервера для обработки ХП и прочего, то новый купить/настроить/поддерживать слишком дорого и проблемно
- если не хватает мощности промежуточного звена, просто ставим рядом второй такой же, и нагрузка между ними распределяется без потери функциональности

← →
Курдль © (2006-01-31 12:44) [104]

> seg (31.01.06 12:38) [102]
> Написать сложный запрос, который одинаково бы работал на
> SQL и Oracle попробовал. Работает :)
> Запрос в студию!

Ок. Сейчас выложу ораклевый запрос. Если надо - пороюсь в CVS-е и извлеку его версию под Sybase ASA.

select A_PR.SA_ID, Null as SA_ID_PR, A_PR.SA_REJECT, DA_PR.DOC_DATE, DA_PR.DOC_NUM, DA_PR.DOT_CODE, DD_PR.DOC_ID as DCL_ID, DC_PR.DOC_ID as CNTR_ID, DS_PR.DCS_SUMMA_RUB, DS_PR.DCS_SUMMA, DS_PR.VAL_CODE, V_PR.VAL_ATTR, COND_PR.CON_SMALL_NAME, AGP_PR.SYS_ID, AGS_PR.SYS_PLACE, DD_PR.DOC_NUM || " от " || To_Char(DD_PR.DOC_DATE, "dd.MM.yyyy г.") as DCL_NAME, DC_PR.DOT_CODE || " № " || DC_PR.DOC_NUM || " от " || To_Char(DC_PR.DOC_DATE, "dd.MM.yyyy г.") as CNTR_NAME, (case when DA_PR.DOT_CODE = "АВП" then 1 else 0 end) as ACT_TYPE, (case when DC_PR.DOT_CODE = "ДВП" then 1 when DC_PR.DOT_CODE = "ДИП" then 2 else 0 end) as CNTR_TYPE , (select NVL(sum(LS_CO.LNS_SUMMA_2), 0) from SC.SC_DOC_LINKS DL_CO, SC.SC_LINK_SUMMS LS_CO where DL_CO.DOC_ID_1=LS_CO.DOC_ID_1 and DL_CO.DOC_ID_2=LS_CO.DOC_ID_2 and DL_CO.DOT_CODE_1=LS_CO.DOT_CODE_1 and DL_CO.DOT_CODE_2=LS_CO.DOT_CODE_2 and DL_CO.BNT_CODE=LS_CO.BNT_CODE and DL_CO.DOC_ID_2=DA_PR.DOC_ID and DL_CO.BNT_CODE="006") AS PAY_SUMMA, (1 - NVL(A_PR.SA_REJECT, 0)) * NVL(DS_PR.DCS_SUMMA, 0) as REAL_SUMMA from SC.SC_INSUR_ACTS A_PR, SC.SC_DOCUMENTS DA_PR, SC.SC_DOCUMENTS DD_PR, SC.SC_DOCUMENTS DC_PR, SC.SC_DOCUMENT_SUMMS CS_PR, SC.SC_DOCUMENT_SUMMS DS_PR, SC.SC_VALUTS V_PR, SC.SC_CONTRACTS CNTR_PR left outer join (SC.SC_AGENT_POLICES AGP_PR inner join SC.SC_AGENT_SYSTEMS AGS_PR on AGS_PR.SYS_ID = AGP_PR.SYS_ID) on AGP_PR.CNTR_ID = CNTR_PR.DOC_ID, SC.SC_CONDITIONS COND_PR, SC.SC_DOC_LINKS L2, SC.SC_DOC_LINKS L3 where DA_PR.DOT_CODE in ("АКТ", "АВП") and L2.DOC_ID_1 = A_PR.SA_ID and L2.DOC_ID_2 = DD_PR.DOC_ID and L2.BNT_CODE = "001" and L3.DOC_ID_1 = DD_PR.DOC_ID and L3.DOC_ID_2 = DC_PR.DOC_ID and L3.BNT_CODE = "001" and CS_PR.DOC_ID = DC_PR.DOC_ID and CNTR_PR.DOC_ID = CS_PR.DOC_ID and COND_PR.CON_ID = CNTR_PR.CON_ID and V_PR.VAL_CODE = DS_PR.VAL_CODE and DA_PR.DOC_ID = A_PR.SA_ID and DS_PR.DOC_ID = A_PR.SA_ID and exists (select /*+ FIRST_ROWS */ Null from SC.SC_INSUR_ACTS A, SC.SC_DOCUMENTS DA, SC.SC_DOCUMENTS DD, SC.SC_DOCUMENTS DC, SC.SC_CONTRACTS CNTR left outer join (SC.SC_AGENT_POLICES AGP inner join SC.SC_AGENT_SYSTEMS AGS on AGS.SYS_ID = AGP.SYS_ID) on AGP.CNTR_ID = CNTR.DOC_ID, SC.SC_DOC_LINKS L5, SC.SC_DOC_LINKS L6, SC.SC_DOC_LINKS L4 where L4.DOC_ID_1 = A.SA_ID and L4.DOC_ID_2 = A_PR.SA_ID and L4.DOT_CODE_1 = "АИП" and L4.DOT_CODE_2 in ("АКТ", "АВП") and L4.BNT_CODE = "005" and L5.DOC_ID_1 = A.SA_ID and L5.DOC_ID_2 = DD.DOC_ID and L5.BNT_CODE = "001" and L6.DOC_ID_1 = DD.DOC_ID and L6.DOC_ID_2 = DC.DOC_ID and L6.BNT_CODE = "001" and CNTR.DOC_ID = DC.DOC_ID and DA.DOC_ID = A.SA_ID and DA.SBJ_ID_OWNER = :SBJ_ID_OWNER

← →
seg (2006-01-31 12:49) [105]

пороюсь в CVS-е и извлеку его версию под Sybase ASA.

Что значит "его версию"?
Ты выложи один запрос, который будет работать на всех серверах.

← →
Reindeer Moss Eater © (2006-01-31 12:54) [106]

Могу сказать, что процедуры, написанные на PL/SQL не будут работать на других серверах и наоборот, а от к-во звеньев это ваще никак не зависит.
Это все равно, то перенести программу с С на Дельфи.

Дело не в самом языке а о механизме сохранения значений переменных пакета в течение сессии клиента.
Например:
Коннект юзера к серверу. Вызывается процедура, которая инициализирует кучу переменных и структур пакета.
На MSSQL при вызове серверной логики с клиента на сервер надо передавать кучу параметров (скажем простейшее логирование активности: ID юзера,код события, текст).
На оракле код юзера можно не передавать, а использовать закешированное в пакете значение.
Этот механизм позволяет существенно снизить количество параметров процедур и функций, снизить трафик между клиентом и сервером и т.д.

← →
Курдль © (2006-01-31 12:54) [107]

> seg (31.01.06 12:49) [105]
> Что значит "его версию"?
> Ты выложи один запрос, который будет работать на всех серверах.

Я что, где-то выше по тексту упоминал "универсальный запрос"? :(

Я говорил, что адаптировать проект, выполненный на трехзвенке под новую СУБД в десятки раз проще, чем выполненный на двухзвенке. Кроме того, написал, что во многих местах запросы пришлось править. Однако, опять повторюсь, правки чаще всего были "механические" и умственной работы не требовали.

← →
Petr V. Abramov © (2006-01-31 12:54) [108]

> Desdechado © (31.01.06 12:43) [103]
> К упоминавшейся масштабируемости промежуточного звена:
> - если не хватает мощности SQL-сервера для обработки ХП и прочего, то
> новый купить/настроить/поддерживать слишком дорого и проблемно
> - если не хватает мощности промежуточного звена, просто ставим рядом
> второй такой же, и нагрузка между ними распределяется без потери
> функциональности
У Oracle это все сделано безо всякой трехслойки

← →
seg (2006-01-31 12:57) [111]

СУБД не УПРАВЛЯЕТ т/акциями

Я в шоке.

2 Digitman © (31.01.06 12:37) [101]

Да, пожалуй ты прав.
Я не то хотел сказать. Просто сам труд, из которого была выхвачена цитата, пестрит аргументами, которые, мягко говоря, можно повернуть и в сторону двухзвенки и в сторону трехзвенки.
Почему "операционная система сервера оказывается настолько загруженной управлением многочисленными подключениями к серверу" ? Разве в трехзвенке этого нет?
Почему "есть еще и дополнительное промежуточное звено, которое управляет транзакциями намного эффективнее"? Разве это нереально на двухзвенке?

> paul_k © (31.01.06 12:56) [110]
> Курдль © (31.01.06 12:44) [104]
> Это не сложный. Это большой запрос:)

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

Курдль © (31.01.06 12:54) [107]
Я говорил, что адаптировать проект, выполненный на трехзвенке под новую СУБД
совершал "переезд" с Sybase ASE на MS SQL. За счет изначально правильного подхода к разработке в очень большом проекте пришлось исправить 16 процедур. добавить 10 шаблонов в макроязык.
Система стала жить и в том и в другом сервере. На "переезд" ушел месяц. Причина - изначально правильно продуманный подход к разработке.

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

← →
seg (2006-01-31 13:02) [116]

Курдль © (31.01.06 12:54) [107]

Я писал:

можно писать только простые запросы, понятные обоим серверам, а если надо сделать более сложный запрос, то надо писать 2 версии - по одной для
каждого сервера.

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

2 Digitman © (31.01.06 12:56) [109]
СУБД не УПРАВЛЯЕТ т/акциями!

Автомобиль не ездит, он лишь исполяет команды "поехали", "стоп" и "дави бабку" :)

← →
seg (2006-01-31 13:06) [118]

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

Или не способные создать подобное.

> seg (31.01.06 13:06) [118]
> многозвенную архитектуру придумали люди не знакомые с сервером
> оракл
> иначе они конечно-же сразу бы поняли абсурдность данной
> парадигмы
>
> Или не способные создать подобное.

Каюсь! Я не способен создать сервер оракл :(

> Dok_3D © (31.01.06 13:03) [117]

Дурью не майся уже)

Так ведь и есть - автомобиль "слушает" и "исполняет"ё твои команды.. А тебе как "ездюку" по колено как он там это делает ...

и не говори что это не так) ...

Трехслойка vs Двухслойка Найти похожие ветки