Здравствуйте, Aviator, Вы писали:

A>Поддерживать код SQL проще? Не смешите мои тапочки. Если у вас сидит один монстр который с уцтра до вечера фигачит запросы и у которого в голове лежит вся схема базы со всеми хранимками, то я понимаю почему Вы так говорите. А теперь предположитеЮ, что проходят годы, код меняется, дописывается новый. В один прекрасный день происходит непредвиденная ситуация — Ваши монстры SQL уходят, а новым надо уйму времени, что бы осознать какие хранимки что делают и как внести изменение, не поломав что то в другом конце системы. Не говоря уж о том, что бизнес логика должна оперировать понятиями бизнес логиками а не "математическими основами БД". А уж если в один прекрасный день вам предложат мигрировать с MS SQL на Oracle то Вы совсем расстроитесь.

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

Здравствуйте, Aviator, Вы писали:

A>Код с классами подвергается чёткому структурированию и рефакторингу. Скрипты sql по своей природе плохочитаемы и не особо структурируются.

Может вы их не так пишете, что их сложнее читать? А то тебя послушать SQL какой-то язык-злодей. А народ активно пользуется, все ошибаются?

Здравствуйте, adontz, Вы писали:


A>>>ИМХО ХП напротив проще поддерживать потому что:
kuj>>Вы когда-нибудь пытались поддерживать ХП? Я имею в виду более менее большие проекты, а не базы с парой десяткой табличек и 30-40 процедурами.

A>Поддержкой ХП занимаются программисты БД. Я не такой. Они на моей памяти не жаловались. Мне с ХП работать на порядки проще, чем изучать потроха конкретной схемы.

Я не завидую Вашим программистам БД.

A>>>

ХП пишет тот же, кто разработал схему БД, а значит ХП лучше учитывают наличие или отсутствие индексов. прикладной же программист вставляющий в свой код SQL запросы в лучшем случае прочитал названия таблиц и столбцов.
kuj>>В наше время все давно используют различные OR/M.

A>ORM всего лишь обёртки для мапинга и сопутствующих операций.

Вам пора прочитать что такое OR/M.

A>Если транзакция нужна, а её нет ORM не спасёт.
Какие проблемы с транзакциями? OR/M отлично справляются с организацией транзакций.

A>Если делается выборка по неиндексированному столбцу ORM опять таки не спасёт. Спасают, в плане не дают облажатся, именно ХП.
Да что Вы говорите... А посмотреть статистику сервера по запросам и грамотно проставить индексы не судьба? К слову, индексы далеко не всегда являются панацеей и могут даже вредить производительности.

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

kuj>>Что чрезвычайно усложняет сопровождение такого проекта, т.к. ХП гораздо сложнее отлаживать и тестировать. О читабельности я вообще молчу.

A>Извини, ты с ХП работал вообще?

К сожалению. При чем проект среднего размера на ХП был сущей головной болью даже в сравнении с самым сложным и большим проектом, который у нас сейчас есть (7 млн строк кода, 4 тыс. таблиц, более 8 мил. записей) на NHibernate.

kuj>>Потому и используют OR/M. Нету никаких таблиц. Нету никаких столбцов. Есть объекты DAL-уровня со свойствами. Есть соотвествующие объекты BLL уровня с бизнес логикой. Все связи минимальны благодаря IoC-контейнерам (Spring, Castle Windsor и т.п.). Код тщательно документируется. В наличии богатый IntelliSense инструментарий, фреймворки для тестирования типа nUnit с RhinoMocks, средства для автоматического создания документации, мощный отладчик, прекрасная читабельность кода, отсутствие привязки к конкретной БД и минимальная зависимость от схемы БД, высокая масштабируемость.

A>Повторюсь. ORM всего лишь обёртки для мапинга и сопутствующих операций. Если транзакция нужна, а её нет ORM не спасёт. Если делается выборка по неиндексированному столбцу ORM опять таки не спасёт. Спасают, в плане не дают облажатся, именно ХП.

Вы хоть понимаете о чем говорите? Похоже, что не очень.

A>Именно тот факт, что ORM являясь очень удобными средствами никак не контроллирующим разработчика и приводит к отказу от ORM в действительно крупных проектах.

Кто Вам эту чушь сказал?

