Здравствуйте, <Аноним>, Вы писали:
А>Не могу выбрать: А> 1 делать логику на уровне БД хранимками PL/SQL А> 1 вынести логику из базы
А>какие за и против по поводу обоих вариантов?
А нет ни "за", ни "против". Надо смотреть по ситуации. И всегда оставлять логику СУБД — самой СУБД, а логику приложения — приложению. Универсального совета, я думаю, не существует. Так что, ты хоть примерно опиши предметную область задачи, саму задачу... Вот тогда и можно будет что-то советовать.
С годами я делаюсь все менее терпимым к людям неумным и неумеющим работать свое дело очень хорошо. (с) М. Веллер
Здравствуйте, Аноним, Вы писали:
А>Не могу выбрать: А> 1 делать логику на уровне БД хранимками PL/SQL А> 1 вынести логику из базы
А>какие за и против по поводу обоих вариантов?
Я всегда придерживаюсь следующего правила:
1. Логика реализуется на уровне БД.
2. Только когда сложно или невозможно реализовать логику на уровне
БД, вынести логику из базы.
Первый вариант имеет следующие преимущества:
— В хранимых процедурах напрямую использовать SQL, уровень которого выше, чем
у процедурного языка программирования
— Многие бизнес-правила на уровне БД реализуются декларативно
средствами БД (такими, например, как CHECK CONSTRAINT или
FOREIGN KEY) или при помощи триггеров
— Код находится ближе к данным, что облегает отладку, тестирование и
сопровождение программы
Этот же вариант имеет и недостатки:
— Скорость работы хранимых процедур может быть недостаточной
— Логика может быть сложной настолько, что ее становится трудно
реализовать при помощи хранимых процедур (хотя PL-SQL,
в общем-то, достаточно можный язык)
Какой подход лучше использовать, зависит от конкретного проекта.
Здравствуйте, Аноним, Вы писали:
А>Не могу выбрать: А> 1 делать логику на уровне БД хранимками PL/SQL А> 1 вынести логику из базы А>какие за и против по поводу обоих вариантов?
Слабому Серверу Толстый клиент и наоборот.
В то же время, если логика будет вся в БД, то создавать свои приложения можно будет по средствам различных средств разработки, а не писать заново логику одну и ту же во всех приложениях. К примеру ВинФормс и Веб приложения могут использовать одни и те же функции и процедуры с сервера. Так же контроль прав намного проще и безопаснее на уровне сервера организовывать.
Хотя для какой-то разовой работы можно и всю логику из БД в приложение вынести. Разрабатывать такое попроще, если язык БД знаете хуже чем приложения.
Здравствуйте, Flying Dutchman, Вы писали:
FD>Первый вариант имеет следующие преимущества: FD>- Многие бизнес-правила на уровне БД реализуются декларативно FD> средствами БД (такими, например, как CHECK CONSTRAINT или FD> FOREIGN KEY) или при помощи триггеров
Вот из этой цитаты я понял, что ты не совсем четко представляешь, что именно должно кодироваться в программе, а что именно в SQL.
Здравствуйте, Mika Soukhov, Вы писали:
MS>Здравствуйте, Flying Dutchman, Вы писали:
FD>>Первый вариант имеет следующие преимущества: FD>>- Многие бизнес-правила на уровне БД реализуются декларативно FD>> средствами БД (такими, например, как CHECK CONSTRAINT или FD>> FOREIGN KEY) или при помощи триггеров
MS>Вот из этой цитаты я понял, что ты не совсем четко представляешь, что именно должно кодироваться в программе, а что именно в SQL.
И что же, по-твоему, должно кодироваться в программе, а что в SQL ?
Здравствуйте, Flying Dutchman, Вы писали:
MS>>Вот из этой цитаты я понял, что ты не совсем четко представляешь, что именно должно кодироваться в программе, а что именно в SQL. FD>И что же, по-твоему, должно кодироваться в программе, а что в SQL ?
В SQL — работа с данными. Логику в хранимых процедурах поддерживать сложно и неудобно. Там должно быть только то, что не имеет смысла делать в прикладном коде: создание данных для отчетов, еще может быть проверка политик безопасности и т.п.
Средства поддержки целостности БД еще прекрасно работают в качестве "последнего рубежа" в борьбе с ошибками. То есть, в хорошей программе нарушения констрейнтов — ошибочная ситуация, которой не должно быть (хотя могут быть какие-то частные случаи). Но уж если ошибка случилась — то БД хоть не даст испортить данные.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Flying Dutchman, Вы писали:
MS>>>Вот из этой цитаты я понял, что ты не совсем четко представляешь, что именно должно кодироваться в программе, а что именно в SQL. FD>>И что же, по-твоему, должно кодироваться в программе, а что в SQL ? C>В SQL — работа с данными. Логику в хранимых процедурах поддерживать сложно и неудобно.
Почему же "сложно и неудобно" ? По опыту своих проектов могу сказать, что
большую часть логики удобно реализовать в хранимых процедурах,
тем более что логика
Даже на таком, в общем-то, примитивном языке, как Transact-SQL.
Не говоря уже о PL-SQL, который представляет собой полноценный (почти) язык
программирования.
Другое дело, что работа с данными должна быть по возможности отделена от логики, т.е. должна
быть реализована в других хранимых процедурах.
С>Там должно быть только то, что не имеет смысла делать в прикладном коде: создание данных для отчетов, еще может быть проверка политик безопасности и т.п.
Я бы сказал по-другому — в прикладном коде должно быть только то, что сложно или не имеет смысла
реализовать в хранимых процедурах.
Здравствуйте, Flying Dutchman, Вы писали:
FD>Здравствуйте, Mika Soukhov, Вы писали:
MS>>Здравствуйте, Flying Dutchman, Вы писали:
FD>>>Первый вариант имеет следующие преимущества: FD>>>- Многие бизнес-правила на уровне БД реализуются декларативно FD>>> средствами БД (такими, например, как CHECK CONSTRAINT или FD>>> FOREIGN KEY) или при помощи триггеров
MS>>Вот из этой цитаты я понял, что ты не совсем четко представляешь, что именно должно кодироваться в программе, а что именно в SQL.
FD>И что же, по-твоему, должно кодироваться в программе, а что в SQL ?
Бизнес-правила — это: послать уведомление о подтверждении заказа; сделать скидку X если сумма превысила Y; удалить товар, если заказ не подтвердился в течении времени Z. Foreign Key, Primary Key, Constraints — это системный уровень. К бизнесу он никакого отношения не имеет (если, конечно, у вас бизнес не построен на создании СУБД).
Собственно, из твоего сообщения, я считаю правильным только вот это:
— Логика может быть сложной настолько, что ее становится трудно
реализовать при помощи хранимых процедур (хотя PL-SQL,
в общем-то, достаточно можный язык)
Все остальное или неверно, или спорно (aka зависит от задача).
Здравствуйте, Аноним, Вы писали:
А>Не могу выбрать: А> 1 делать логику на уровне БД хранимками PL/SQL
В этом случае можно задействовать всю мощь Oracle (pl/sql) и соответственно повысить производительность и скорость обработки запросов.
А> 1 вынести логику из базы
Если планируете разрабатывть не зависимую от СУБД систему. Т.е. СУБД только для хранения данных.
Flying Dutchman wrote: > C>В SQL — работа с данными. Логику в хранимых процедурах поддерживать > сложно и неудобно. > Почему же "сложно и неудобно" ? По опыту своих проектов могу сказать, что > большую часть логики удобно реализовать в хранимых процедурах, > тем более что логика
По моему опыту, перенос сложной логики в БД — путь к монструозным проектам.
> Даже на таком, в общем-то, примитивном языке, как Transact-SQL. > Не говоря уже о PL-SQL, который представляет собой полноценный (почти) язык > программирования.
Ага. И при использовании такого подхода — получить мучения с системами
контроля версий, совместной работой и т.п.
Я уж не говорю про крайнюю убогость языка по сравнению даже с обычным C#.
> Другое дело, что работа с данными должна быть по возможности отделена от > логики, т.е. должна > быть реализована в других хранимых процедурах.
А это вообще приводит к бреду.
> С>Там должно быть только то, что не имеет смысла делать в прикладном > коде: создание данных для отчетов, еще может быть проверка политик > безопасности и т.п. > Я бы сказал по-другому — в прикладном коде должно быть только то, что > сложно или не имеет смысла реализовать в хранимых процедурах.
То бишь, почти все.
Здравствуйте, Cyberax, Вы писали:
C>В SQL — работа с данными. Логику в хранимых процедурах поддерживать сложно и неудобно...
Гм... Логика — это ни есть работа с данными? Например, увеличение остатка после оприходования товара?
C>Средства поддержки целостности БД еще прекрасно работают в качестве "последнего рубежа" в борьбе с ошибками. То есть, в хорошей программе нарушения констрейнтов — ошибочная ситуация, которой не должно быть (хотя могут быть какие-то частные случаи). Но уж если ошибка случилась — то БД хоть не даст испортить данные.
Безусловно. И теперь, следуя Вашей мысли, проверять на предмет "ошибки" тоже стоит не на стороне бд, например, на нарушение того или иного ограничения на логику обработки данных?
Здравствуйте, Cyberax, Вы писали:
C>По моему опыту, перенос сложной логики в БД — путь к монструозным проектам.
Т.е. реализация бизнес-логики в "другом месте" не приведет к монструозности? Аргументы?
C>Ага. И при использовании такого подхода — получить мучения с системами C>контроля версий, совместной работой и т.п.
Гм... И какие проблемы с контролем версий и совместной работой при разработке логики на сервере, например, на T-SQL?
C>Я уж не говорю про крайнюю убогость языка по сравнению даже с обычным C#.
По меньшей мере странно обрабатывать данные в реляционным хранилище языком, не предназначенном для этого.
Здравствуйте, pkarklin, Вы писали:
C>>В SQL — работа с данными. Логику в хранимых процедурах поддерживать сложно и неудобно... P>Гм... Логика — это ни есть работа с данными? Например, увеличение остатка после оприходования товара?
Ага, именно. Такие действия надо как можно дальше из БД выносить.
Потому как потом захочется еще при изменении, например, посылать письма или обновлять Excel-отчет в Sharepoint-сервере. Я видел монстров на TSQL, где формировался CSV и HTML в хранимых процедурах, куда шло обращение из ISAPI-фильтров.
C>>Средства поддержки целостности БД еще прекрасно работают в качестве "последнего рубежа" в борьбе с ошибками. То есть, в хорошей программе нарушения констрейнтов — ошибочная ситуация, которой не должно быть (хотя могут быть какие-то частные случаи). Но уж если ошибка случилась — то БД хоть не даст испортить данные. P>Безусловно. И теперь, следуя Вашей мысли, проверять на предмет "ошибки" тоже стоит не на стороне бд, например, на нарушение того или иного ограничения на логику обработки данных?
Именно. Как пример — в форме ввода disable'ить кнопку 'OK' пока не введут все нужные поля.
Проверки и констрейнты в БД нужно использовать, причем чем больше — тем лучше. Но только как дополнительную защитную фичу. Естественно, при правильном подходе констрейнты и проверки можно декларативно задавать в одном месте.
Здравствуйте, Cyberax, Вы писали:
P>>Гм... Логика — это ни есть работа с данными? Например, увеличение остатка после оприходования товара? C>Ага, именно. Такие действия надо как можно дальше из БД выносить.
Гм... Выносить вкуда? На апп.сервер? Который в конце концов сгенерит инструкцию типа
UPDATE
AccountSaldo
SET
Saldo = Saldo + @SomeValue
WHERE
AccountID = @SomeID AND
Period = @SomePeriod
Зачем мне еще что-то где-то на чем-то еще программировать, если в конечном результате я все равно проапдэйчу поле в одной записи? Зачем мне для этого апп.сервер, написанный на C?
C>Потому как потом захочется еще при изменении, например, посылать письма или обновлять Excel-отчет в Sharepoint-сервере. Я видел монстров на TSQL, где формировался CSV и HTML в хранимых процедурах, куда шло обращение из ISAPI-фильтров.
Нивапрос. Если СУБД предоставляет мне такие возможности (sp_send_dbmail, или linked servers, или DTS), то зачем мне еще где-то городить дополнительные городушки, которые еще будут неизвестно как работать?
P>>Безусловно. И теперь, следуя Вашей мысли, проверять на предмет "ошибки" тоже стоит не на стороне бд, например, на нарушение того или иного ограничения на логику обработки данных? C>Именно. Как пример — в форме ввода disable'ить кнопку 'OK' пока не введут все нужные поля.
Вот как раз "визуализация" ограничений в клиентском приложении есть дополнительная (но не обязательная) функциональность к:
1. соответствующим проверкам в коде бизнес-логики:
IF @ReceiverAccount IS NULL EXEC dbo.Abort 'Не указан счет получателя!'
0. И декларативным ограничениям. NOT NULL для поля
Здравствуйте, pkarklin, Вы писали:
C>>По моему опыту, перенос сложной логики в БД — путь к монструозным проектам. P>Т.е. реализация бизнес-логики в "другом месте" не приведет к монструозности? Аргументы?
Нормальные языки имеют нааамного больше средств для борьбы со сложностью, чем языки хранимых процедур (возможность юнит-тестирования, ООП всякое и т.п.)
C>>Ага. И при использовании такого подхода — получить мучения с системами C>>контроля версий, совместной работой и т.п. P>Гм... И какие проблемы с контролем версий и совместной работой при разработке логики на сервере, например, на T-SQL?
Покажи мне как нормально положить хранимые процедуры в SVN? Кроме того, очень часто девелоперам приходится работать на одном сервере (так как поставить себе на личные компьютеры полную базу данных часто нереально). В случае, когда логика от базы отделена — часто можно использовать центральную базу, к которой будут цепляться серверы на личных компьютерах.
C>>Я уж не говорю про крайнюю убогость языка по сравнению даже с обычным C#. P>По меньшей мере странно обрабатывать данные в реляционным хранилище языком, не предназначенном для этого.
По меньшей мере странно использовать хранилище для обработки данных.
Здравствуйте, Cyberax, Вы писали:
C>Flying Dutchman wrote: >> C>В SQL — работа с данными. Логику в хранимых процедурах поддерживать >> сложно и неудобно. >> Почему же "сложно и неудобно" ? По опыту своих проектов могу сказать, что >> большую часть логики удобно реализовать в хранимых процедурах, >> тем более что логика C>По моему опыту, перенос сложной логики в БД — путь к монструозным проектам.
По моему опыту — наоборот. Чтобы не быть голословным, приведу примеры
некоторых проектов, в которых я принимал участие.
1. Банковская система.
Реализована на Oracle, > 150 таблиц
Вся логика реализована в хранимых процедурах на PL/SQL (кроме экспорта данных
в другую систему), включая генерацию отчетов (это оказалось удобнее,
чем использовать Oracle Reports).
2. Система для хранения конструкторской информации и заказов для
фабрики по производству кранов. Реализована на SQL Server 2000, около 60
таблиц. Вся логика реализована на Transact SQL (несколько тысяч строк).
3. ERP-система для компаний, предоставляющих персонал внаем. Функции отдела кадров,
учеты проектов, расчета зарплаты и др. Реализована на SQL Server 2000, > 300 таблиц,
сотни хранимых процедур. Большая часть (почти вся) логики реализована на
Transact SQL, в частности, расчет зарплаты — полностью. На С# была организована
генерация отчетов в XML-формате, да и то я только потому, что я не знал тогда всех возможностей
Transact SQL. Сейчас я сделал бы это в хранимых процедурах.
4. Система автоматизации документооборота для полиции. SQL Server 2000, около 60 таблиц.
Около 80% логики (а может, и больше) в хранимых процедурах. Довольно сложная система
workflow и прав доступа. Были проблемы с некоторыми ХП из-за
низкой производительности. Некоторые ХП были очень большими и сложными, но на C#
это было бы еще больше и сложнее.
С другой стороны, знакомый участвовал в проекте автоматизации нефтеперегонного завода.
Все было также реализовано на Transact SQL, но у них были проблемы и со сложностью,
и с производительностью. Было много работы с массивами, которые моделировались
при помощи таблиц и обрабатывались при помощи курсоров, что приводило к большому замедлению.
Общий вывод — для большинства проектов лучше реализовавать логику в базе данных.
Для меньшей части проектов — в клиентском приложении.
>> Даже на таком, в общем-то, примитивном языке, как Transact-SQL. >> Не говоря уже о PL-SQL, который представляет собой полноценный (почти) язык >> программирования. C>Ага. И при использовании такого подхода — получить мучения с системами C>контроля версий, совместной работой и т.п.
И какие же проблемы могут быть с системами контроля версий ? Если поступать
правильно, то есть хранить хранимые процедуры в файле, а файл в системе
контроля версий, то никаких проблем не будет. Если же создавать и редактировать
хранимые процедуры прямо на сервере — то да, будут проблемы.
C>Я уж не говорю про крайнюю убогость языка по сравнению даже с обычным C#.
Ну, не убогость, а ограниченность для процедурных задач. Но этот недостаток
с лихвой компенсируется удобством использования SQL для работы с данными.
И то эта ограниченность свойственна, например, Transact SQL, а PL-SQL
уже полнофункциональный язык программирования.
>> Другое дело, что работа с данными должна быть по возможности отделена от >> логики, т.е. должна >> быть реализована в других хранимых процедурах. C>А это вообще приводит к бреду.
К чему приводит ??? Описанная практика это вообще best practice в
мире Oracle (за подробностями отсылаю к статьям Люкаса Йеллема The best of both worlds. Cross-breeding Java and PL/SQL и
Стива Ферстайна Cleaning Up PL/SQL Practices).
>> Я бы сказал по-другому — в прикладном коде должно быть только то, что >> сложно или не имеет смысла реализовать в хранимых процедурах. C>То бишь, почти все.
Ну, в общем-то, да. Работая в Oracle, вполне можно этого добиться для многих проектов.
Да и у SQL Server 2005 есть много возможностей. Можно, например, писать хранимые процедуры на C#.
Здравствуйте, pkarklin, Вы писали:
P>>>Гм... Логика — это ни есть работа с данными? Например, увеличение остатка после оприходования товара? C>>Ага, именно. Такие действия надо как можно дальше из БД выносить. P>Гм... Выносить вкуда? На апп.сервер? Который в конце концов сгенерит инструкцию типа
Именно.
P>Зачем мне еще что-то где-то на чем-то еще программировать, если в конечном результате я все равно проапдэйчу поле в одной записи? Зачем мне для этого апп.сервер, написанный на C?
А если потребуется перед измененим сальдо сначала направить счета на подтверждение к координинатору?
C>>Потому как потом захочется еще при изменении, например, посылать письма или обновлять Excel-отчет в Sharepoint-сервере. Я видел монстров на TSQL, где формировался CSV и HTML в хранимых процедурах, куда шло обращение из ISAPI-фильтров. P>Нивапрос. Если СУБД предоставляет мне такие возможности (sp_send_dbmail, или linked servers, или DTS), то зачем мне еще где-то городить дополнительные городушки, которые еще будут неизвестно как работать?
А письмо как формировать будем? Конкатенацией строк? А я могу мой любимый Velocity использовать в качестве темплейтного движка? А может MVEL? А как насчет использования LDAP для взятия почтового адреса пользователя?
Ты будешь лепить интерфейсы к базе?
P>>>Безусловно. И теперь, следуя Вашей мысли, проверять на предмет "ошибки" тоже стоит не на стороне бд, например, на нарушение того или иного ограничения на логику обработки данных? C>>Именно. Как пример — в форме ввода disable'ить кнопку 'OK' пока не введут все нужные поля. P>Вот как раз "визуализация" ограничений в клиентском приложении есть дополнительная (но не обязательная) функциональность к:
Нет. Эта функциональность для _нормальных_ приложений обязательна. Люди очень плохо реагируют на ошибки типа "Constraint filed_cannot_be_null violation. Transaction rolled back".
P>
P>IF @ReceiverAccount IS NULL EXEC dbo.Abort 'Не указан счет получателя!'
P>
P>0. И декларативным ограничениям. NOT NULL для поля
А у меня это все описано вот примерно так:
class Something
{
@Validate(notNull=true, messageKey="account.cant.be.null")
void setAccount(Account account);
}
"account.cant.be.null" — это локализуемый ресурс, будет определен примерно так: "ru.account.cant.be.null=Не указан счет получателя для ${that.name}!".
Да, и при этом система байндинга автоматически будет подкрашивать поле красным цветом при ошибке, дизэйблить кнопку 'OK' и т.п.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, pkarklin, Вы писали:
C>>>По моему опыту, перенос сложной логики в БД — путь к монструозным проектам. P>>Т.е. реализация бизнес-логики в "другом месте" не приведет к монструозности? Аргументы? C>Нормальные языки имеют нааамного больше средств для борьбы со сложностью, чем языки хранимых процедур (возможность юнит-тестирования, ООП всякое и т.п.)
Зато языки хранимых процедур обладают большими возможностями для работы с реляционными данными.
Это преимущество перевешивает их недостатки (например, отсутствие ООП).
Юнит-тестирование для баз данных существует. Для Oracle есть пакет utPLSQL, для
тестирования хранимых процедур SQL Server я использую NUnit и пишу тестовые программы на C#.
P>>Гм... И какие проблемы с контролем версий и совместной работой при разработке логики на сервере, например, на T-SQL? C>Покажи мне как нормально положить хранимые процедуры в SVN? Кроме того, очень часто девелоперам приходится работать на одном сервере (так как поставить себе на личные компьютеры полную базу данных часто нереально). В случае, когда логика от базы отделена — часто можно использовать центральную базу, к которой будут цепляться серверы на личных компьютерах.
Можно хранить хранимые процедуры в текстовом файле, а текстовый файл в SVN.
C>>>Я уж не говорю про крайнюю убогость языка по сравнению даже с обычным C#. P>>По меньшей мере странно обрабатывать данные в реляционным хранилище языком, не предназначенном для этого. C>По меньшей мере странно использовать хранилище для обработки данных.
База данных — это не просто хранилище данных, а хранилище данных + хранилище бизнес-правил + устройство обработки данных.
Flying Dutchman wrote: > C>Нормальные языки имеют нааамного больше средств для борьбы со > сложностью, чем языки хранимых процедур (возможность юнит-тестирования, > ООП всякое и т.п.) > Зато языки хранимых процедур обладают большими возможностями для работы > с реляционными данными.
Работа с реляционными данными в большинстве случаев сводится к "сделать
запрос". Это прекрасно можно сделать без хранимых процедур. А тут еще и
LINQ подкатывает, который сведет на нет большую часть "преимуществ" БД.
Ну и я не говорю про ORM.
> Это преимущество перевешивает их недостатки (например, отсутствие ООП).
Не перевешивает в большинстве случаев.
> Юнит-тестирование для баз данных существует. Для Oracle есть пакет > utPLSQL, для > тестирования хранимых процедур SQL Server я использую NUnit и пишу > тестовые программы на C#.
И как мне использовать моки, например?
> Можно хранить хранимые процедуры в текстовом файле, а текстовый файл в SVN.
Угу. Пробовали. В одном файле их хранить нельзя — пойдут сплошные
конфликты. А разбивать на файлы не так-то просто.
> P>>По меньшей мере странно обрабатывать данные в реляционным хранилище > языком, не предназначенном для этого. > C>По меньшей мере странно использовать *хранилище* для обработки данных. > База данных — это не просто хранилище данных, а хранилище данных + > хранилище бизнес-правил + устройство обработки данных.
Нет. База данных — это именно хранилище, на которое многие пытаются
навернуть того, что там не должно быть.
Flying Dutchman wrote: > C>По моему опыту, перенос сложной логики в БД — путь к монструозным > По моему опыту — наоборот. Чтобы не быть голословным, приведу примеры > некоторых проектов, в которых я принимал участие.
Мой опыт работы с приложениями:
1. База данных для автоматизации предприятия — около 1500 таблиц на
Oracle, интегрируем с нашей системой. Жуть. Рефакторингу не поддается
из-за того, что нет нормальных инструментов и огромного объемы.
2. У соседей — сравнительно небольшой проект. Сначала такой же крутой
DBA заставлял все делать в хранимых процедурах на MSSQL. В результате
поимели кучу проблем с версированием. В итоге люди выбросили это все
нафиг и стали использовать NHibernate.
3. Мой текущий проект — первая версия была написана в лучше оракловом
стиле, с row level security, странными политиками безопасности и
непонятными хранимыми процедурами для workflow и бизнес-правил.
Переписали на Hibernate + трехзвенка, для бизнес-правил взяли drools,
для workflow — JBoss jBPM. Сейчас бизнес-консултанты добавляют в неделю
по десятку правил для разных клиентов.
Нет, я видел успешные проекты на Oracle — в котором люди работали над
кодом через Remote Desktop, так как других вариантов просто не было. Но
я бы такой проект писать не стал.
> C>Ага. И при использовании такого подхода — получить мучения с системами > C>контроля версий, совместной работой и т.п. > И какие же проблемы могут быть с системами контроля версий ? Если поступать > правильно, то есть хранить хранимые процедуры в файле, а файл в системе > контроля версий, то никаких проблем не будет. Если же создавать и > редактировать хранимые процедуры прямо на сервере — то да, будут проблемы.
Про один файл я уже сказал.
> C>Я уж не говорю про крайнюю убогость языка по сравнению даже с обычным C#. > Ну, не убогость, а ограниченность для процедурных задач. Но этот недостаток > с лихвой компенсируется удобством использования SQL для работы с данными. > И то эта ограниченность свойственна, например, Transact SQL, а PL-SQL > уже полнофункциональный язык программирования.
Он нифига не полнофункциональный. Он на уровне 80-х годов, там нет
современных фич.
> C>А это вообще приводит к бреду. > К чему приводит ??? Описанная практика это вообще best practice в > мире Oracle (за подробностями отсылаю к статьям Люкаса Йеллема
В best practices меня можно не тыкать — я их уже много видел.
А отделение работы с данными от логики для организации псевдо-DAL'а
приводить только к бессмысленному увеличению объема работы.
> Ну, в общем-то, да. Работая в Oracle, вполне можно этого добиться для > многих проектов. > Да и у SQL Server 2005 есть много возможностей. Можно, например, писать > хранимые процедуры на C#.
Я работал с приложениями, построеными на Oracle. В большинстве случаев
это монстры, которые живут годами, добавляя заплатки из-за того, что
невозможно сделать нормальный рефакторинг.
Здравствуйте, Mika Soukhov, Вы писали:
MS>Бизнес-правила — это: послать уведомление о подтверждении заказа; сделать скидку X если сумма превысила Y; удалить товар, если заказ не подтвердился в течении времени Z.
MS>Foreign Key, Primary Key, Constraints — это системный уровень. К бизнесу он никакого отношения не имеет (если, конечно, у вас бизнес не построен на создании СУБД).
Здравствуйте, Cyberax, Вы писали:
C>Нормальные языки имеют нааамного больше средств для борьбы со сложностью, чем языки хранимых процедур (возможность юнит-тестирования, ООП всякое и т.п.)
А какие проблемы с юнит-тестированием серверного кода? И, простите, зачем мне ООП в реляционной СУБД?! Свят, свят, свят...
C>Покажи мне как нормально положить хранимые процедуры в SVN?
Гм... Для хранения исполнимого кода используем VSS. На раз интегрируется хоть с Management Studio, хоть с MultiEdit. Я предпочитаю последний. Модель в ервине и в том же самом VSS.
C>Кроме того, очень часто девелоперам приходится работать на одном сервере (так как поставить себе на личные компьютеры полную базу данных часто нереально).
Т.е. разделение на Production, Test & Development Environment придумали лохи?
C>В случае, когда логика от базы отделена — часто можно использовать центральную базу, к которой будут цепляться серверы на личных компьютерах.
Даешь каждому разработчику по серверу.
C>По меньшей мере странно использовать хранилище для обработки данных.
Окститесь! Современные СУБД это не просто хранилише!!! Это целый конгломерат функциональности, причем реляционный движок значимая, но не самая большая часть.
Здравствуйте, Cyberax, Вы писали:
P>>Гм... Выносить вкуда? На апп.сервер? Который в конце концов сгенерит инструкцию типа C>Именно.
C>А если потребуется перед измененим сальдо сначала направить счета на подтверждение к координинатору?
И в чем проблема?! Вы не знаете как это реализовать без апп.сервера?
C>А письмо как формировать будем? Конкатенацией строк? А я могу мой любимый Velocity использовать в качестве темплейтного движка? А может MVEL? А как насчет использования LDAP для взятия почтового адреса пользователя?
Опять наружу вылазит незнание возможностей используемой СУБД. М.б. стоит чуть больше уделить внимания их изучению? Дабы не изобретать велосипед в виде апп. сервера
C>Ты будешь лепить интерфейсы к базе?
Что то я не помню, чтоб мы с Вами выпивали на брудершафт?!
C>Нет. Эта функциональность для _нормальных_ приложений обязательна. Люди очень плохо реагируют на ошибки типа "Constraint filed_cannot_be_null violation. Transaction rolled back".
Гм... Интересно где в приведенных мной отрывках Вы увидели возможность получения клиентом такого сообщения?
C>А у меня это все описано вот примерно так: C>
C>"account.cant.be.null" — это локализуемый ресурс, будет определен примерно так: "ru.account.cant.be.null=Не указан счет получателя для ${that.name}!".
И что будет, если доступ к базе будет получен не через Ваш апп сервер?
C>Да, и при этом система байндинга автоматически будет подкрашивать поле красным цветом при ошибке, дизэйблить кнопку 'OK' и т.п.
Тот же фунционал реализуется и без "системы байндинга" как два пальца об асфальт.
Здравствуйте, Flying Dutchman, Вы писали:
FD>Здравствуйте, Cyberax, Вы писали:
C>>Flying Dutchman wrote: >>> C>В SQL — работа с данными. Логику в хранимых процедурах поддерживать >>> сложно и неудобно. >>> Почему же "сложно и неудобно" ? По опыту своих проектов могу сказать, что >>> большую часть логики удобно реализовать в хранимых процедурах, >>> тем более что логика C>>По моему опыту, перенос сложной логики в БД — путь к монструозным проектам.
FD>По моему опыту — наоборот. Чтобы не быть голословным, приведу примеры FD>некоторых проектов, в которых я принимал участие.
Сам в основном пишу логику в БД. Удобно.
Но вот наткнулся на описание Архитектуры eBay.
Судя по всему, реализовав логику на БД, они бы столкнулись с проблемой производительности.
Здравствуйте, _Oleg_, Вы писали:
_O_>Но вот наткнулся на описание _O_>Архитектуры eBay. _O_>Судя по всему, реализовав логику на БД, они бы столкнулись с проблемой производительности.
_O_>
_O_>No business logic in database:
_O_>
_O_>No store procedures
_O_>Only very simple triggers
_O_>
_O_>Move CPU-intensive work to applications:
_O_>
_O_>Joins
_O_>Sorting
_O_>...
_O_>
Зачот. Однозначно. Они на уровне applications гараздо лучше сделают Joins, Sorting ..., чем СУБД, которые именно для этого предназначены. Долго ржал...
Здравствуйте, pkarklin, Вы писали:
_O_>>Move CPU-intensive work to applications: _O_>>
_O_>>Joins _O_>>Sorting _O_>>... _O_>>_O_>>[/q]
P>Зачот. Однозначно. Они на уровне applications гараздо лучше сделают Joins, Sorting ..., чем СУБД, которые именно для этого предназначены. Долго ржал...
Судя из презентации, у них для каждого типа объектов чуть ли не свой отдельный сервер.
Сервер для аккаунтов, сервер для продаж и т.д.
Видимо Join на базе СУБД сделать и не получится.
Здравствуйте, Flying Dutchman, Вы писали:
MS>>Бизнес-правила — это: послать уведомление о подтверждении заказа; сделать скидку X если сумма превысила Y; удалить товар, если заказ не подтвердился в течении времени Z.
MS>>Foreign Key, Primary Key, Constraints — это системный уровень. К бизнесу он никакого отношения не имеет (если, конечно, у вас бизнес не построен на создании СУБД).
FD>Это широко распространенное заблуждение.
Тоесть, таких неграмотных как я много? Ну чтож, скучать не будем.
FD>На странице 12 читаем:
FD>
FD>...note that the PRIMARY KEY and FOREIGN KEY clauses correspond to business rules...
FD>(...отметим, что предложения PRIMARY KEY и FOREIGN KEY относятся к бизнес-правилам...)
Любой автоматизированные бизнес в мире (выращивание бананов и продажа оружейного плутония) объединяют как минимум три бизнес-правила
pkarklin wrote:
..., чем СУБД, которые именно для этого предназначены. > Долго ржал...
Зря смеешься. Это именно так.
Зачастую просто написать тупой императивный код, чем громоздить запросы
и работать с курсорами.
У меня примерно та же ситуация — клиенты один раз загружают с сервера
нужные данные (которые при этом чаще всего еще и во внутрипроцессном
кэше лежат), а потом уже работают с ними на локальных узлах. Так как
иначе сервер БД бы просто умер.
Flying Dutchman wrote: > Indeed, foreign key constraints in particular are an important case of > *business rules* in general. > (В самом деле, ограничение по внешнему ключу является частным случаем > *бизнес-правила*.) > Так что ограничение целостности являются бизнес-правилами.
Достаточно редко объекты в БД соответствуют 1-в-1 реальным
бизнес-объектам. Так что FKC — это один из _способов_ задавать
бизнес-правила, но не самый мощный.
pkarklin wrote: > C>Нормальные языки имеют нааамного больше средств для борьбы со > сложностью, чем языки хранимых процедур (возможность юнит-тестирования, > ООП всякое и т.п.) > А какие проблемы с юнит-тестированием серверного кода? И, простите, > зачем мне ООП в реляционной СУБД?! Свят, свят, свят...
Ну или там ФП. Или логическое программирование для правил. Ну как-бы то,
что люди начали повсеместно использовать 20 лет назад.
> C>Покажи мне как нормально положить хранимые процедуры в SVN? > Гм... Для хранения исполнимого кода используем VSS. На раз интегрируется > хоть с Management Studio, хоть с MultiEdit. Я предпочитаю последний. > Модель в ервине и в том же самом VSS.
А вот мы VSS не используем (и не будем). Нам что делать? Провайдеров SCC
API для SVN нормальных нет.
> C>Кроме того, очень часто девелоперам приходится работать на одном > сервере (так как поставить себе на личные компьютеры полную базу данных > часто нереально). > Т.е. разделение на Production, Test & Development Environment придумали > лохи?
Естественно, разработчики будут работать не на production'е. Суть в том,
что они скорее всего будут работать все на _одном_ сервере.
> C>В случае, когда логика от базы отделена — часто можно использовать > центральную базу, к которой будут цепляться серверы на личных компьютерах. > Даешь каждому разработчику по серверу.
Можно. Но дорого и неудобно — еще и проблемы с синхронизацией появятся.
> C>По меньшей мере странно использовать *хранилище* для обработки данных. > Окститесь! Современные СУБД это не просто хранилише!!! Это целый > конгломерат функциональности, причем реляционный движок значимая, но не > самая большая часть.
Вот. И эта остальная часть — по большей части сливает нормальным
системам разработки. Так как она не была изначально для этого предназначена.
Поскипано...
>> Окститесь! Современные СУБД это не просто хранилише!!! Это целый >> конгломерат функциональности, причем реляционный движок значимая, но не >> самая большая часть. C>Вот. И эта остальная часть — по большей части сливает нормальным C>системам разработки. Так как она не была изначально для этого предназначена.
Можно конкретные примеры фунциональности, которые Вы не смогли разрулить только на уровне СУБД и перенесли на средний слой? Давайте только не будем про рассылку писем и оповещения, ибо это реализуется и без апп. сервера.
Здравствуйте, Cyberax, Вы писали:
C>..., чем СУБД, которые именно для этого предназначены. >> Долго ржал... C>Зря смеешься. Это именно так.
Не надо рассказывать мне сказки, чтоб самописные джоины и сортировки "сделали" их аналоги на промышленных серверах СУБД!
C>Зачастую просто написать тупой императивный код, чем громоздить запросы C>и работать с курсорами.
Курсоры идут в сад! А вот "запросы" — это то, что умеет "переваривать" СУБД гараздо лучше, чем самопальный императивный код на апп. сервере.
C>У меня примерно та же ситуация — клиенты один раз загружают с сервера C>нужные данные (которые при этом чаще всего еще и во внутрипроцессном C>кэше лежат), а потом уже работают с ними на локальных узлах. Так как C>иначе сервер БД бы просто умер.
Даешь всю базу на клиента! Возвращение к истокам? Все работают с локальными копиями. Еще один спец по разгрузке серверов баз данных от их непосредственных обязанностей...
Здравствуйте, pkarklin, Вы писали:
P>Здравствуйте, Cyberax, Вы писали:
C>>У меня примерно та же ситуация — клиенты один раз загружают с сервера C>>нужные данные (которые при этом чаще всего еще и во внутрипроцессном C>>кэше лежат), а потом уже работают с ними на локальных узлах. Так как C>>иначе сервер БД бы просто умер.
P>Даешь всю базу на клиента! Возвращение к истокам? Все работают с локальными копиями. Еще один спец по разгрузке серверов баз данных от их непосредственных обязанностей...
Нагрузка на базу существенно ниже, если сортировку производить на сервере приложений либо на клиенте.
На сколько я знаю, при сортировке Oracle использует табличное пространство TEMP. Если каждый пользователь начнет кидать запросы с ORDER, это может привести к резкому падению производительности.
Здравствуйте, _Oleg_, Вы писали:
_O_>Нагрузка на базу существенно ниже, если сортировку производить на сервере приложений либо на клиенте.
Господи Всемилостевший... Взываю к тебе...
Господа, но вы сами себя послушайте, а...
Если ОДИН сервер СУБД не справляется с нагрузкой от большого числа пользователей, то мы между ним и пользователями поставим ЕЩЕ ОДИН СЕРВЕР, который решит эти проблемы? Бред...
_O_>На сколько я знаю, при сортировке Oracle использует табличное пространство TEMP. Если каждый пользователь начнет кидать запросы с ORDER, это может привести к резкому падению производительности.
Позволю себе порекомендовать и Вам чуть глубже с архитектурой используемой Вами СУБД. И, потом, на разработку СУБД, специально расчитанных на обслуживание тюсяч и десятков тысяч пользователей, потречена ни одна сотня человеко\лет. И Вы считаете, что Вы на уровне апп.сервера "импертивным кодом" реализуете механизмы кэширования, сортировки и объединения лучше? Я Вас умоляю...
Здравствуйте, Mika Soukhov, Вы писали:
FD>>Это широко распространенное заблуждение.
MS>Тоесть, таких неграмотных как я много? Ну чтож, скучать не будем.
Я вот раньше тоже думал, что констрейнты — это не бизнес-правила, пока
старика Дейта не почитал.
Хотя, если мыслить логически, то все совершенно ясно.
По определению, бизнес-правила — правила, описывающие организацию бизнеса (в общем, есть разные определения,
но все они означают приблизительно одно и тоже).
Возьмем, скажем, торговую компанию. В базе данных у нас будут присутствовать, допустим,
таблицы Orders для заказов и OrderItems для позиций заказа, между которыми
создан Foreign Key. Смысл этого ключа в переводе на нормальный язык будет означать
"Заказ состоит из нескольких позиций. Каждая позиция заказа принадлежит одному
и только одному заказу". То есть самое что ни на есть правило, описывающее
процесс ведения бизнеса.
(Если быть совсем точным, то здесь Foreign Key не совсем точно описывает реальность,
поскольку он допускает ситуацию, когда некоторой записи в таблице Orders не соответствует ни
одной записи в таблице OrderItems. То есть резрешаются пустые заказы, не содержащие
позиций, чего в жизни не бывает.)
Аналогично Primary Key для таблицы Orders означает "Каждый заказ имеет уникальный номер,
чтобы отличать его от других заказов" и так далее.
MS>Любой автоматизированные бизнес в мире (выращивание бананов и продажа оружейного плутония) объединяют как минимум три бизнес-правила
Какие ?
Re[14]: ORACLE: АРХИТЕКТУРА БД
От:
Аноним
Дата:
12.09.07 14:33
Оценка:
> потречена ни одна сотня человеко\лет.
rdbms оракла ~ 30 лет, для пары сотен человеко лет там должно в ядре ковырятся не более 30 человек из 10,000 штатных сотрудников
2_Oleg_
может перед критикой хотя бы oracle concepts попробуете осилить, ну и историю ИТ полистать ...
Здравствуйте, Cyberax, Вы писали:
C>Flying Dutchman wrote: >> Indeed, foreign key constraints in particular are an important case of >> *business rules* in general. >> (В самом деле, ограничение по внешнему ключу является частным случаем >> *бизнес-правила*.) >> Так что ограничение целостности являются бизнес-правилами. C>Достаточно редко объекты в БД соответствуют 1-в-1 реальным C>бизнес-объектам. Так что FKC — это один из _способов_ задавать C>бизнес-правила, но не самый мощный.
Интересно, а какой способ задавать бизнес-правила более мощный ?
Здравствуйте, pkarklin, Вы писали:
P>А какие проблемы с юнит-тестированием серверного кода? И, простите, зачем мне ООП в реляционной СУБД?! Свят, свят, свят...
В PL/SQL уже давно есть ООП.
P>Окститесь! Современные СУБД это не просто хранилише!!! Это целый конгломерат функциональности, причем реляционный движок значимая, но не самая большая часть.
А если еще вспомним про всякие reporting'и, analizing'и b т.п....
Здравствуйте, pkarklin, Вы писали:
P>Если ОДИН сервер СУБД не справляется с нагрузкой от большого числа пользователей, то мы между ним и пользователями поставим ЕЩЕ ОДИН СЕРВЕР, который решит эти проблемы? Бред...
Это не бред, это правда жизни... Иногда..
На практике один сервер БД может (и должен) держать 3-4 App-сервера. Хотя это очень сильно зависит от задачи и окружения. Вообще, рассуждать о том что лучше в отрыве от конкретной задачи — довольно бесполезное занятие.
P> И Вы считаете, что Вы на уровне апп.сервера "импертивным кодом" реализуете механизмы кэширования, сортировки и объединения лучше? Я Вас умоляю...
Не будем столь котегоричны. Существуют сценарии, при которых это утверждение является истиной.
Причин тому несколько. Во-первых, кеширование такая штука, которая в принципе работает тем эффективнее, чем ближе расположено к клиенту. А во-вторых, БД решает задачу в общем виде, а конкретный App-сервер решает конкретную прикладную задачу, ему просто больше информации доступно, что можно кешировать, а что нельзя, и как — таже фигня и с объединением и сортировкой.
Здравствуйте, Flying Dutchman, Вы писали:
FD>Я вот раньше тоже думал, что констрейнты — это не бизнес-правила, пока FD>старика Дейта не почитал.
Старика Дейта надо читать аккуратно, на неокрепший мозг действует хуже чем капля никотина на того хомячка.
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, Flying Dutchman, Вы писали:
FD>>Я вот раньше тоже думал, что констрейнты — это не бизнес-правила, пока FD>>старика Дейта не почитал. IB>Старика Дейта надо читать аккуратно, на неокрепший мозг действует хуже чем капля никотина на того хомячка.
Здравствуйте, Flying Dutchman, Вы писали: FD>И как ты задашь Fioreign Key constraint при помощи DSL ? Напомню, что DDL — это DSL для описания реляционных таблиц.
DSL может включать в себя всё то же плюс еще тележку, особенно если будет описывать не таблицы, а сущности.
Вот, из свежепридуманного:
define entity OrderItem
(
Order references Orders,
Item
unique within Order
references Items where Item.IsAllowedFor(Order.Owner)
)
DDL скрывает нервную икоту.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, IB, Вы писали:
IB>Это не бред, это правда жизни... Иногда..
Бесспорно.
IB>На практике один сервер БД может (и должен) держать 3-4 App-сервера. Хотя это очень сильно зависит от задачи и окружения. Вообще, рассуждать о том что лучше в отрыве от конкретной задачи — довольно бесполезное занятие.
И тут соглашусь. Хотя, нужен ли в таком случаи сервер СУБД? Прошу не относить меня к противником N-звенок. Я противник пихания их куда нипоподя. Вступить в дисскуссию в слишком категоричном тоне меня заставила такая же категоричность сторонников реализации бизнес-логики на апп. серверах. И, как всегда, приводится аргументация, невыдерживающая критики.
P>> И Вы считаете, что Вы на уровне апп.сервера "импертивным кодом" реализуете механизмы кэширования, сортировки и объединения лучше? Я Вас умоляю... IB>Не будем столь котегоричны. Существуют сценарии, при которых это утверждение является истиной. IB>Причин тому несколько. Во-первых, кеширование такая штука, которая в принципе работает тем эффективнее, чем ближе расположено к клиенту. А во-вторых, БД решает задачу в общем виде, а конкретный App-сервер решает конкретную прикладную задачу, ему просто больше информации доступно, что можно кешировать, а что нельзя, и как — таже фигня и с объединением и сортировкой.
Это утверждение может быть истиной только в контексте сценария, изолированного от взаимодействия апп.сервера с сервером бд. В противном случие суммарная произодительность (выбрать данные сервера бд, передать их на апп.сервер, закэшировать, отсортировать и вернуть клиенту) в сугубо простых и специфических случаях будет выше в N-звенке.
Здравствуйте, pkarklin, Вы писали:
P>И тут соглашусь. Хотя, нужен ли в таком случаи сервер СУБД?
А кто ACID-ность обеспечивать будет? Нужен конечно...
P>Это утверждение может быть истиной только в контексте сценария, изолированного от взаимодействия апп.сервера с сервером бд.
Нет, дело не в изолированности...
P> В противном случие суммарная произодительность (выбрать данные сервера бд, передать их на апп.сервер, закэшировать, отсортировать и вернуть клиенту) в сугубо простых и специфических случаях будет выше в N-звенке.
Очевидно, кешируются уже отсортированные и сджойненые данные и это будет эффективнее чем в БД — исключается раунд-тип в хранилище и снимается нагрузка на него. Физически БД очень плохо масштабируются, пихать же stateless app-сервероа можно практически даром.
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, pkarklin, Вы писали:
P>>И тут соглашусь. Хотя, нужен ли в таком случаи сервер СУБД? IB>А кто ACID-ность обеспечивать будет? Нужен конечно...
Ну, так он и не только это делать умеет...
IB>Очевидно, кешируются уже отсортированные и сджойненые данные и это будет эффективнее чем в БД — исключается раунд-тип в хранилище и снимается нагрузка на него. Физически БД очень плохо масштабируются, пихать же stateless app-сервероа можно практически даром.
Такой подход (кеширование ПОСЛЕ сортировки и сджоивания в бд) я еще готов признать. Но смех у меня вызвал проспект ebay, где они и сортировку с джоинами вынесли на апп. сервер.
Здравствуйте, pkarklin, Вы писали:
C>>Вот. И эта остальная часть — по большей части сливает нормальным C>>системам разработки. Так как она не была изначально для этого предназначена. P>Можно конкретные примеры фунциональности, которые Вы не смогли разрулить только на уровне СУБД и перенесли на средний слой? Давайте только не будем про рассылку писем и оповещения, ибо это реализуется и без апп. сервера.
У меня основное приложение — работа с расписанием. Один из достаточно сложных моментов — сортировка людей по количеству денег, которые они заработают за смену. Первая версия была написана в виде жуткой процедуры на Oracle'е. Торррмозилло, особенно с многими клиентами. "Поставить еще один сервер" — далеко уже не так просто, нужно ставить систему репликации, разделяемое хранилище и т.п.
В текущей версии эти вычисления были перенесены на клиента. Ну и "за компанию" почти все остальные тоже (так как не осталось смысла их на сервере держать). В результате, сейчас сервер БД занят практически только фиксацией изменений. Даже загрузка данных на клиенты идет по большей части из кэша.
Здравствуйте, pkarklin, Вы писали:
>>> Долго ржал... C>>Зря смеешься. Это именно так. P> P>Не надо рассказывать мне сказки, чтоб самописные джоины и сортировки "сделали" их аналоги на промышленных серверах СУБД!
Элементарно. Я часто руками могу заоптимизировать так, что некоторым БД даже не снилось даже и при использовании хинтов. У меня вообще "промышленные" решения долго не живут — погибают после глубокой кастомизации под мои задачи.
C>>Зачастую просто написать тупой императивный код, чем громоздить запросы C>>и работать с курсорами. P>Курсоры идут в сад! А вот "запросы" — это то, что умеет "переваривать" СУБД гараздо лучше, чем самопальный императивный код на апп. сервере.
Как ты предлагаешь _нормально_ без курсоров работать с понятиями "предидущий ряд результата"/"предидущая точка изменения"?
C>>У меня примерно та же ситуация — клиенты один раз загружают с сервера C>>нужные данные (которые при этом чаще всего еще и во внутрипроцессном C>>кэше лежат), а потом уже работают с ними на локальных узлах. Так как C>>иначе сервер БД бы просто умер. P>Даешь всю базу на клиента!
Ага, именно. Сейчас делаем архитектуру, когда данные будут рассылаться на локальные супер-ноды, а оттуда уже на клиентские компьютеры. Чтобы даже и эту нагрузку с сервера снять.
P>Возвращение к истокам? Все работают с локальными копиями. Еще один спец по разгрузке серверов баз данных от их непосредственных обязанностей...
А какие проблемы в локальных копиях? Авторитетная копия данных находится на сервере, все изменения тоже проходят исключительно через сервер (а потом автоматически реплицируются во все локальные копии). Так что проблем с безопасностью и прочими timestamp'ами — никаких.
Здравствуйте, Flying Dutchman, Вы писали:
C>>Достаточно редко объекты в БД соответствуют 1-в-1 реальным C>>бизнес-объектам. Так что FKC — это один из _способов_ задавать C>>бизнес-правила, но не самый мощный. FD>Интересно, а какой способ задавать бизнес-правила более мощный ?
Мы используем для задания правил кастомизированый JBoss Drools.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, pkarklin, Вы писали:
C>У меня основное приложение — работа с расписанием. Один из достаточно сложных моментов — сортировка людей по количеству денег, которые они заработают за смену. Первая версия была написана в виде жуткой процедуры на Oracle'е. Торррмозилло, особенно с многими клиентами. "Поставить еще один сервер" — далеко уже не так просто, нужно ставить систему репликации, разделяемое хранилище и т.п.
Гм... Зачем репликация? Для Oracle — RAC, для MS SQL Federated Database Servers. Вот мне только интересно, какие объемы данных и скольким кол-вом пользователей обсчитывались одновременно, что "тормозило".
C>В текущей версии эти вычисления были перенесены на клиента. Ну и "за компанию" почти все остальные тоже (так как не осталось смысла их на сервере держать). В результате, сейчас сервер БД занят практически только фиксацией изменений. Даже загрузка данных на клиенты идет по большей части из кэша.
Повторятся не буду. Считать надо там, где и даные лежат.
Здравствуйте, Cyberax, Вы писали:
C>Элементарно. Я часто руками могу заоптимизировать так, что некоторым БД даже не снилось даже и при использовании хинтов. У меня вообще "промышленные" решения долго не живут — погибают после глубокой кастомизации под мои задачи.
Да Вы гений, батенька. Может попросить продуктовую команду, скажем MS SQL чтоб Вас взяли Вас к себе? А то, есть жалобы на некоторые моменты работы оптимизатора.
C>Как ты предлагаешь _нормально_ без курсоров работать с понятиями "предидущий ряд результата"/"предидущая точка изменения"?
Курсор в большинстве случаев может быть заменен циклом.
C>Ага, именно. Сейчас делаем архитектуру, когда данные будут рассылаться на локальные супер-ноды, а оттуда уже на клиентские компьютеры. Чтобы даже и эту нагрузку с сервера снять.
Почему бы на этих "супер-нодах" держат не апп. сервера, а сервера БД?
C>А какие проблемы в локальных копиях? Авторитетная копия данных находится на сервере, все изменения тоже проходят исключительно через сервер (а потом автоматически реплицируются во все локальные копии). Так что проблем с безопасностью и прочими timestamp'ами — никаких.
Это мне все напоминает старый-добрый файл\сервер. Притащили к себе данные и с ними работаем.
pkarklin wrote: > Гм... Зачем репликация? Для Oracle — RAC, для MS SQL Federated Database > Servers. Вот мне только интересно, какие объемы данных и скольким > кол-вом пользователей обсчитывались одновременно, что "тормозило".
Можно и RAC. Сколько оно там у нас стоит? А сколько для него стоит
нормальный SAN с винчестерами на fibre channel? На слабом железе RAC
работает очень посредственно — проверено.
В MSSQL примерно такие же требования, AFAIR.
> C>В текущей версии эти вычисления были перенесены на клиента. Ну и "за > компанию" почти все остальные тоже (так как не осталось смысла их на > сервере держать). В результате, сейчас сервер БД занят практически > только фиксацией изменений. Даже загрузка данных на клиенты идет по > большей части из кэша. > Повторятся не буду. Считать надо там, где и даные лежат.
Ага. Откуда такое догматическое убеждение?
pkarklin wrote: > C>Элементарно. Я часто руками могу заоптимизировать так, что некоторым > БД даже не снилось даже и при использовании хинтов. У меня вообще > "промышленные" решения долго не живут — погибают после глубокой > кастомизации под мои задачи. > Да Вы гений, батенька. Может попросить продуктовую команду, скажем MS > SQL чтоб Вас взяли Вас к себе?
Можно Только я туда не пойду.
> А то, есть жалобы на некоторые моменты работы оптимизатора.
Проблема в оптимизаторе в том, что он заточен на общие решения. А в моих
частных задачах часто можно применить достаточно значительные
оптимизации, до которых оптимизатору не додуматься в ближайшее время.
Ситуация такая же, как и с программированием на ассемблере — хороший
низкоуровневый программист часто может побить компилятор (особенно в
области использования всяких SSE), для которого оптимизатор писали
тысячи человеко-лет.
> C>Как ты предлагаешь _нормально_ без курсоров работать с понятиями > "предидущий ряд результата"/"предидущая точка изменения"? > Курсор в большинстве случаев может быть заменен циклом.
У меня проблема часто в запоминании некоторых предидущих позиций в
списке значений.
> C>Ага, именно. Сейчас делаем архитектуру, когда данные будут рассылаться > на локальные супер-ноды, а оттуда уже на клиентские компьютеры. Чтобы > даже и эту нагрузку с сервера снять. > Почему бы на этих "супер-нодах" держат не апп. сервера, а сервера БД?
Неудобно по некоторым причинам. У меня на app-серверах сейчас,
фактически, объектная база получается.
> C>А какие проблемы в локальных копиях? Авторитетная копия данных > находится на сервере, все изменения тоже проходят исключительно через > сервер (а потом автоматически реплицируются во все локальные копии). Так > что проблем с безопасностью и прочими timestamp'ами — никаких. > Это мне все напоминает старый-добрый файл\сервер. Притащили к себе > данные и с ними работаем.
И что тут плохого? У меня локально утаскиваются только те данные, с
которыми надо будет работать (и которые скорее всего придется показать).
В результате у меня GUI работает мгновенно. А вот как сделать мгновенные
запросы по тормозному каналу через половину Земли — пока еще не придумали.
Здравствуйте, Cyberax, Вы писали:
C>Можно и RAC. Сколько оно там у нас стоит? А сколько для него стоит C>нормальный SAN с винчестерами на fibre channel? На слабом железе RAC C>работает очень посредственно — проверено.
А, ну да, понятно. Берем MySQL. Енто у нас будет сервер бд. НА персоналках с идешными винтами делаем апп. сервера. Все счастливы и довольны. И, самое главное, все практически бесплатно.
C>В MSSQL примерно такие же требования, AFAIR.
Эээ... Простите?! Вам шашечки или ехать?
C>Ага. Откуда такое догматическое убеждение?
Здравствуйте, pkarklin, Вы писали:
C>>Можно и RAC. Сколько оно там у нас стоит? А сколько для него стоит C>>нормальный SAN с винчестерами на fibre channel? На слабом железе RAC C>>работает очень посредственно — проверено. P>А, ну да, понятно. Берем MySQL. Енто у нас будет сервер бд. НА персоналках с идешными винтами делаем апп. сервера. Все счастливы и довольны. И, самое главное, все практически бесплатно.
Как ни странно, Google вот примерно так и сделал. Вместо того, чтобы заплатить $$$$$$$$$ за пару десятков тысяч Orcale'ов с RAC — эти идиоты даже сделали свою файловую систему.
У меня на узлах сейчас вообще базы данных нет — ее роль выполняет структурированый кэш в оперативной памяти.
C>>В MSSQL примерно такие же требования, AFAIR. P>Эээ... Простите?! Вам шашечки или ехать?
Ехать, да еще и без миллионных требований на железо.
Здравствуйте, Cyberax, Вы писали:
C>Можно Только я туда не пойду.
Как хотите.
C>Проблема в оптимизаторе в том, что он заточен на общие решения. А в моих C>частных задачах часто можно применить достаточно значительные C>оптимизации, до которых оптимизатору не додуматься в ближайшее время.
C>Ситуация такая же, как и с программированием на ассемблере — хороший C>низкоуровневый программист часто может побить компилятор (особенно в C>области использования всяких SSE), для которого оптимизатор писали C>тысячи человеко-лет.
Точно так же и хороший программист баз данных может заставить выполняться запрос так как он пожелает, а не как за отведенное ему на размышление время придумал оптимизатор. К чему это я. Каждый инструмент нужно уметь использовать проффесионально и, самое главное, к месту. Если я счас на T-SQL буду писать обработку видео, то сами понимаете, что у меня получится.
C>У меня проблема часто в запоминании некоторых предидущих позиций в C>списке значений.
Это слишком обще... Была бы конретная задача — можно было бы полумать о решении.
C>Неудобно по некоторым причинам. У меня на app-серверах сейчас, C>фактически, объектная база получается.
Ну, тогда понятно. Вам "привычнее" работать с объектами, чем с чисто реляционными данными, поэтому у Вас и апп. сервера.
C>И что тут плохого? У меня локально утаскиваются только те данные, с C>которыми надо будет работать (и которые скорее всего придется показать).
Да ни каких проблем, когда таких данных не много.
C>В результате у меня GUI работает мгновенно. А вот как сделать мгновенные C>запросы по тормозному каналу через половину Земли — пока еще не придумали.
Ширина канала на "торознутость запроса" влияет примерно так же, как время, необходимое чтобы доехать до автосервиса на время, необходимое на починку Вашей машины.
Здравствуйте, Cyberax, Вы писали:
C>Как ни странно, Google вот примерно так и сделал.
На гугловых задачах ACID-ность не нужна, им MySQL в самый раз. У гугла все-таки уникальная задача, не следует их сомбреро натягивать на всех хуанов в округе.
IB wrote: > C>Как ни странно, Google вот примерно так и сделал. > На гугловых задачах ACID-ность не нужна, им MySQL в самый раз. У гугла > все-таки уникальная задача, не следует их сомбреро натягивать на всех > хуанов в округе.
MySQL, кстати, давно уже ACID. А его последние фичи с share-nothing
кластеризацией — вообще позволяют во многих случаях успешно соперничать
с Oracle/MSSQL.
Здравствуйте, Cyberax, Вы писали:
C>MySQL, кстати, давно уже ACID.
Гы. Его ACID, это главная деталь вечного двигателя — вечный тормоз. Его использовать-то толком нельзя.
C> А его последние фичи с share-nothing кластеризацией — вообще позволяют во многих случаях успешно соперничать C>с Oracle/MSSQL.
Ну да, когда транзакционность не нужна.
IB wrote: > C>MySQL, кстати, давно уже ACID. > Гы. Его ACID, это главная деталь вечного двигателя — вечный тормоз. Его > использовать-то толком нельзя.
Странно, многие почему-то так вполне успешно его используют. MySQL
Enterprise пользуется вполне себе неплохим спросом.
> C> А его последние фичи с share-nothing кластеризацией — вообще > позволяют во многих случаях успешно соперничать > C>с Oracle/MSSQL. > Ну да, когда транзакционность не нужна.
Блин, MSSQL уже пять лет как транзакции поддерживает. В их кластерной
системе как раз нетранзакционный движок вообще не работает. Ты вообще
кроме MS что-нибудь смотришь?
Здравствуйте, Cyberax, Вы писали:
C>Странно, многие почему-то так вполне успешно его используют.
Конечно используют на хомяках.
C>MySQL Enterprise пользуется вполне себе неплохим спросом.
Там где транзакции не нужны.
C>Блин, MSSQL уже пять лет как транзакции поддерживает.
MySql? Фигово он их поддерживает. Обоими своими движками и беркли и финской поделкой.
C> В их кластерной системе как раз нетранзакционный движок вообще не работает.
Да там и транзакционный не очень.
IB wrote: > C>Странно, многие почему-то так вполне успешно его используют. > Конечно используют на хомяках.
Статистику в студию.
> C>MySQL Enterprise пользуется вполне себе неплохим спросом. > Там где транзакции не нужны.
Мда. А MSSQL используют там, где администраторам лень ставить нормальную
БД типа Oracle или Postgres.
> C>Блин, MSSQL уже пять лет как транзакции поддерживает. > MySql? Фигово он их поддерживает. Обоими своими движками и беркли и > финской поделкой.
В чем фиговость? "Агласите весь список, пжалуста" (c) фильм.
> C> В их кластерной системе как раз нетранзакционный движок вообще не > работает. > Да там и транзакционный не очень.
Чем "не очень"? Полный ACID, с поддержкой XA.
Здравствуйте, Cyberax, Вы писали:
C>Статистику в студию.
В гугле поищи.
C>А MSSQL используют там, где администраторам лень ставить нормальную C>БД типа Oracle или Postgres. Постгри тут тоже очень кстати. )
C>В чем фиговость? "Агласите весь список, пжалуста" (c) фильм.
Тормозами и глюками.
C>Чем "не очень"? Полный ACID, с поддержкой XA.
Вот именно что полный, только очень медленный и не стабильный.
Здравствуйте, Flying Dutchman, Вы писали:
FD>На странице 12 читаем:
FD>
FD>...note that the PRIMARY KEY and FOREIGN KEY clauses correspond to business rules...
FD>(...отметим, что предложения PRIMARY KEY и FOREIGN KEY относятся к бизнес-правилам...)
FD>или немного ранее
FD>
FD>Indeed, foreign key constraints in particular are an important case of
FD>business rules in general.
FD>(В самом деле, ограничение по внешнему ключу является частным случаем бизнес-правила.)
FD>Так что ограничение целостности являются бизнес-правилами.
Почти прав. Только ограничения целостности не всегда являются бизнес-правилами. Допустим:
1. Сообщение не может быть без адресата.
Как бы все прекрасно, делаем foreign key на адресат, и можно почти считать что мы выполнили данное бизнес-правило. foreign key — есть бизнес-правило.
Но тут появляется второе требование.
2. При сохранении сообщение, в случае если адресат не заполнен, пользователю должен быть предложено заполнить адресат.
Oops. Посылать на сервер неликвидные данные в принципе можно. Получишь оттуда ошибку (нормальное получение ошибки еще та песня) и покажешь форму выбора адресата. Только по правильному нужно все решать на уровне клиента и бизнес-логики клиента без открытия транзакции. И получается, что клиент а не БД выполняет не только бизнес-логику. А foreign key — как таковой является только логикой хранения данных, может и желательной вещью, но необязательной.
Что же касается PK — то в большинстве случаев он вообще суррогат. И бизнес-сущностью его фиг опишешь.
Здравствуйте, Cyberax, Вы писали:
C>>>Зачастую просто написать тупой императивный код, чем громоздить запросы C>>>и работать с курсорами. P>>Курсоры идут в сад! А вот "запросы" — это то, что умеет "переваривать" СУБД гараздо лучше, чем самопальный императивный код на апп. сервере. C>Как ты предлагаешь _нормально_ без курсоров работать с понятиями "предидущий ряд результата"/"предидущая точка изменения"?
В этом случае можно прекрасно обойтись без курсоров (другое дело, что это
как раз та область применения SQL, которая сложна для понимания программистов,
которые пишут на процедурных/императивных языках).
Курсоры вообще нужны в очень ограниченном числе случаев, например:
1. БД спроектирована неправильно. Например, вместо того чтобы
хранить заказы и/или другие данные всех клиентов в одной таблице, делается
отдельная таблица для каждого клиента.
2. К каждому элементу из результата запроса нужно применить операцию,
отсутствующую в SQL, например, вызвать хранимую процедурую. Или,
например, "получить список всех соединений к базе данных A и для
каждого соединения выполнить команду kill". (В Transact SQL часто
можно в подобных случаях обойтись без курсора при помощи
использования денормализации списков + динамического SQL).
3. Иногда бывает, что решение на основе курсора быстрее, чем решение
на чистов SQL (в случае использования запросы на основе тэта-соединений (theta-joins)).
Например, задача вычисления нарастающих итогов (running totals) часто решается
быстрее на основе курсора.
4. Другие редкие случаи, например, обработка иерархических струкур. (Однако,
напрмер, при использовании Transact SQL курсор в этом случае не нужен).
Но в подавляющем большинстве случаев задачу можно решить без использования курсоров и решение
на SQL получается короче.
Здравствуйте, Cyberax, Вы писали:
C>Flying Dutchman wrote: >> Зато языки хранимых процедур обладают большими возможностями для работы >> с реляционными данными. C>Работа с реляционными данными в большинстве случаев сводится к "сделать C>запрос". Это прекрасно можно сделать без хранимых процедур.
Можно, но делать запросы в коде, скажем на C#, гораздо неудобнее, чем
в хранимых процедурах, потому что
1. SQL в хранимых процедурах статический, а в программе на C# динамический.
Это означает, что в ХП ошибки в SQL-коде видны сразу при компиляции, а в
SQL-запросе в C#-программе — только на этапе выполнения программы.
Это затрудныет отладку и тестирование.
В некоторых системах существует Embedded SQL (например, в среде
IBM OS-360/390 при работе с PL/1 + DB2 это было еще 20 лет назад). То есть
запросы пишутся на SQL прямо в тексте программы на процедурном языке, потом
программа обрабатывается препроцессором, который делает проверку ошибок в SQL
(и соответствия используемых таблиц и столбцов реальной структуре БД)
и уже потом программа компилируется.
Но в .NET это не реализовано.
2. При изменениии структуры таблиц в БД соответствующий код в ХП перестает
компилироваться и сразу видно, где нужно внести изменения. В программе
на C# нужно вручную просмотреть все тексты запросов.
3. В языке хранимых процедур присутствуют средства, которых нет в C#.
Например, в Tкansact SQL можно использовать временные таблицы и табличные
переменные. Или использовать в SELECT функции, созданные на Transact SQL.
4. Нужно писать дополнительный код для передачи параметров в запросы
(либо переводить используемые значения в текстовый вид) и
следить за предотвращением ошибок типа SQL Injection.
Исходя из этого, во многих организациях действует правило, согласно которому
в клиентской программе вообще не должно быть никакого кода на SQL, за
исключением:
1. Запросов, снегенерированных автоматически — например, при помощи ORM.
2. Сложных запросов, которые строятся динамически на основе данных,
введенных пользователем в форме.
Я также являюсь сторонником этого правила.
С>А тут еще и C>LINQ подкатывает, который сведет на нет большую часть "преимуществ" БД.
О преимуществах LINQ пока еще рано говорить — слишком молодая технология.
К тому же стремление авторов lINQ обеспечить возможность выполнения
запросов из разных источников вполне может оказаться попыткой пойти двумя
ногами в две разные двери .
C>Ну и я не говорю про ORM.
ORM, конечно, вещь очень полезная, но не избавляет полностью
он необходимости писать запросы руками.
ORM обычно позволяет создать набор классов, инкапсулирующих в себя
структуру таблиц БД и отношений между ними и затем использовать
их для манипуляции данных в БД.
В первую очередь можно легко автоматизировать CRUD-операции (
от слов Create-Read-Update-Delete), имеются в виду такие
базовые операции как "Прочитать все данные из таблицы",
"Прочитать/изменить/удалить одну запись из таблицы с соответствующим
значением первичного ключа или уникального индекса" или "добавить
новую запись в таблицу". Также автоматизируются более сложные
операции, например "Для двух таблиц, связанных отношением 1:M,
для определенной записи в родительской таблице вернуть все
соответствующие данные из дочерней таблицы".
ORM предыдущего поколения (например, Olymars) создавали для
этих целей хранимые процедуры в базе данных (что было не совсем
удобно, потому что база данных засорялась множеством мелких ХП).
Современные ORM (например, LLBLGen) используют методику динамической генерации
SQL в процессе выполнения программы.
Например, я использую LLBLGen Pro. Он создает классы и методы,
при помощи которых можно манипулировать данными в базе данных
без явного использования SQL. Сгенерированные классы и методы можно
использовать таким, например, образом:
OrdersCollection cOrders = new OrdersCollection();
cOrders.GetMulti(new PredicateExpression(OrdersFields.ExportDate == DBNull.Value));
Это означает: "Выполнить запрос
select *
from Orders
where ExportDate is null
и занести результат в коллекцию cOrder".
при выполнении этого C#-кода происходит генерация SQL-кода,
который передается на выполнение базе данных.
Теоретически любой SQL-запрос можно записать в подобной форме.
Но только теоретически.
Для простых запросов это работает, но стоить немного усложнить запрос
(добавить несколько условий в Where, соединить несколько таблиц или
выполнить два запроса в одной транзакции), как код становится
совершенно нечитаемым.
То есть на практике ORM может помочь избавиться от 80% SQL-кода,
но сложные запросы по-прежнему проще реализовывать в хранимых процедурах.
>> P>>По меньшей мере странно обрабатывать данные в реляционным хранилище >> языком, не предназначенном для этого. >> C>По меньшей мере странно использовать *хранилище* для обработки данных. >> База данных — это не просто хранилище данных, а хранилище данных + >> хранилище бизнес-правил + устройство обработки данных. C>Нет. База данных — это именно хранилище, на которое многие пытаются C>навернуть того, что там не должно быть.
База данных — это, как минимум, структура данных + сами данные + констрейнты.
Flying Dutchman wrote: > C>Как ты предлагаешь _нормально_ без курсоров работать с понятиями > "предидущий ряд результата"/"предидущая точка изменения"? > В этом случае можно прекрасно обойтись без курсоров (другое дело, что это > как раз та область применения SQL, которая сложна для понимания > программистов, которые пишут на процедурных/императивных языках).
А можно пример как? Мне нужно при работе хранить множество точек
изменений значений или функции от значения.
> Курсоры вообще нужны в очень ограниченном числе случаев, например: > 1. БД спроектирована неправильно. Например, вместо того чтобы > хранить заказы и/или другие данные всех клиентов в одной таблице, делается > отдельная таблица для каждого клиента.
Нормализовано, до третей нормальной формы.
> 3. Иногда бывает, что решение на основе курсора быстрее, чем решение > на чистов SQL (в случае использования запросы на основе тэта-соединений > (theta-joins)). > Например, задача вычисления нарастающих итогов (running totals) часто > решается быстрее на основе курсора.
Theta-join'ы слишком ограничены. C running totals — все просто. А ты
попробуй написать запрос, который пронумерует dupe'ы в базе данных.
Императивный код для этого будет работать O(N) времени (ну O(N*log N)).
> Но в подавляющем большинстве случаев задачу можно решить без > использования курсоров и решение на SQL получается короче.
Меня эти случаи не подавляют — почему-то они как раз у меня толпами летают.
Здравствуйте, Flying Dutchman, Вы писали:
FD>1. SQL в хранимых процедурах статический, а в программе на C# динамический. FD>Это означает, что в ХП ошибки в SQL-коде видны сразу при компиляции, а в FD>SQL-запросе в C#-программе — только на этапе выполнения программы. FD>Это затрудныет отладку и тестирование.
Это исправляется нормальными инструментами. Например:
Я специально добавил ошибки — установку несуществующего параметра и несуществующее поле. Как видишь, IDE мне их вполне нормально показала и подсветила. Также обрати внимание на подсветку синтаксиса. При редактировании, естественно, работает автокомплит и рефакторинг.
FD>2. При изменениии структуры таблиц в БД соответствующий код в ХП перестает FD>компилироваться и сразу видно, где нужно внести изменения. В программе FD>на C# нужно вручную просмотреть все тексты запросов.
См. предидущий пункт.
FD>3. В языке хранимых процедур присутствуют средства, которых нет в C#. FD>Например, в Tкansact SQL можно использовать временные таблицы и табличные FD>переменные. Или использовать в SELECT функции, созданные на Transact SQL.
Единственный плюс для хранимых процедур.
FD>4. Нужно писать дополнительный код для передачи параметров в запросы FD>(либо переводить используемые значения в текстовый вид) и FD>следить за предотвращением ошибок типа SQL Injection.
SQL injection вполне возможен и при вызове хранимых процедур.
FD>Исходя из этого, во многих организациях действует правило, согласно которому FD>в клиентской программе вообще не должно быть никакого кода на SQL, за FD>исключением: FD>1. Запросов, снегенерированных автоматически — например, при помощи ORM. FD>2. Сложных запросов, которые строятся динамически на основе данных, FD>введенных пользователем в форме.
Вот эти мне ОЧЕНЬ не нравится. Только зря увеличивается число сущностей — в крайнем случае можно манипуляцию в отдельный DAL вынести.
C>>Ну и я не говорю про ORM. FD>ORM, конечно, вещь очень полезная, но не избавляет полностью FD>он необходимости писать запросы руками.
См. пункт 1
FD>Например, я использую LLBLGen Pro. Он создает классы и методы, FD>при помощи которых можно манипулировать данными в базе данных FD>без явного использования SQL. Сгенерированные классы и методы можно FD>использовать таким, например, образом: FD>То есть на практике ORM может помочь избавиться от 80% SQL-кода, FD>но сложные запросы по-прежнему проще реализовывать в хранимых процедурах.
Это просто в .NET нет нормальных ORM Для Java есть Hibernate и Toplink — сейчас, пожалуй, только сверхсложные аналитические запросы не получается нормально на Hibernate Query Language писать.
C>>Нет. База данных — это именно хранилище, на которое многие пытаются C>>навернуть того, что там не должно быть. FD>База данных — это, как минимум, структура данных + сами данные + констрейнты.
Естественно. С этим я не спорю — у баз данных хранение данных и проверка констрейнтов получаются очень хорошо.
IB wrote: > C>Статистику в студию. > В гугле поищи.
Можно ключевые слова?
> C>А MSSQL используют там, где администраторам лень ставить нормальную > C>БД типа Oracle или Postgres. > Постгри тут тоже очень кстати. )
Ну ты же делаешь нелепые необоснованые заявляения. Чем я хуже?
> C>В чем фиговость? "Агласите весь список, пжалуста" (c) фильм. > Тормозами и глюками.
"Агласите весь список, пжалуста" (c) фильм.
> C>Чем "не очень"? Полный ACID, с поддержкой XA. > Вот именно что полный, только очень медленный и не стабильный.
Да??? По моим тестам MySQL на стоковом железе в кластере выигрывает у
ВСЕХ крупных серверов (тестировался Oracle, Postgresql+PgCluster, MSSQL)
на разумных операциях.
Что, собственно, неудивительно — NDB (кластерный движок в MySQL)
придумывался для high-perf телекомовских приложений.
Здравствуйте, Cyberax, Вы писали:
C>Можно ключевые слова?
Сам не справляешься?
C>Ну ты же делаешь нелепые необоснованые заявляения. Чем я хуже?
Тем что я не делаю нелепых и необоснованных утверждений. .
C>"Агласите весь список, пжалуста" (c) фильм.
Тормозами и глюками.
C>Да???
Угу.
C> По моим тестам MySQL на стоковом железе в кластере
Значит такие тесты.
Здравствуйте, Cyberax, Вы писали:
Снова все тот же спор!
Еще лет 5-10 назад рагорались споры и преимуществах и недостатках "толстых" и "тонких" клиентов! И притом еще никто и никогда не смог ответить однозначно! Во всем есть свои плюсы! Притом это вне зависимости от используемых средств! Так как с редства — это средства!!!
1.0 при использовании "толстого" клинета не засоряется база СУБД разного рода зранимками. Существуют только таблицы + минимум логики в программе.
1.1 при использовании тонкого клиента на конечной машине стоит только загрузка данных в какие-то таблицы запуск хранимок. То есть получается, что требования к лиентской машине минимальны. Можно хоть на сотом пне запускать вне хависимости от навороченности логики проекта
1.2 мы не заморачиваемся с контролем версий т.к. каждый клиент запуская программу использует те же хранимки, что и все остальные вне зависимости от даты установки программы
1.3 если вся логика реализована в хранимке и промежуточных таблицах, то происходит немного более быстрая обработка данных т.к., простите, данные немного поближе и никуда их перегонять не надо (тем более по сети). Это довольно заметно на большом кол-ве записей.
1.4 (продолжение 1.1) для обрабтки специализированный сервер с бОльшим запасом резурсов чем у клиента. Итог — меньшая стоимость владения данными для большого кол-ва лиентов. (особоенно актуальна для OLTP-систем)
На мой взгляд, при не чрезмерно большом кол-ве пользователей и их нагрузке на СУБД (OLTP и небольшое кол-во warehouse) наиболее логично использование логики на сервере, чтобы клиент мог только получать и отправлять данные минимально обрабатывая их
Свят, свят, свят...
Иногда.. 
Мы уже победили, просто это еще не так заметно...
