Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 [6] 7 8 9 10 .. 14   вперед  Ctrl
 Re: использование хранимых процедур  [new]
Yo.!
Guest
DPH3

Но в моей практике встроенных возможностей не хватает, приходится писать код для авторизации. А тут уже разницы между средним уровнем и T-SQL не наблюдается (по крайней мере, в пользу TSQL).

ну если у мсскл не наблюдается понаблюдайте у оракла - oracle label security (Oracle Vault слегка из другой оперы). с деревьями же даже мсскл научился работать в мсскл2005.

ЗЫ. oracle 10.1 снят с супорта ...
29 окт 09, 18:16    [7858557]     Ответить | Цитировать Сообщить модератору
 Re: использование хранимых процедур  [new]
Favn
Member

Откуда:
Сообщений: 585
barrabas
потом синтаксис проще (не нужно создавать объекты типа sqlcommand (или как он там уже) и биндить переменные) , а просто писать sql в процедуре и все.
Почитайте про SQLJ.
29 окт 09, 18:19    [7858576]     Ответить | Цитировать Сообщить модератору
 Re: использование хранимых процедур  [new]
DPH3
Guest
Yo.!

уже перетиралось тут не раз, на С писалось у всех, но все постепенно перешли на следующую ступень - на языки 4GL. и только дб2 пропустил революцию и все кропал по старинке, в терминах оракла это завется технологией препроцессоров, говорят в оракле вымершая в 80-х годах прошлого столетия. поняв, что на дедовских технологиях далеко не уедешь ибм выкатил sql/pl где-то лет 10 назад, но в то время как раз была мода 3-tier и подавляющее большинство действительно так его и завет "какой-то PLSQL подобный" ...

Угу. Только Oracle так и продолжает рассчитывать на 4GL, а мода то убежала в сторону 3-tier, где нужно уже не это, а нормальные драйвера :) Про что я, собственно, и говорю.
Правда, чем 4GL лучше, нежели универсальные managed языки - мне тоже не понятно. Чем plain C - более менее понимаю, да.


подавляющее большинство действительно так его и завет "какой-то PLSQL подобный" ...

Если я правильно читаю новости, то в 9.5 включили именно поддержку синтаксиса PL-SQL.
Т.е. запуск оракловских хранимок без переписывания, прямо как есть.
(Последствия такого запуска - за свой счет, как водится).


да не умеет дб2 ту же жаву в контексте сервера пускать, только как fenced. уже два раза обсасывали.

Там обсуждение так быстро сваливалось в флейм, что я так и не понял, до чего там договорились :)
Как я понял, в любом случае разницы между sql/pl и java - нет (для DB2).
29 окт 09, 18:27    [7858627]     Ответить | Цитировать Сообщить модератору
 Re: использование хранимых процедур  [new]
ЛП
Guest
baracs
ЛП
baracs
И если клиент читает/меняет данные в БД через хранимые процедуры, это:
- во многих случаях, сильно ускоряет работу системы в целом,
- упрощает обеспечение целостности и непротиворечивости данных,
- сильно упрощает сопровождение и развитие системы;
- про разделение доступа к объектам бд тут уже много писали...

В случае, если у СУБД ровно один клиент (а это именно случай многозвенных приложений) - Ваше высказывание неверно по всем пунктам (по некоторым пунктам оно неверно и в случае многих клиентов)

А поподробнее?

А чего подробнее то?

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

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

Аргумент "упрощение сопровождения и развития" - для одного клиента неверно. Для многих клиентов - верно (проще сопровождать код на одном сервере, чем на многих клиентов), а для одного - нет (что на одном сервере код сопровождать, что на одном клиенте).

Те же самые соображения в ответ на аргумент "разделение доступа к объектам". Что рулить доступом к объектам на одном единственном сервере, что рулить доступом к объектам на одном единственном клиенте - нет разницы.
Вернее, разница есть, и она не в пользу хранимок.
Рулить доступом к объектам на клиенте я могу любым удобным мне способом. Любым. Удобным. Мне.
Чего нельзя сказать про управление доступом к хранимкам и прочим объектам на сервере БД.
29 окт 09, 18:31    [7858642]     Ответить | Цитировать Сообщить модератору
 Re: использование хранимых процедур  [new]
Yo.!
Guest
Favn
Появился SQL PL в 7-й, кажется, версии, то есть он не намного моложе Java, к примеру. Или молодую Джаву тоже использовать не надо? ;)

дык, только вот жава - мейнстрим, а об существовании sql/pl и половина db2 кодеров не подозревает.


Favn
PL SQL единым для DB2 LUW