A> Когда знакомишься с Hiberbnate первая мысль это ВАУ, потом начинают закрадываться сомнения, а чуть позже задаёшь на форуме вопрос "А без HQL можно?" потому что учёт специфики схемы БД не локализован, а разбросан по проекту.

Эээ?

A>Когда БД растёт вместе с проектом и эта специфика меняется начинаются странные падения производительности "хотя совсем недавно всё работало". Получаем мину замедленного действия.

Чушь.

A>Единственное известно мне исключение — это BLT, но там просто функциональности недостаточно чтоб мины делать (хотя в том что BLT делает, она на высоте).

Не знаю, не работал с BLT и не слышал ни об одном более-менее крупном проекте на BLT.

A>>>Кроме того, использование ХП позволяем автоматически тестировать самый низкоуровневый код работы с данными.
kuj>>Наоборот не позволяет автоматически тестировать. Нет, конечно можно писать тесты для тестирования хранимых процедур, но они редко могут быть полными.

A>Смотря что делают хранимые процедуры. Конечно, если у тебя реализация вида 1запрос-1ХП, то пользы и от ХП мало и от их тестирования.

В том-то и дело, что хранимая процедура это черный ящик. В отличии от тестирования того же CLR — где можно делать mocking объектов. Вы пишете тест для процедуры, которая в свою очередь вызывает еще 20 процедур. В итоге Ваш тест тестирует не (только) эту процедуру, но и остальные 20. Поэтому для модульного тестирования 1 запрос — 1 ХП это вообще идеальный вариант.


A>>>Зависимость от конкретной СУБД будет всегда. Дело даже не в синтаксических различиях диалектов SQL, а в разном объёме предоставляемой функциональности. Система не может быть независимой от СУБД на уровне DAL. Это ИМХО миф и утопия.
kuj>>Да? Какой кошмар...

A>Если тебе не совсем плевать на производительность, то да.

А какие проблемы с производительностью?

A>Ты писал приложение, которое должно работать на MSSQL И MySQL?

Нет, но у нас есть проект, успешно работающий с MS SQL и Oracle.

A>Это очень разные СУБД с разными заскоками. То что бегало на одной, на другой показывало просто УЖАСНУЮ производительность. Например в MySQL нет типа GUID, и если пойти на поводу у лени и хранить GUID'ы в строках, то получим падение производительности в разы. Разбиение на 4 int работало на ура, но никакая ORM не смогла это отобразить, что впрочем и не удивительно.

Ну так и не используйте GUID. Какие проблемы?


A>На самом деле нет никаких великих ORM и OODBMS. Есть реляционные БД со строгой математической теорией от которых никуда не деться именно в связи с огромной строгой математической теорией. Есть традиция ОО программирования от которйо тоже никуда не деться. а ещё есть маркетологи регулярно сулящие чему-нибудь смерть (RDBMS are dead, апплодисместы, хвала новым героям, бабки с Google AdSence ибо скандальное привлекает) и пытающиеся продать очередную серебрянную пулю. Нет ещё такого средства, которое бы эффективно отобразило хранящуюся в памяти объектную модель на данные в РСУБД без пинков и тычков. Когда надоедает пинать и тыкать, наступает просветление и просто делаешь всё руками. Ну или существенную часть.

Ну-ну.

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, adontz, Вы писали:

A>Может вы их не так пишете, что их сложнее читать? А то тебя послушать SQL какой-то язык-злодей. А народ активно пользуется, все ошибаются?
Это язык написания запросов, адаптированный для написания несложных скриптов. Он не предназначался для написания сложной логики.

Здравствуйте, kuj, Вы писали:

kuj>Вы когда-нибудь пытались поддерживать ХП? Я имею в виду более менее большие проекты, а не базы с парой десяткой табличек и 30-40 процедурами.
Успешно поддерживаем и развиваем. Кол-во ХП более 1150, таблиц более 400. ИМО ХП гораздо удобнее.

Здравствуйте, adontz, Вы писали:

A>То что ты сказал не лишено смысла, но к SQL не имеет решительно никакого отношения. Если мостры SQL непредвиденно уходят, это не прослема SQL или ХП. И если они уходят ни оставив ни капли комментариев, документции и т.п. сколько-нибудь полезной тем, кто пришёл им на замену, то это тоже к SQL имеет слабое отношение.

