Здравствуйте, kuj, Вы писали:
kuj>При чем тут кеш второго уровня? oO
Я не знаю, это твой вечный аргумент. Чтобы я не сказал, ыт мне тычешь под нос кешем второго уровня.
kuj>И с чего Вы решили, что транзакции БД это единственный способ организации бизнес-транзакций?
Во-первых, я этого не говорил.
Во-вторых, утвержнение не верное. Транзакции БД это не просто не единственный способ, это не способ вовсе.
kuj>Разберитесь сначала в терминологии и не сваливайте все в одну кучу.
Здравствуйте, Sinclair, Вы писали:
S>В теории всё должно работать так же, как и везде: S>1. создали тестовую БД S>2. наполнили ее тестовыми данными S>3. прогнали набор тестовых операций S>4. проверили нужные ассерты. S>Я не вижу принципиальной разницы в сложности п.3 для ХП и ORM. Вся сложность обвчно в п.2. Если его выполнить, остальное сработает примерно одинаково.
Да, а как вы в процедурах делаете mocking? Или у вас все процедуры без зависимостей от других процедур и зависят исключительно от данных в БД?
Проблема с тестированием того же в DAL в ORM связанна непосредственно с БД. Тесты сами по себе могут менять состояние БД. Тестов много и они должны отрабатывать быстро и при этом БД нужно возвращать в исходное состояние каждый раз. Для больших проектов прогонка полного комплекта тестов на DAL может занимать часы, что мягко говоря не способствует их частой прогонке.
S>Поэтому сейчас появляются инструменты тестирования data-приложений, которые делают именно так. Например, MS VS for Database Professionals. Там можно тестовые данные генерить, можно снимать образец с production базы. Можно делать нагрузочное тестирование и проверять плазы запросов. И всё это в том числе автоматически и по расписанию.
Вот это уже интересно и по делу. Будем почитать.
... << RSDN@Home 1.2.0 alpha rev. 746>>
Re[19]: Оформление работы с БД в корпоративных приложениях -
Здравствуйте, adontz, Вы писали:
A>Даже если на 5 минут сойти с ума и предположить что ты прав, это всё равно не корректный способ сравнения — считать ключевые слова относящиеся к той или иной обласни. SELECT пишется гораздо гаще, на порядки чаще, чем CREATE, а исполняется в миллиарды раз чаще.
Не спорьте, вы оба правы Классический ANSI SQL — это декларативный язык.
T-SQL и PL/SQL кроме декларативного SQL еще поддерживают и императивные конструкции (циклы, сравнения, ветвления, присваивания).
Sapienti sat!
Re[27]: Оформление работы с БД в корпоративных приложениях -
Здравствуйте, adontz, Вы писали:
kuj>>При чем тут кеш второго уровня? oO
A>Я не знаю, это твой вечный аргумент. Чтобы я не сказал, ыт мне тычешь под нос кешем второго уровня.
Ну так разберитесь сначала с тем, что есть кеш второго уровня в Hibernate и зачем он нужен. К транзакциям же он никакого отношения не имеет.
kuj>>И с чего Вы решили, что транзакции БД это единственный способ организации бизнес-транзакций?
A>Во-первых, я этого не говорил. A>Во-вторых, утвержнение не верное. Транзакции БД это не просто не единственный способ, это не способ вовсе.
Рад, что Вы наконец хоть с этим разобрались.
... << RSDN@Home 1.2.0 alpha rev. 746>>
Re[19]: Оформление работы с БД в корпоративных приложениях -
kuj>>декларативное: kuj>>SELECT ...
kuj>>императивное: kuj>>CREATE TABLE, VIEW, INDEX, ... kuj>>DROP TABLE, VIEW, INDEX, ... kuj>>Так понятнее?
A>Так не понятнее, потому что глупость. DDL не является императивной частью, он точно такая же декларативная часть. Ты указываешь конечный результат — таблицу, а не пришешь генерацию внутреней структуры файлов: записей, индексов.
О да, по Вашей логике получается, что
MessageBox m = new MessageBox()
Это тоже декларативная конструкция, т.к. я "указываю на конечный результат" — MessageBox. Верно?
Почитайте определение императивного языка. Может поймете все же... А еще лучше изучите Prolog.
A>Даже если на 5 минут сойти с ума и предположить что ты прав, это всё равно не корректный способ сравнения — считать ключевые слова относящиеся к той или иной обласни. SELECT пишется гораздо гаще, на порядки чаще, чем CREATE, а исполняется в миллиарды раз чаще.
Хорошо, тогда ответьте мне, а HTML тоже является декларативным языком программирования?
... << RSDN@Home 1.2.0 alpha rev. 746>>
Re[10]: Оформление работы с БД в корпоративных приложениях -
Здравствуйте, kuj, Вы писали: S>>Я не вижу принципиальной разницы в сложности п.3 для ХП и ORM. Вся сложность обвчно в п.2. Если его выполнить, остальное сработает примерно одинаково. kuj>Да, а как вы в процедурах делаете mocking? Или у вас все процедуры без зависимостей от других процедур и зависят исключительно от данных в БД?
Ну, вообще-то мокинг процедур, имхо, сделать вообще нереально. В том-то и дело, что в отличие от хорошо структурированных программ, базы данных имеют дело с shared state. Собственно, одна хранимка потребляет результаты другой исключительно в виде произведенных ею изменений в разделяемых данных. Я имею в виду ХП в смысле MS SQL Server. То, что в IB/FB делается через suspend я предпочитаю называть table-valued функциями, и я вовсе не уверен, что их вообще имеет смысл подменять моками при тестировании. Речь идет о том, что мы тестируем не отдельную хранимку, а поведение всей системы. И по-другому нельзя. По хорошему это именно так: подняли сервер, наколотили в него тестовых данных, выполнили набор SOAP вызовов.
С юнит-тестами тут тяжко, я вообще не очень понимаю, как можно что-то в базе заюниттестить. Не изолируется потому что нифига.
kuj>Проблема с тестированием того же в DAL в ORM связанна непосредственно с БД. Тесты сами по себе могут менять состояние БД. Тестов много и они должны отрабатывать быстро и при этом БД нужно возвращать в исходное состояние каждый раз. Для больших проектов прогонка полного комплекта тестов на DAL может занимать часы, что мягко говоря не способствует их частой прогонке.
Вообще говоря, прогон тестов раз в сутки — вполне достаточно. По сравнению с ручным тестированием, один цикл которого у нас занимает примерно три недели, это недостижимая мечта.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[17]: Оформление работы с БД в корпоративных приложениях -
Здравствуйте, adontz, Вы писали:
kuj>>В том и проблема, что тестировать процедуры самописными приложениями полноценно не выйдет. Для тестирования CLR у меня есть средства для мокинга, благодаря которым я могу тестировать конкретно нужный мне метод, а не этот метод И все методы, которые он вызывает, как пример.
A>Ты видимо не очень это понимаешь, но SQL и обсуждемые расширения с диалектами не являются ОО, а значит мок-объекты им не светят. По определению. A>Кроме того, если мы говорим о тестировании, БД не являются сущностями, которые можно протестировать полностью. По той же причине, что и многопоточные приложения, например.
Рад, что вы хоть в чем-то разобрались со вчерашнего дня. Данный спор идет Вам на пользу:
"Кроме того, использование ХП позволяем автоматически тестировать самый низкоуровневый код работы с данными. Это особенно актуально при изменении схемы (добавлении столбца, а то и таблицы). "
... << RSDN@Home 1.2.0 alpha rev. 746>>
Re[20]: Оформление работы с БД в корпоративных приложениях -
Здравствуйте, kuj, Вы писали:
kuj>MessageBox m = new MessageBox() kuj>Это тоже декларативная конструкция, т.к. я "указываю на конечный результат" — MessageBox. Верно?
Нет. Тут явный вызов функции.
kuj>Хорошо, тогда ответьте мне, а HTML тоже является декларативным языком программирования?
Декларативный — да, язык программирования — нет. HTML определяет статическую структуру документа (вместе с CSS — конечный автомат), а не какие-либо действия.
Здравствуйте, kuj, Вы писали:
A>>Во-первых, я этого не говорил. A>>Во-вторых, утвержнение не верное. Транзакции БД это не просто не единственный способ, это не способ вовсе. kuj>Рад, что Вы наконец хоть с этим разобрались.
Я? Это ты разобрался. 12 часов назад ты утверждал что бизнес-транзакций вовсе нет!
Здравствуйте, kuj, Вы писали:
A>>Кроме того, если мы говорим о тестировании, БД не являются сущностями, которые можно протестировать полностью. По той же причине, что и многопоточные приложения, например. kuj>Рад, что вы хоть в чем-то разобрались со вчерашнего дня. Данный спор идет Вам на пользу: kuj>"Кроме того, использование ХП позволяем автоматически тестировать самый низкоуровневый код работы с данными. Это особенно актуально при изменении схемы (добавлении столбца, а то и таблицы). "
Ты всё вечно читаешь не так как написано, а так хочется твоему эго. Не полностью тестируемые не означает не тестируемые вовсе.
Здравствуйте, Sinclair, Вы писали:
S>>>Я не вижу принципиальной разницы в сложности п.3 для ХП и ORM. Вся сложность обвчно в п.2. Если его выполнить, остальное сработает примерно одинаково. kuj>>Да, а как вы в процедурах делаете mocking? Или у вас все процедуры без зависимостей от других процедур и зависят исключительно от данных в БД? S>Ну, вообще-то мокинг процедур, имхо, сделать вообще нереально. В том-то и дело, что в отличие от хорошо структурированных программ, базы данных имеют дело с shared state. Собственно, одна хранимка потребляет результаты другой исключительно в виде произведенных ею изменений в разделяемых данных. Я имею в виду ХП в смысле MS SQL Server. То, что в IB/FB делается через suspend я предпочитаю называть table-valued функциями, и я вовсе не уверен, что их вообще имеет смысл подменять моками при тестировании. Речь идет о том, что мы тестируем не отдельную хранимку, а поведение всей системы. И по-другому нельзя. По хорошему это именно так: подняли сервер, наколотили в него тестовых данных, выполнили набор SOAP вызовов. S>С юнит-тестами тут тяжко, я вообще не очень понимаю, как можно что-то в базе заюниттестить. Не изолируется потому что нифига.
Все верно. Потому я и считаю, что в случае корпоративных приложений БД следует использовать исключительно как хранилище информации — без хранимых процедур и триггеров.
kuj>>Проблема с тестированием того же в DAL в ORM связанна непосредственно с БД. Тесты сами по себе могут менять состояние БД. Тестов много и они должны отрабатывать быстро и при этом БД нужно возвращать в исходное состояние каждый раз. Для больших проектов прогонка полного комплекта тестов на DAL может занимать часы, что мягко говоря не способствует их частой прогонке. S>Вообще говоря, прогон тестов раз в сутки — вполне достаточно. По сравнению с ручным тестированием, один цикл которого у нас занимает примерно три недели, это недостижимая мечта.
В том то и дело, что прогон раз в сутки часто не достаточно. В идеале тесты должны прогоняться после малейшего изменения. Потому и необходимо столь жесткое разделение на слои и домены: хранилище — DAL — BLL — ...
... << RSDN@Home 1.2.0 alpha rev. 746>>
Re[19]: Оформление работы с БД в корпоративных приложениях -
A>>>Кроме того, если мы говорим о тестировании, БД не являются сущностями, которые можно протестировать полностью. По той же причине, что и многопоточные приложения, например. kuj>>Рад, что вы хоть в чем-то разобрались со вчерашнего дня. Данный спор идет Вам на пользу:
kuj>>"Кроме того, использование ХП позволяем автоматически тестировать самый низкоуровневый код работы с данными. Это особенно актуально при изменении схемы (добавлении столбца, а то и таблицы). "
A>Ты всё вечно читаешь не так как написано, а так хочется твоему эго. Не полностью тестируемые не означает не тестируемые вовсе.
То есть ХП уже не тестируемые вовсе? Как полярно у Вас поменялось мнение... Надо же.
... << RSDN@Home 1.2.0 alpha rev. 746>>
Re[21]: Оформление работы с БД в корпоративных приложениях -
Здравствуйте, adontz, Вы писали:
kuj>>MessageBox m = new MessageBox() kuj>>Это тоже декларативная конструкция, т.к. я "указываю на конечный результат" — MessageBox. Верно?
A>Нет. Тут явный вызов функции.
Где там явный вызов функции и чем это отличается от CREATE TABLE?
CREATE TABLE ...
CREATE INDEX ...
CREATE VIEW ...
— абсолютно императивная конструкция, описывающая логическую последовательность действий, которую необходимо выполнить.
При декларативном программировании нет никаких последовательностей действий, потому и порядок не имеет роли.
Декларативное программирование, это например
predicates
term (real, string)
clauses
term (T, "Лёд"):- T<=0.
term (T, "Жидкость"):- T>0, T<=100.
term (T, "Пар"):- T>100.
Так понятно?
... << RSDN@Home 1.2.0 alpha rev. 746>>
Re[20]: Оформление работы с БД в корпоративных приложениях -
Здравствуйте, adontz, Вы писали: A>Если бы T-SQL был чисто императивным процедурным языком, то тебе вместо декларативного описания результата запроса пришлось бы императивно определять план его исполнения. Этого не наблюдается.
Да-да. Неверящим в императивные языки программирования СУБД рекомендую ознакомиться c dBase/Clipper и посмотреть, как выполнялись всякие джойны и прочее в до-SQL эпоху.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[12]: Оформление работы с БД в корпоративных приложениях -
Здравствуйте, kuj, Вы писали: kuj>В том то и дело, что прогон раз в сутки часто не достаточно. В идеале тесты должны прогоняться после малейшего изменения. Потому и необходимо столь жесткое разделение на слои и домены: хранилище — DAL — BLL — ...
На доступном мне уровне развития науки, сие для БД-ориентированных приложений решительно невозможно. Даже не-БД тестировать "после малейшего изменения" нереально, т.к. банальная сборка мало-мальски сложного проекта начинает занимать больше времени, чем проходит между коммитами в SVN.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[29]: Оформление работы с БД в корпоративных приложениях -
A>>>Во-первых, я этого не говорил. A>>>Во-вторых, утвержнение не верное. Транзакции БД это не просто не единственный способ, это не способ вовсе. kuj>>Рад, что Вы наконец хоть с этим разобрались.
A>Я? Это ты разобрался. 12 часов назад ты утверждал что бизнес-транзакций вовсе нет!
Не перекручивайте слова.
A>>Если транзакция нужна, а её нет ORM не спасёт. kuj>Какие проблемы с транзакциями? OR/M отлично справляются с организацией транзакций.
БД справляется ещё лучше. Нельзя на ORM сваливать всё то, что лень было запрограммировать в БД, так как в результате ты получишь неповоротливую систему.
----------
---------- A>>>ОМГ. У тебя есть две машины, на одной всё что на java, на воторой SQL-сервер. Это достаточно стандартная схема. C>>У меня вот два сервера БД (кластер с failover) и 3 app-сервера в качестве front-end'ов. Все прекрасно работает с Hibernate.
A>Почетай выше о чём вообще речь, kuj совсем не понимает чем транзакции уровня БД отличаются от транзакций уровня бизнес-логики.
Транзакции уровня бизнес-логики? Вот это круто. Вы это только что придумали?
----------
На что Вы в дальнейшем сказали:
---------- kuj>И с чего Вы решили, что транзакции БД это единственный способ организации бизнес-транзакций?
Во-первых, я этого не говорил.
Во-вторых, утвержнение не верное. Транзакции БД это не просто не единственный способ, это не способ вовсе.
----------
Мухи отдельно, котлеты отдельно, да?
... << RSDN@Home 1.2.0 alpha rev. 746>>
Re[13]: Оформление работы с БД в корпоративных приложениях -
kuj>>В том то и дело, что прогон раз в сутки часто не достаточно. В идеале тесты должны прогоняться после малейшего изменения. Потому и необходимо столь жесткое разделение на слои и домены: хранилище — DAL — BLL — ... S>На доступном мне уровне развития науки, сие для БД-ориентированных приложений решительно невозможно. Даже не-БД тестировать "после малейшего изменения" нереально, т.к. банальная сборка мало-мальски сложного проекта начинает занимать больше времени, чем проходит между коммитами в SVN.
А почему Вы решили, что нужно собирать весь проект?
... << RSDN@Home 1.2.0 alpha rev. 746>>
Re: Оформление работы с БД в корпоративных приложениях - как
ОЧЕНЬ хотелось бы попросить, чтобы вы привели примеры кода, с разных уровней, т.е. как выглядит код в уровне GUI (в обработчиках кнопок например), этот код будет взаимодействовать с объектами из следующего уровня — приведите код из следующего уровня и т.д. Т.е. чтобы можно было кратко представить целую картину по оформлению работы с БД в приложении. А то сейчас все довольно абстрагировано, по крайней мере для меня — человека НЕ С ВАШИМ уровнем и опытом.
Это относится к обоим выделившимся сторонам обсуждения (Adontz и все остальные .
Вы конечно ничего никому не обязаны объяснять, но вот вам не жалко тратить ЧАСЫ на ведение этого спора, а несколько минут потратить чтобы вернуться к теме привести примеры — жалко?
Заранее спасибо...
Re[21]: Оформление работы с БД в корпоративных приложениях -
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, adontz, Вы писали: A>>Если бы T-SQL был чисто императивным процедурным языком, то тебе вместо декларативного описания результата запроса пришлось бы императивно определять план его исполнения. Этого не наблюдается. S>Да-да. Неверящим в императивные языки программирования СУБД рекомендую ознакомиться c dBase/Clipper и посмотреть, как выполнялись всякие джойны и прочее в до-SQL эпоху.
Ну работал я с таким АПИ без sql со старой СУБД. Но это никак не означает, что t-sql декалартивный язык .
Re[20]: Оформление работы с БД в корпоративных приложениях -
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, adontz, Вы писали:
A>>Даже если на 5 минут сойти с ума и предположить что ты прав, это всё равно не корректный способ сравнения — считать ключевые слова относящиеся к той или иной обласни. SELECT пишется гораздо гаще, на порядки чаще, чем CREATE, а исполняется в миллиарды раз чаще. C>Не спорьте, вы оба правы Классический ANSI SQL — это декларативный язык.
C>T-SQL и PL/SQL кроме декларативного SQL еще поддерживают и императивные конструкции (циклы, сравнения, ветвления, присваивания).
Только проблема в том, что в хранимках плотность императивных конструкций максимальна.
.