только вот сам luw не единый, а до v9 и для luw нужно было С компилятор для sql/pl таскать.

Favn
Она, конечно, лучше "вписана" в СУБД, чем Java, но спасает ли это от переключения контекстов?

скорострельность pl/sql далеко не единственная, а главное не главная фича :)

Favn
Кстати, о "лишь базовых конструкциях" - в последнем DB2 9.7 SQL PL в части обработки данных в БД функционально ничем не хуже PL/SQL. А остальное, ИМХО, всяко лучше на Java писать.

ну ерунду не говорите, там нет базовых конструкций. нет аналога пакетам, нет реф-курсоров, нет и трети функий из базовых пакетов оракла. посмотрите чего может эмулировать db2 9.7 в плане pl/sql, он же и половины конструкций не переваривает.
29 окт 09, 18:33    [7858659]     Ответить | Цитировать Сообщить модератору
 Re: использование хранимых процедур  [new]
DPH3
Guest
Yo.!

ну если у мсскл не наблюдается понаблюдайте у оракла - oracle label security (Oracle Vault слегка из другой оперы). с деревьями же даже мсскл научился работать в мсскл2005.

Э, с деревьями я и в MS SQL 2000 спокойно справлялся, делов-то.
А label security читал, нужной гибкости все равно не получается (по датам). Да и денег, насколько я помню, стоит :)
29 окт 09, 18:36    [7858666]     Ответить | Цитировать Сообщить модератору
 Re: использование хранимых процедур  [new]
Yo.!
Guest
DPH3

Угу. Только Oracle так и продолжает рассчитывать на 4GL, а мода то убежала в сторону 3-tier, где нужно уже не это, а нормальные драйвера :) Про что я, собственно, и говорю.

субд нужна нормальная, а не архаизм с драйверами ;)

DPH3
Правда, чем 4GL лучше, нежели универсальные managed языки - мне тоже не понятно. Чем plain C - более менее понимаю, да.

дорого сопровождать. managed языки оторваны от субд, 4GL же может отслеживать поломаные DDLом процедуры, ну и ресурсы/скорострельность интереснее гораздо.

DPH3
Как я понял, в любом случае разницы между sql/pl и java - нет (для DB2).

есть sql/pl работает как not fenced, т.е. в ядре db2, вне адресного пространства, как и любой пхп например. просто для пхп нет препроцессора, а для жабы выкатили.
29 окт 09, 18:49    [7858698]     Ответить | Цитировать Сообщить модератору
 Re: использование хранимых процедур  [new]
Yo.!
Guest
"т.е. в ядре db2, вне адресного пространства"
следует читать как
т.е. в ядре db2, жаба же работает вне адресного пространства
29 окт 09, 18:50    [7858707]     Ответить | Цитировать Сообщить модератору
 Re: использование хранимых процедур  [new]
Yo.!
Guest
DPH3

А label security читал, нужной гибкости все равно не получается (по датам). Да и денег, насколько я помню, стоит :)

с датами то чего проще ? параметризованый вью - дешевого и сердито
29 окт 09, 18:56    [7858720]     Ответить | Цитировать Сообщить модератору
 Re: использование хранимых процедур  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
ЛП

Рулить доступом к объектам на клиенте я могу любым удобным мне способом. Любым. Удобным. Мне.
Чего нельзя сказать про управление доступом к хранимкам и прочим объектам на сервере БД.

А можно более подробно, что в вашем понимании есть "клиент" и что есть "рулить доступом"?
Потому как я не понимаю - каким это образом можно "рулить доступом с клиента".
29 окт 09, 20:00    [7858960]     Ответить | Цитировать Сообщить модератору
 Re: использование хранимых процедур  [new]
ЛП
Guest
2 locky
А можно более подробно, что в вашем понимании есть "клиент"

В контексте предыдущего обсуждения "клиент БД" = "средний слой многозвенки"
Доступ, соответственно, к объектам этого же самого среднего слоя (до объектов БД конечного пользователя никто и не допустит в обход среднего слоя).
29 окт 09, 20:07    [7858977]     Ответить | Цитировать Сообщить модератору
 Re: использование хранимых процедур  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
ЛП
Обеспечение целостности и непротиворечивости данных - так оно вообще не с помощью ХП делаться должно. Нормализация, констрейнты - да, упрощает обеспечение целостности и непротиворечивости. Обеспечивать целостность хранимками - нет, не упрощает, только усложняет.


Если Вы про Domain, Entity и прочая, то да, это делается декларативным способом, но существует еще ограничения бизнес-логики, например, клиент не может оформить заказ на условиях предоплаты на сумму более 5 000 руб, если у него еще нет выполненных заказов на условиях предоплаты на общую сумму не менее 25 000 руб.