Ты искренне считаешь, что читать код на каком-нибудь transact-sql удобно? Что ковыряться по куче процедур доставляет удовольствие? Что процедурное программирование не менее удобно чем объектное?

Здравствуйте, ilvi, Вы писали:

I>Очень странно видеть такую полемику, напоминает религиозные войны программистов на билдере и визуал си. Одним удобно пользоваться неким конструктором, который от них "прячет" (упрощает — кому как нравится) некоторые вещи; другим приятнее сделать всю черновую работу самим и быть увереными, что они не потеряли в производительности и контролируют процесс.

Есть такое понятие, как сроки, и к сожалению сроки всегда ограничены. Как Вы думаете, зачем был придуман .NET Framework и Java? Можно было бы и на ASM писать... — все контроллировать и быть увереными (быть ли?), что не потеряли производительности и контролируют процесс.

I>В данном случае одни привыкли при работе с базой пользоваться промежуточными автоматизироваными средствами и думают, что это лучший вариант потому что привыкли работать имено в этом русле, другие также привыкли работать через хранимки и считают это вполе нормальным, и работа у них построенна изходя из этой особенности. Если работа организована грамотно, то можно работать в соответсвии с обоими идеями. Если где-то есть просчеты, то в любом случае будут проблемы, какой путь невыбери.
I>З.Ы.
I>Странно видеть возглассы о том, что большую бд с кучей хранимок тяжело поддерживать... Хочется задать вопрос, а большой проект с кучей разнородных классов легко подерживать?

Гораздо легче. Даже, если написано через пень-колоду, все-равно гораздо легче.

Здравствуйте, AndrewJD, Вы писали:

AJD>Здравствуйте, kuj, Вы писали:

kuj>>Вы когда-нибудь пытались поддерживать ХП? Я имею в виду более менее большие проекты, а не базы с парой десяткой табличек и 30-40 процедурами.
AJD>Успешно поддерживаем и развиваем. Кол-во ХП более 1150, таблиц более 400. ИМО ХП гораздо удобнее.
Интересно, а как у вас организован процесс тестирования? Сидим тыкаем кнопари на формах и ждём что случится? И вообще, TDD наверно враги прогресса придумали?

Здравствуйте, AndrewJD, Вы писали:

kuj>>Вы когда-нибудь пытались поддерживать ХП? Я имею в виду более менее большие проекты, а не базы с парой десяткой табличек и 30-40 процедурами.
AJD>Успешно поддерживаем и развиваем. Кол-во ХП более 1150, таблиц более 400. ИМО ХП гораздо удобнее.

Не завидую Вам. Честное слово. Наш проект на ХП с 800 процедур и 180 таблиц это сущая головная боль. Что-то в нем поменять почти не реально. Документации по нем кот наплакал...

Здравствуйте, kuj, Вы писали:

kuj>Здравствуйте, AndrewJD, Вы писали:

kuj>>>Вы когда-нибудь пытались поддерживать ХП? Я имею в виду более менее большие проекты, а не базы с парой десяткой табличек и 30-40 процедурами.
AJD>>Успешно поддерживаем и развиваем. Кол-во ХП более 1150, таблиц более 400. ИМО ХП гораздо удобнее.

kuj>Не завидую Вам. Честное слово. Наш проект на ХП с 800 процедур и 180 таблиц это сущая головная боль. Что-то в нем поменять почти не реально. Документации по нем кот наплакал...
Просто Вам наверно есть с чем сравнивать, а вот человеку видимо не с чем. Он искренне думает что лучше не бывает .

Здравствуйте, kuj, Вы писали:


AJD>>Успешно поддерживаем и развиваем. Кол-во ХП более 1150, таблиц более 400. ИМО ХП гораздо удобнее.
kuj>Не завидую Вам. Честное слово. Наш проект на ХП с 800 процедур и 180 таблиц это сущая головная боль. Что-то в нем поменять почти не реально. Документации по нем кот наплакал...
Есть мнение что это связано больше с тем как поставлен процес разработки в компании, а не в преимуществе ХП vs запросы

Здравствуйте, adontz, Вы писали:

