Здравствуйте, kuj, Вы писали:
kuj>Это как-раз проблема ХП и SQL. Процедуры на T-SQL имеют ужасную читабельность.
Не имеют. Это твоё личный опыт, вообще говоря это не так.
kuj>К слову, еще один минус хранимок — доп. нагрузка на сервер, что может стать критичной проблемой при большом количестве одновременно подключенных клиентов.
Здравствуйте, kuj, Вы писали:
kuj>ХП vs запросы? О чем Вы?
О отвоём коде btnLink_Click из первого сообщения, вероятно. Вообще забавно, что человек строящий команду в обработчике кнопки являтся адептом ORM. Что-то тут не так.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, Aviator, Вы писали:
A>>Это язык написания запросов, адаптированный для написания несложных скриптов. Он не предназначался для написания сложной логики.
A>Никто не говорит о выносе бизнес-логики в SQL. Речь идёт о том, чтобы не делать глупости вида SELECT * FROM everything, а потом разбирать это уровнем выше, потому что "SQL — плохой язык, Java — лучше". То что должно быть запрограммировано на SQL там и должно оставаться.
Ы чём заключается обозначенная глупость? Я чё та не понял.
Re[14]: Оформление работы с БД в корпоративных приложениях -
Здравствуйте, Aviator, Вы писали:
A>>Никто не говорит о выносе бизнес-логики в SQL. Речь идёт о том, чтобы не делать глупости вида SELECT * FROM everything, а потом разбирать это уровнем выше, потому что "SQL — плохой язык, Java — лучше". То что должно быть запрограммировано на SQL там и должно оставаться. A>Ы чём заключается обозначенная глупость? Я чё та не понял.
Ну и о чём тогда говорить, если ты не понимаешь что такое БД и зачем она нужна?
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, kuj, Вы писали:
kuj>>Это как-раз проблема ХП и SQL. Процедуры на T-SQL имеют ужасную читабельность.
A>Не имеют. Это твоё личный опыт, вообще говоря это не так.
kuj>>К слову, еще один минус хранимок — доп. нагрузка на сервер, что может стать критичной проблемой при большом количестве одновременно подключенных клиентов.
A>Это бред полнейший.
Не бред, вы с Вашими любимыми хранимками привязаны к одному серверу СУБД. Мне ничего не мешает распаралелить ряд операций по различным серверам.
Re[9]: Оформление работы с БД в корпоративных приложениях -
Здравствуйте, AndrewJD, Вы писали:
AJD>Здравствуйте, Aviator, Вы писали:
A>>Интересно, а как у вас организован процесс тестирования? Сидим тыкаем кнопари на формах и ждём что случится? AJD>Как обычно, ежедневные автоматические тесты.
A>>И вообще, TDD наверно враги прогресса придумали? AJD>TDD — серебрянная пуля?
просто писать юнит тесты на каком нить c# с заглушками намного проще чем организовывать автоматическое тестирование кода совместно с субд ...
Re[9]: Оформление работы с БД в корпоративных приложениях -
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, Aviator, Вы писали:
A>>Интересно, а как у вас организован процесс тестирования? Сидим тыкаем кнопари на формах и ждём что случится? И вообще, TDD наверно враги прогресса придумали?
A>Пошутил? Ха-ха. TDD замечательно бывает только на SQL. Ты кажется просто не умеешь тестрировать SQL-код.
А ты умеешь?
Re[12]: Оформление работы с БД в корпоративных приложениях -
Здравствуйте, Aviator, Вы писали:
A>>Это бред полнейший. A>Не бред, вы с Вашими любимыми хранимками привязаны к одному серверу СУБД. Мне ничего не мешает распаралелить ряд операций по различным серверам.
Я распределить нагрузку на уровне СУБД не судьба? СУБД не кластеризуются? Я же говорю, что ты СУБД никогда и не видел толком...
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, Aviator, Вы писали:
A>>>Никто не говорит о выносе бизнес-логики в SQL. Речь идёт о том, чтобы не делать глупости вида SELECT * FROM everything, а потом разбирать это уровнем выше, потому что "SQL — плохой язык, Java — лучше". То что должно быть запрограммировано на SQL там и должно оставаться. A>>Ы чём заключается обозначенная глупость? Я чё та не понял.
A>Ну и о чём тогда говорить, если ты не понимаешь что такое БД и зачем она нужна?
Я Вас и не заставляю ничего говорить Пишите дальше хранимки, пока ещё есть кого заставить их поддерживать.
Re[10]: Оформление работы с БД в корпоративных приложениях -
Здравствуйте, Aviator, Вы писали:
A>>Пошутил? Ха-ха. TDD замечательно бывает только на SQL. Ты кажется просто не умеешь тестрировать SQL-код. A>А ты умеешь?
В мои объязанности не входит их написание, но они есть и, видимо, не с неба упали. Что касается навыка, да я себе достаточно чётко представляю что это такое и как это делать.
Здравствуйте, adontz, Вы писали:
A>>Не бред, вы с Вашими любимыми хранимками привязаны к одному серверу СУБД. Мне ничего не мешает распаралелить ряд операций по различным серверам. A>Я распределить нагрузку на уровне СУБД не судьба? СУБД не кластеризуются? Я же говорю, что ты СУБД никогда и не видел толком...
Ага а не приходило в голову, что это не самый гибкий подход к построению распределённого приложения?
Re[11]: Оформление работы с БД в корпоративных приложениях -
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, Aviator, Вы писали:
A>>>Пошутил? Ха-ха. TDD замечательно бывает только на SQL. Ты кажется просто не умеешь тестрировать SQL-код. A>>А ты умеешь?
A>В мои объязанности не входит их написание, но они есть и, видимо, не с неба упали. Что касается навыка, да я себе достаточно чётко представляю что это такое и как это делать.
Ну разъясните будьте любезны нам неразумным, даже интересно стало. Даже можно с примерами кода.
Re[16]: Оформление работы с БД в корпоративных приложениях -
Здравствуйте, Aviator, Вы писали:
A>>Ну и о чём тогда говорить, если ты не понимаешь что такое БД и зачем она нужна? A>Я Вас и не заставляю ничего говорить Пишите дальше хранимки, пока ещё есть кого заставить их поддерживать.
Пишите дальше SELECT *. Хорошим примером такого способа хранения данных являетс 1С. Вроде бы и в БД всё, но толку от этого никакого. 2процессорный, многоядерный, 4Гб, супер-пупер сервер едва держит 10 клиентских соединений. Вы кажется в эту категорию спешите записаться.
Здравствуйте, Aviator, Вы писали:
A>просто писать юнит тесты на каком нить c# с заглушками намного проще чем организовывать автоматическое тестирование кода совместно с субд ...
Если сравнивать тестирование одной и той же задачи, то абсолютно всё равно.
Здравствуйте, adontz, Вы писали:
kuj>>Я не завидую Вашим программистам БД.
A>Зря. Им хорошо платят и неплохо кормят
Не сомневаюсь. Надбавка за вредность должна быть ну очччччень хорошей.
A>>>ORM всего лишь обёртки для мапинга и сопутствующих операций. kuj>>Вам пора прочитать что такое OR/M.
A>Ну давай мерятся пиписьками. На вот A>http://en.wikipedia.org/wiki/Object-relational_mapping A>Что я сказал не так?
Прочитайте хотя бы http://www.hibernate.org/15.html
ORM это гораздо больше, чем "всего лишь мапинг и сопутствующие операции".
A>>>Если транзакция нужна, а её нет ORM не спасёт. kuj>>Какие проблемы с транзакциями? OR/M отлично справляются с организацией транзакций.
A>БД справляется ещё лучше. Нельзя на ORM сваливать всё то, что лень было запрограммировать в БД, так как в результате ты получишь неповоротливую систему.
Ликбез: транзакции выполняются на сервере. Только на сервере. Поэтому нет никакого "лучше" / "хуже".
Вот как это делается в Hibernate http://www.hibernate.org/hib_docs/v3/reference/en/html/transactions.html
A>>>Если делается выборка по неиндексированному столбцу ORM опять таки не спасёт. Спасают, в плане не дают облажатся, именно ХП. kuj>>Да что Вы говорите... А посмотреть статистику сервера по запросам и грамотно проставить индексы не судьба?
A>Ага, то есть предлагаешь отлаживаться на production сервере? Зашибись.
Это т.н. tuning и ничего отлаживать не надо. Есть статистика, которая собирается самой СУБД. Надо проанализировать ее и решить каких индексов не хватает, а какие надо выкинуть.
A>А если вдруг выяснится что сама структура хранения неверная и надо не индексами манипулировать, а менять всё нафиг?
И? Чем Вам тут ХП помогут?
kuj>>А то время, которые Ваши программисты тратят на поддержку монструозных нечитабельных нетестируемых ХП, можно было бы потратить на более тщательную проработку архитектуры базы и клиентов базы.
A>Нечитабельные ХП это миф. Нет никаких причин их так писать.
Их сложно писать не "так" в силу синтаксиса и убогости T-SQL.
kuj>>>>Потому и используют OR/M. Нету никаких таблиц. Нету никаких столбцов. Есть объекты DAL-уровня со свойствами. Есть соотвествующие объекты BLL уровня с бизнес логикой. Все связи минимальны благодаря IoC-контейнерам (Spring, Castle Windsor и т.п.). Код тщательно документируется. В наличии богатый IntelliSense инструментарий, фреймворки для тестирования типа nUnit с RhinoMocks, средства для автоматического создания документации, мощный отладчик, прекрасная читабельность кода, отсутствие привязки к конкретной БД и минимальная зависимость от схемы БД, высокая масштабируемость.
A>Ты опять употребляешь термин "масштабируемость", хотя кажется не понимаешь его смысла.
Да, Вам только кажется.
kuj>>Вы хоть понимаете о чем говорите? Похоже, что не очень.
A>Я говорю о дураках, от которых надо защищатся. Вы, кажется исключительно с высококвалифицированными гениями не делающими ошибок работаете.
Вот именно. Ваш проект на ХП имеет минимум "защиты от дурака". У нас активно применяется TDD, что фактически не возможно было бы, если бы проект был с использованием ХП.
A>>>Именно тот факт, что ORM являясь очень удобными средствами никак не контроллирующим разработчика и приводит к отказу от ORM в действительно крупных проектах. kuj>>Кто Вам эту чушь сказал?
A>Я тебе говорю. Никто в крупном проекте HQL не пользуется, это подходит только для какого-нибудь среднего онлайн-магазина.
Нда......
A>>>Единственное известно мне исключение — это BLT, но там просто функциональности недостаточно чтоб мины делать (хотя в том что BLT делает, она на высоте). kuj>>Не знаю, не работал с BLT и не слышал ни об одном более-менее крупном проекте на BLT.
A>Ну расширить твой кругозор не сложно. http://www.rsdn.ru/Forum/Info/FAQ.rfd.rfdprojects.aspx
Это "впечатляет".
A>>>Смотря что делают хранимые процедуры. Конечно, если у тебя реализация вида 1запрос-1ХП, то пользы и от ХП мало и от их тестирования. kuj>>В том-то и дело, что хранимая процедура это черный ящик. В отличии от тестирования того же CLR — где можно делать mocking объектов. Вы пишете тест для процедуры, которая в свою очередь вызывает еще 20 процедур. В итоге Ваш тест тестирует не (только) эту процедуру, но и остальные 20. Поэтому для модульного тестирования 1 запрос — 1 ХП это вообще идеальный вариант.
A>То что ты написал это полный бред. Получается нельзя тестировать методы классов вызывающие другие методы. Тесты для ХП пишет тот жекто и ХП, для него она не чёрный ящик. А вот тот факт, что ХП чёрный ящик для всех остальных меня радует. Примерно так же как модификатор private. Инкапсуляция... слышал?
Прочитайте чтоли про mocking объектов (RhinoMocks лучшая известная мне реализация) и unit testing, а так же о TDD...
Вы явно не понимаете о чем речь.
A>>>Если тебе не совсем плевать на производительность, то да. kuj>>А какие проблемы с производительностью?
A>Если ты пишешь SQL код работащий под несколько СУБД с минимальными правками, то наверняка не учитываешь особенности СУБД и не пользуешься всеми её возможностями. Как следствие — абсолютно неадекватная производительность.
Вы кажется не поняли. Я не пишу код под несколько СУБД. Я пишу DAL`ы с использованием (N)Hibernate и Castle ActiveRecord. С проблемами производительности мы пока не сталкивались.
kuj>>Ну так и не используйте GUID. Какие проблемы? A>Проблемы в том, что GUIS были нужны Других проблем нет.
Кстати, а при чем тут MySql? MySQL это вообще СУБД для других целей и мало подходит для "БД в корпоративных приложениях".
... << RSDN@Home 1.2.0 alpha rev. 746>>
Re[10]: Оформление работы с БД в корпоративных приложениях -
Здравствуйте, Aviator, Вы писали:
A>>Я распределить нагрузку на уровне СУБД не судьба? СУБД не кластеризуются? Я же говорю, что ты СУБД никогда и не видел толком... A>Ага а не приходило в голову, что это не самый гибкий подход к построению распределённого приложения?
Как раз это самый гибкий, рабить BL и DAL на разные tier, сделать BL максимально stateless (по крайней мере не кешируещим) и получить щасте. BL для кластеризации начитает хватать обычного NLB, DAL кластеризуется средствами БД. Получаем двухуровневую систему кластеров. В каждый уровень можно досбавлять кластеры по мере необходимости. Весьма гибко.
Здравствуйте, adontz, Вы писали:
kuj>>ХП vs запросы? О чем Вы?
A>О отвоём коде btnLink_Click из первого сообщения, вероятно. Вообще забавно, что человек строящий команду в обработчике кнопки являтся адептом ORM. Что-то тут не так.
О каком-таком моем коде? Окститесь.
... << RSDN@Home 1.2.0 alpha rev. 746>>
Re[9]: Оформление работы с БД в корпоративных приложениях -
Здравствуйте, adontz, Вы писали:
kuj>>Не завидую Вам. Честное слово. Наш проект на ХП с 800 процедур и 180 таблиц это сущая головная боль. Что-то в нем поменять почти не реально. Документации по нем кот наплакал...
A>Хранимки причём? Зачем свой единичный негативный опыт распространять на хранимые процедуры вообще?
При том, что ХП сложно документировать, сложно читать, сложно тестировать, сложно отлаживать.
... << RSDN@Home 1.2.0 alpha rev. 746>>
Re[11]: Оформление работы с БД в корпоративных приложениях -
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, Aviator, Вы писали:
A>>Ты искренне считаешь, что читать код на каком-нибудь transact-sql удобно?
>>Если тот, кто писал код позаботился об удобстве чтения (отступы, вменяемые имена, комментарии гед надо), то да.
Да отступы и комментарии — это конечно залог читаемости кода .
A>>Что ковыряться по куче процедур доставляет удовольствие? A>I LOVE MY JOB! YAHO-O-O-O!
Ну учитывая что вы заставляете этим заниматься кого то другого вполне так оно и есть
A>>Что процедурное программирование не менее удобно чем объектное? A>Зависит от контекста. Иногда объекты ни к селу, ни к городу. В реляционной БД я места ООП не вижу.
Реляционная БД — это всего лишь хранилище данных, Вы путаете задачу хранения и обработки. Споры вызывает то, что Вы хотите на хранилище возложить ещё и функции обработки. Разработчика бизнес логики в большинстве случев вообще не интересует какая там субд и как она сохраняет, он оперирует доменными объектами.
...