ЛП
Причем если обеспечивать целостность SQL-кодом, то нет разницы, где этот код расположен, в хранимке на сервере, или в теле программы в одном единственном клиенте (ака средний слой).


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

ЛП
Те же самые соображения в ответ на аргумент "разделение доступа к объектам". Что рулить доступом к объектам на одном единственном сервере, что рулить доступом к объектам на одном единственном клиенте - нет разницы.


А почему он у Вас "один единственный"?! Чем это гарантируется, или, наконец, что может помешать подключиться к базе другим клиентом?!


ЛП
Вернее, разница есть, и она не в пользу хранимок.


Заблуждаетесь, IMHO.

ЛП
Рулить доступом к объектам на клиенте я могу любым удобным мне способом. Любым. Удобным. Мне.


Опять, 25. Но это не значит, что не любимый и не удобный лично Вам способ не существует и дает целый ряд преимуществ.

ЛП
Чего нельзя сказать про управление доступом к хранимкам и прочим объектам на сервере БД.


Безусловно, этого нельзя сказать, если не знаешь, как это делается. ;) Ибо реализация ACL (включая row & cell level security) на стороне реляционной СУБД делается не просто предоставлением (или не предоставление) доступа к тому или иному модулю с кодом в бд, а чуть сложнее.
29 окт 09, 20:08    [7858979]     Ответить | Цитировать Сообщить модератору
 Re: использование хранимых процедур  [new]
ЛП
Guest
2 pkarklin
Если Вы про Domain, Entity и прочая, то да, это делается декларативным способом, но существует еще ограничения бизнес-логики, например, клиент не может оформить заказ на условиях предоплаты на сумму более 5 000 руб, если у него еще нет выполненных заказов на условиях предоплаты на общую сумму не менее 25 000 руб.

Не спорю.
И такие ограничения бизнес-логики можно придумать, что реализовывать их на T-SQL - весьма тоскливое занятие. Одна из причин для "посмотреть в сторону многозвенок". Или какого-нибудь унылого говна с офигенно развитым внедренным в СУБД супер-мега-пл-т-эскюэль

Есть, и принципиальная. Система, в которой прямой доступ к таблицам закрыт, а вся работа организована через вьюхи и хп является самодостаточно устойчивой (про права админа не будем, ибо против лома нет приема). А в Вашей схеме, если код, обеспечивающий целостность данных, расположен в одном клиенте, то другой клиент, не содержащий такого кода, подключившись к бд может привести ее в неконсистентное состояние.

Товарисч pkarklin, Вы вообще как, внимательно сообщения читаете, прежде чем на них отвечать берётесь?
Какой такой другой клиент, если русским по белому и неоднократно сказано, что клиент для БД - один единственный?

А почему он у Вас "один единственный"?!

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

Чем это гарантируется, или, наконец, что может помешать подключиться к базе другим клиентом?!

Вам подсказать способы, как не дать другим подключиться, или сами додумаетесь?
Думаю, что сами справитесь. Я в Вас верю.

Опять, 25. Но это не значит, что не любимый и не удобный лично Вам способ не существует и дает целый ряд преимуществ.

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

Безусловно, этого нельзя сказать, если не знаешь, как это делается. ;) Ибо реализация ACL (включая row & cell level security) на стороне реляционной СУБД делается не просто предоставлением (или не предоставление) доступа к тому или иному модулю с кодом в бд, а чуть сложнее.

Это уже детали, к чему именно и какую именно секьюрити надо обеспечивать. В трехзвенке, BTW, эти детали вообще мало волнуют мозг. Чего не скажешь об.
29 окт 09, 20:30    [7859037]     Ответить | Цитировать Сообщить модератору
 Re: использование хранимых процедур  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
Как ДБА, скажу.
Любителей размазывать sql код по приложению - надо стрелять грязным тапком.

-------------------------
There’s no silver bullet!
29 окт 09, 20:33    [7859041]     Ответить | Цитировать Сообщить модератору
 Re: использование хранимых процедур  [new]
ЛП
Guest
locky
Как ДБА, скажу.
Любителей размазывать sql код по приложению - надо стрелять грязным тапком.

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

Только не думайте, что приложение перестает быть приложением только от того, что крутится в том же процессе, что и MS SQL Server (к примеру)
:)
29 окт 09, 20:46    [7859077]     Ответить | Цитировать Сообщить модератору
 Re: использование хранимых процедур  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
ЛП,