A>>Поддерживать код SQL проще? Не смешите мои тапочки. Если у вас сидит один монстр который с уцтра до вечера фигачит запросы и у которого в голове лежит вся схема базы со всеми хранимками, то я понимаю почему Вы так говорите. А теперь предположитеЮ, что проходят годы, код меняется, дописывается новый. В один прекрасный день происходит непредвиденная ситуация — Ваши монстры SQL уходят, а новым надо уйму времени, что бы осознать какие хранимки что делают и как внести изменение, не поломав что то в другом конце системы. Не говоря уж о том, что бизнес логика должна оперировать понятиями бизнес логиками а не "математическими основами БД". А уж если в один прекрасный день вам предложат мигрировать с MS SQL на Oracle то Вы совсем расстроитесь.

A>То что ты сказал не лишено смысла, но к SQL не имеет решительно никакого отношения. Если мостры SQL непредвиденно уходят, это не прослема SQL или ХП. И если они уходят ни оставив ни капли комментариев, документции и т.п. сколько-нибудь полезной тем, кто пришёл им на замену, то это тоже к SQL имеет слабое отношение.

Это как-раз проблема ХП и SQL. Процедуры на T-SQL имеют ужасную читабельность. С PL/SQL чуть лучше, но и они не далеко ушли.

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

Здравствуйте, Aviator, Вы писали:

A>Интересно, а как у вас организован процесс тестирования? Сидим тыкаем кнопари на формах и ждём что случится?
Как обычно, ежедневные автоматические тесты.

A>И вообще, TDD наверно враги прогресса придумали?
TDD — серебрянная пуля?

Здравствуйте, kuj, Вы писали:

kuj>Я не завидую Вашим программистам БД.

Зря. Им хорошо платят и неплохо кормят

A>>ORM всего лишь обёртки для мапинга и сопутствующих операций.
kuj>Вам пора прочитать что такое OR/M.

Ну давай мерятся пиписьками. На вот
http://en.wikipedia.org/wiki/Object-relational_mapping
Что я сказал не так?

A>>Если транзакция нужна, а её нет ORM не спасёт.
kuj>Какие проблемы с транзакциями? OR/M отлично справляются с организацией транзакций.

БД справляется ещё лучше. Нельзя на ORM сваливать всё то, что лень было запрограммировать в БД, так как в результате ты получишь неповоротливую систему.

A>>Если делается выборка по неиндексированному столбцу ORM опять таки не спасёт. Спасают, в плане не дают облажатся, именно ХП.
kuj>Да что Вы говорите... А посмотреть статистику сервера по запросам и грамотно проставить индексы не судьба?

Ага, то есть предлагаешь отлаживаться на production сервере? Зашибись. А если вдруг выяснится что сама структура хранения неверная и надо не индексами манипулировать, а менять всё нафиг?

kuj>А то время, которые Ваши программисты тратят на поддержку монструозных нечитабельных нетестируемых ХП, можно было бы потратить на более тщательную проработку архитектуры базы и клиентов базы.

Нечитабельные ХП это миф. Нет никаких причин их так писать.

kuj>>>Потому и используют OR/M. Нету никаких таблиц. Нету никаких столбцов. Есть объекты DAL-уровня со свойствами. Есть соотвествующие объекты BLL уровня с бизнес логикой. Все связи минимальны благодаря IoC-контейнерам (Spring, Castle Windsor и т.п.). Код тщательно документируется. В наличии богатый IntelliSense инструментарий, фреймворки для тестирования типа nUnit с RhinoMocks, средства для автоматического создания документации, мощный отладчик, прекрасная читабельность кода, отсутствие привязки к конкретной БД и минимальная зависимость от схемы БД, высокая масштабируемость.

Ты опять употребляешь термин "масштабируемость", хотя кажется не понимаешь его смысла.

kuj>Вы хоть понимаете о чем говорите? Похоже, что не очень.

Я говорю о дураках, от которых надо защищатся. Вы, кажется исключительно с высококвалифицированными гениями не делающими ошибок работаете.

A>>Именно тот факт, что ORM являясь очень удобными средствами никак не контроллирующим разработчика и приводит к отказу от ORM в действительно крупных проектах.
kuj>Кто Вам эту чушь сказал?

Я тебе говорю. Никто в крупном проекте HQL не пользуется, это подходит только для какого-нибудь среднего онлайн-магазина.

A>>Когда БД растёт вместе с проектом и эта специфика меняется начинаются странные падения производительности "хотя совсем недавно всё работало". Получаем мину замедленного действия.
kuj>Чушь.

