Re[8]: Оформление работы с БД в корпоративных приложениях -
От: adontz Грузия http://adontz.wordpress.com/
Дата: 24.09.07 09:51
Оценка: 1 (1) -2
Здравствуйте, Aviator, Вы писали:

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


То что ты сказал не лишено смысла, но к SQL не имеет решительно никакого отношения. Если мостры SQL непредвиденно уходят, это не прослема SQL или ХП. И если они уходят ни оставив ни капли комментариев, документции и т.п. сколько-нибудь полезной тем, кто пришёл им на замену, то это тоже к SQL имеет слабое отношение.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[10]: Оформление работы с БД в корпоративных приложениях -
От: adontz Грузия http://adontz.wordpress.com/
Дата: 24.09.07 09:53
Оценка:
Здравствуйте, Aviator, Вы писали:

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


Может вы их не так пишете, что их сложнее читать? А то тебя послушать SQL какой-то язык-злодей. А народ активно пользуется, все ошибаются?
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[7]: Оформление работы с БД в корпоративных приложениях -
От: kuj  
Дата: 24.09.07 09:59
Оценка: 1 (1) :)
Здравствуйте, 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>>
  • Re[11]: Оформление работы с БД в корпоративных приложениях -
    От: Aviator  
    Дата: 24.09.07 09:59
    Оценка: :)
    Здравствуйте, adontz, Вы писали:

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

    Это язык написания запросов, адаптированный для написания несложных скриптов. Он не предназначался для написания сложной логики.
    Re[6]: Оформление работы с БД в корпоративных приложениях -
    От: AndrewJD США  
    Дата: 24.09.07 10:00
    Оценка: 40 (2) -1
    Здравствуйте, kuj, Вы писали:

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

    Успешно поддерживаем и развиваем. Кол-во ХП более 1150, таблиц более 400. ИМО ХП гораздо удобнее.
    "For every complex problem, there is a solution that is simple, neat,
    and wrong."
    Re[9]: Оформление работы с БД в корпоративных приложениях -
    От: Aviator  
    Дата: 24.09.07 10:04
    Оценка: :)
    Здравствуйте, adontz, Вы писали:

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


    Ты искренне считаешь, что читать код на каком-нибудь transact-sql удобно? Что ковыряться по куче процедур доставляет удовольствие? Что процедурное программирование не менее удобно чем объектное?
    Re[9]: Оформление работы с БД в корпоративных приложениях -
    От: kuj  
    Дата: 24.09.07 10:05
    Оценка:
    Здравствуйте, ilvi, Вы писали:

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


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

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

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

    Гораздо легче. Даже, если написано через пень-колоду, все-равно гораздо легче.
    ... << RSDN@Home 1.2.0 alpha rev. 746>>
    Re[7]: Оформление работы с БД в корпоративных приложениях -
    От: Aviator  
    Дата: 24.09.07 10:07
    Оценка: 1 (1) +1 -1
    Здравствуйте, AndrewJD, Вы писали:

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


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

    AJD>Успешно поддерживаем и развиваем. Кол-во ХП более 1150, таблиц более 400. ИМО ХП гораздо удобнее.
    Интересно, а как у вас организован процесс тестирования? Сидим тыкаем кнопари на формах и ждём что случится? И вообще, TDD наверно враги прогресса придумали?
    Re[7]: Оформление работы с БД в корпоративных приложениях -
    От: kuj  
    Дата: 24.09.07 10:12
    Оценка: -1
    Здравствуйте, AndrewJD, Вы писали:

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

    AJD>Успешно поддерживаем и развиваем. Кол-во ХП более 1150, таблиц более 400. ИМО ХП гораздо удобнее.

    Не завидую Вам. Честное слово. Наш проект на ХП с 800 процедур и 180 таблиц это сущая головная боль. Что-то в нем поменять почти не реально. Документации по нем кот наплакал...
    ... << RSDN@Home 1.2.0 alpha rev. 746>>
    Re[8]: Оформление работы с БД в корпоративных приложениях -
    От: Aviator  
    Дата: 24.09.07 10:15
    Оценка:
    Здравствуйте, kuj, Вы писали:

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


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

    AJD>>Успешно поддерживаем и развиваем. Кол-во ХП более 1150, таблиц более 400. ИМО ХП гораздо удобнее.

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

    Просто Вам наверно есть с чем сравнивать, а вот человеку видимо не с чем. Он искренне думает что лучше не бывает .
    Re[8]: Оформление работы с БД в корпоративных приложениях -
    От: AndrewJD США  
    Дата: 24.09.07 10:17
    Оценка:
    Здравствуйте, kuj, Вы писали:


    AJD>>Успешно поддерживаем и развиваем. Кол-во ХП более 1150, таблиц более 400. ИМО ХП гораздо удобнее.

    kuj>Не завидую Вам. Честное слово. Наш проект на ХП с 800 процедур и 180 таблиц это сущая головная боль. Что-то в нем поменять почти не реально. Документации по нем кот наплакал...
    Есть мнение что это связано больше с тем как поставлен процес разработки в компании, а не в преимуществе ХП vs запросы
    "For every complex problem, there is a solution that is simple, neat,
    and wrong."
    Re[9]: Оформление работы с БД в корпоративных приложениях -
    От: kuj  
    Дата: 24.09.07 10:18
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


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


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

    К слову, еще один минус хранимок — доп. нагрузка на сервер, что может стать критичной проблемой при большом количестве одновременно подключенных клиентов.
    ... << RSDN@Home 1.2.0 alpha rev. 746>>
    Re[8]: Оформление работы с БД в корпоративных приложениях -
    От: AndrewJD США  
    Дата: 24.09.07 10:20
    Оценка:
    Здравствуйте, Aviator, Вы писали:

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

    Как обычно, ежедневные автоматические тесты.

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

    TDD — серебрянная пуля?
    "For every complex problem, there is a solution that is simple, neat,
    and wrong."
    Re[8]: Оформление работы с БД в корпоративных приложениях -
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 24.09.07 10:20
    Оценка: -2
    Здравствуйте, 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 были нужны Других проблем нет.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[11]: Оформление работы с БД в корпоративных приложениях -
    От: kuj  
    Дата: 24.09.07 10:21
    Оценка: +1
    Здравствуйте, adontz, Вы писали:

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


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


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


    Вы ошибаетесь, думая что "народ активно пользуется". Ошибаетесь лет так на 7-8.
    ... << RSDN@Home 1.2.0 alpha rev. 746>>
    Re[9]: Оформление работы с БД в корпоративных приложениях -
    От: kuj  
    Дата: 24.09.07 10:21
    Оценка:
    Здравствуйте, AndrewJD, Вы писали:

    AJD>>>Успешно поддерживаем и развиваем. Кол-во ХП более 1150, таблиц более 400. ИМО ХП гораздо удобнее.

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

    ХП vs запросы? О чем Вы?
    ... << RSDN@Home 1.2.0 alpha rev. 746>>
    Re[12]: Оформление работы с БД в корпоративных приложениях -
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 24.09.07 10:23
    Оценка: :)
    Здравствуйте, Aviator, Вы писали:

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


    Никто не говорит о выносе бизнес-логики в SQL. Речь идёт о том, чтобы не делать глупости вида SELECT * FROM everything, а потом разбирать это уровнем выше, потому что "SQL — плохой язык, Java — лучше". То что должно быть запрограммировано на SQL там и должно оставаться.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[10]: Оформление работы с БД в корпоративных приложениях -
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 24.09.07 10:26
    Оценка: :))
    Здравствуйте, Aviator, Вы писали:

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


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

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


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

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


    Зависит от контекста. Иногда объекты ни к селу, ни к городу. В реляционной БД я места ООП не вижу.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[8]: Оформление работы с БД в корпоративных приложениях -
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 24.09.07 10:27
    Оценка:
    Здравствуйте, kuj, Вы писали:

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


    Хранимки причём? Зачем свой единичный негативный опыт распространять на хранимые процедуры вообще?
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[8]: Оформление работы с БД в корпоративных приложениях -
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 24.09.07 10:29
    Оценка: :))
    Здравствуйте, Aviator, Вы писали:

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


    Пошутил? Ха-ха. TDD замечательно бывает только на SQL. Ты кажется просто не умеешь тестрировать SQL-код.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Подождите ...
    Wait...
    Пока на собственное сообщение не было ответов, его можно удалить.