уточню.
Любителей выносить код sql за пределы SP - стрелять мокрыми тряпками.
29 окт 09, 20:51    [7859089]     Ответить | Цитировать Сообщить модератору
 Re: использование хранимых процедур  [new]
ЛП
Guest
locky
ЛП,

уточню.
Любителей выносить код sql за пределы SP - стрелять мокрыми тряпками.

Типо хп - эт не приложение вовсе, а так, насрано.
Понятно :)
29 окт 09, 20:53    [7859093]     Ответить | Цитировать Сообщить модератору
 Re: использование хранимых процедур  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
ЛП
И такие ограничения бизнес-логики можно придумать, что реализовывать их на T-SQL - весьма тоскливое занятие.


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

ЛП
Одна из причин для "посмотреть в сторону многозвенок".


Чур, меня, чур...

ЛП
Товарисч pkarklin, Вы вообще как, внимательно сообщения читаете, прежде чем на них отвечать берётесь?
Какой такой другой клиент, если русским по белому и неоднократно сказано, что клиент для БД - один единственный?

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


Не надо меня возить мордой по столу по топику. Это не Вы ли продекларировали:

ЛП
В случае, если у СУБД ровно один клиент (а это именно случай многозвенных приложений) - Ваше высказывание неверно по всем пунктам (по некоторым пунктам оно неверно и в случае многих клиентов)


Будем снова перетирать про быстродействие и удобство сопровождения, раз уж Вы упомянули только про некоторые пункты?!

ЛП
Вам подсказать способы, как не дать другим подключиться, или сами додумаетесь?
Думаю, что сами справитесь. Я в Вас верю.


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

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


Вас?! Да упаси Господи Вас в чем то убеждать. Влез в этот тред тока с целью предостеречь неокрепшие умы читающих его от апологетов "логики на клиенте" (фокспро\аксесс форева!!!).

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


Простите, кто на ком стоял?! ((с) п. Преображенский) Т.е. что Вам не подходит и для какой, собственно, задачи?

ЛП
Это уже детали, к чему именно и какую именно секьюрити надо обеспечивать. В трехзвенке, BTW, эти детали вообще мало волнуют мозг. Чего не скажешь об.


Это пять!!! "Детали" идут лесом!!! Трехзвенка все делает без "деталей", т.е. без мозга. Видел я результаты такой безмозговой деятельности.
29 окт 09, 20:56    [7859103]     Ответить | Цитировать Сообщить модератору
 Re: использование хранимых процедур  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
ЛП
Правильно.
Любителей размазывать логику по приложениям (кусок кода в СУБД, кусок кода где-то еще, в WCF-сервисе каком-нибудь) - стрелять двумя грязными тапками, и контрольный выстрел нестиранными трусами.


Гм... Вы так делаете?! Кмк, мы тут перетирали про код на клиенте или в хп, а не и.

ЛП
Только не думайте, что приложение перестает быть приложением только от того, что крутится в том же процессе, что и MS SQL Server (к примеру)
:)


Поддержу Вас в Вашем демогагическом начинании, а программа на ASM - это приложение для процессора, а процессор - приложение для материнской платы и т.д. и т.п. Самим Вам не смешно?!
29 окт 09, 21:06    [7859112]     Ответить | Цитировать Сообщить модератору
 Re: использование хранимых процедур  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
ЛП
locky
ЛП,

уточню.
Любителей выносить код sql за пределы SP - стрелять мокрыми тряпками.

Типо хп - эт не приложение вовсе, а так, насрано.
Понятно :)

Нет, это типа мне очень не нравится рыскать по стопиццоттысяч разным шарповским модулям, пытаясь выяснить где какой sql код есть, что он делает, где возможны проблемы, где точки входа и модификации и т.д.
В то же время в случае использования только SP я имею проблемы только с dsql
29 окт 09, 21:09    [7859116]     Ответить | Цитировать Сообщить модератору
 Re: использование хранимых процедур  [new]
ЛП
Guest
2 pkarklin
А то как насмотришься, как некоторые на апп. сервере и джоинить пытаются и прочая, получив плоские наборы с сервера СУБД, дабы реализовать ТАМ ограничения целостности или секьюрность, то волосы дыбом встают.

Угу. А как посмотришь на курсорные трактора внутре хранимок - что дыбом должно вставать?
Оно канешн на каком-нибудь расширении SQL, и аж внутре хранимки лежит, и за это этому унылому говну можно простить его внешний вид :)

Не надо меня возить мордой по столу по топику.

Надо. Если Вы с первого раза не понимаете, то как еще.

Это не Вы ли продекларировали:

Я. Какое-то слово непонятно?