Ну значит не всречался. Я вот встречался.

A>>Единственное известно мне исключение — это BLT, но там просто функциональности недостаточно чтоб мины делать (хотя в том что BLT делает, она на высоте).
kuj>Не знаю, не работал с BLT и не слышал ни об одном более-менее крупном проекте на BLT.

Ну расширить твой кругозор не сложно. http://www.rsdn.ru/Forum/Info/FAQ.rfd.rfdprojects.aspx

Автор: IT
Дата: 03.07.05

A>>Смотря что делают хранимые процедуры. Конечно, если у тебя реализация вида 1запрос-1ХП, то пользы и от ХП мало и от их тестирования.
kuj>В том-то и дело, что хранимая процедура это черный ящик. В отличии от тестирования того же CLR — где можно делать mocking объектов. Вы пишете тест для процедуры, которая в свою очередь вызывает еще 20 процедур. В итоге Ваш тест тестирует не (только) эту процедуру, но и остальные 20. Поэтому для модульного тестирования 1 запрос — 1 ХП это вообще идеальный вариант.

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

A>>Если тебе не совсем плевать на производительность, то да.
kuj>А какие проблемы с производительностью?

Если ты пишешь SQL код работащий под несколько СУБД с минимальными правками, то наверняка не учитываешь особенности СУБД и не пользуешься всеми её возможностями. Как следствие — абсолютно неадекватная производительность.

kuj>Ну так и не используйте GUID. Какие проблемы?
Проблемы в том, что GUIS были нужны Других проблем нет.

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, Aviator, Вы писали:

A>>Код с классами подвергается чёткому структурированию и рефакторингу. Скрипты sql по своей природе плохочитаемы и не особо структурируются.

A>Может вы их не так пишете, что их сложнее читать? А то тебя послушать SQL какой-то язык-злодей. А народ активно пользуется, все ошибаются?

Вы ошибаетесь, думая что "народ активно пользуется". Ошибаетесь лет так на 7-8.

Здравствуйте, AndrewJD, Вы писали:

AJD>>>Успешно поддерживаем и развиваем. Кол-во ХП более 1150, таблиц более 400. ИМО ХП гораздо удобнее.
kuj>>Не завидую Вам. Честное слово. Наш проект на ХП с 800 процедур и 180 таблиц это сущая головная боль. Что-то в нем поменять почти не реально. Документации по нем кот наплакал...
AJD>Есть мнение что это связано больше с тем как поставлен процес разработки в компании, а не в преимуществе ХП vs запросы

ХП vs запросы? О чем Вы?

Здравствуйте, Aviator, Вы писали:

A>Это язык написания запросов, адаптированный для написания несложных скриптов. Он не предназначался для написания сложной логики.

Никто не говорит о выносе бизнес-логики в SQL. Речь идёт о том, чтобы не делать глупости вида SELECT * FROM everything, а потом разбирать это уровнем выше, потому что "SQL — плохой язык, Java — лучше". То что должно быть запрограммировано на SQL там и должно оставаться.

Здравствуйте, Aviator, Вы писали:

A>Ты искренне считаешь, что читать код на каком-нибудь transact-sql удобно?

Если тот, кто писал код позаботился об удобстве чтения (отступы, вменяемые имена, комментарии гед надо), то да.

A>Что ковыряться по куче процедур доставляет удовольствие?

I LOVE MY JOB! YAHO-O-O-O!

A>Что процедурное программирование не менее удобно чем объектное?

Зависит от контекста. Иногда объекты ни к селу, ни к городу. В реляционной БД я места ООП не вижу.

Здравствуйте, kuj, Вы писали:

kuj>Не завидую Вам. Честное слово. Наш проект на ХП с 800 процедур и 180 таблиц это сущая головная боль. Что-то в нем поменять почти не реально. Документации по нем кот наплакал...

Хранимки причём? Зачем свой единичный негативный опыт распространять на хранимые процедуры вообще?

Здравствуйте, Aviator, Вы писали:

A>Интересно, а как у вас организован процесс тестирования? Сидим тыкаем кнопари на формах и ждём что случится? И вообще, TDD наверно враги прогресса придумали?

Пошутил? Ха-ха. TDD замечательно бывает только на SQL. Ты кажется просто не умеешь тестрировать SQL-код.