Будем снова перетирать про быстродействие и удобство сопровождения, раз уж Вы упомянули только про некоторые пункты?!

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

Влез в этот тред тока с целью предостеречь неокрепшие умы читающих его от апологетов "логики на клиенте" (фокспро\аксесс форева!!!).

Вы дурак, простите?
Где Вы увидели фокспро/аксес?
Вам что-то приглючилось, и Вы решили предостеречь неокрепшие умы от Ваших собственных глюков?
Когда протрезвеете - приходите, может удастся пообщаться.

Вы так делаете?! Кмк, мы тут перетирали про код на клиенте или в хп, а не и.

Нет. Так делают (собираются делать) некоторые другие участники этого обсуждения.

Поддержу Вас в Вашем демогагическом начинании, а программа на ASM - это приложение для процессора, а процессор - приложение для материнской платы и т.д. и т.п. Самим Вам не смешно?!

Не, не смешно.
За размазывание логики про приложению на АСМе - тоже стрелять тапком.
Я серьезен как никогда. Демагогии - ноль.
Когда-нибудь поймете. Как протрезвеете.
29 окт 09, 21:14    [7859130]     Ответить | Цитировать Сообщить модератору
 Re: использование хранимых процедур  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
2 ЛП.

Думаю, что в этом вопросе, Вам следует идти до конца.
29 окт 09, 21:18    [7859140]     Ответить | Цитировать Сообщить модератору
 Re: использование хранимых процедур  [new]
barrabas
Member

Откуда: от махмуда
Сообщений: 10528
ЛП
Нет. Так делают (собираются делать) некоторые другие участники этого обсуждения.
.

ну ну, по моему кто то никак не поймет, что логику работу с данными размазывать никто не собирается, зачем?, это как раз произойдет если вынести её на среднее звено, а тут окажется что нужен триггер или джоб. А если есть задачи которые к базе отношения не имеют и к клиенту тоже, то где же ей находится как не на другом слое, раз в в базе и на клиенте ей делать нечего и это не повод выносить туда всё остальное, т.к. с базой может работать еще и другой клиент или сервис
29 окт 09, 21:24    [7859146]     Ответить | Цитировать Сообщить модератору
 Re: использование хранимых процедур  [new]
ЛП
Guest
2 barrabas
это как раз произойдет если вынести её на среднее звено, а тут окажется что нужен триггер или джоб.

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

А если есть задачи которые к базе отношения не имеют и к клиенту тоже

О, это вообще не сюда - что-то ни к чему не относящееся. Ему ни хранимки не помогут, ни отсутствие хранимок не помешает. Программирование фотошопа этажом выше.

раз в в базе и на клиенте ей делать нечего и это не повод

Это не повод называть это нечто средним слоем.
Не называйте это "ни к чему не относящееся" средним слоем - и ни малейших возражений не получите на свои высказывания. Правда невелика будет и ценность этих высказываний в контексте обсуждения "хранимок в трехзвенке"
29 окт 09, 21:39    [7859168]     Ответить | Цитировать Сообщить модератору
 Re: использование хранимых процедур  [new]
barrabas
Member

Откуда: от махмуда
Сообщений: 10528
ЛП
2 barrabas
это как раз произойдет если вынести её на среднее звено, а тут окажется что нужен триггер или джоб.

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

А если есть задачи которые к базе отношения не имеют и к клиенту тоже

О, это вообще не сюда - что-то ни к чему не относящееся. Ему ни хранимки не помогут, ни отсутствие хранимок не помешает. Программирование фотошопа этажом выше.

раз в в базе и на клиенте ей делать нечего и это не повод

Это не повод называть это нечто средним слоем.
Не называйте это "ни к чему не относящееся" средним слоем - и ни малейших возражений не получите на свои высказывания. Правда невелика будет и ценность этих высказываний в контексте обсуждения "хранимок в трехзвенке"

клиентское приложение коннектится к сервису, ни о базе и о чем другом ему знать не нужно, сервис, в свою очередь, откликаясь на запросы клиента, стучится к нескольким базам (ну скажем для сверки данных в разных ИС) и выдает что нужно клиенту, тут же нужно разослать отчеты клиентам, данные получаем с СУБД, а формируются файлы нужного формата на среднем слое - сервисе, каждый занят своим делом, никакой проблемы с размазываем логики, ни какой проблемы для ДБА.
Я вижу смысл в трехзвенке если не нужно "светить" базу в инете, при работе с несколькими базами, но просто так чтобы было, типа чтобы ХП не писать, а писать классы в еще одном проекте, не вижу смысла.
29 окт 09, 22:01    [7859216]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 [6] 7 8 9 10 .. 14   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить