Оформление работы с БД в корпоративных приложениях - как? - Архитектура программного обеспечения

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

kuj>>Бизнес-логика ничего. Абсолютно ничего о транзакциях знать не должна. Для этого есть DAL, который управляет транзакциями, где это необходимо.
S>Ну, лично мне это странно слышать. Есть, конечно, "технические" транзакции (типа коммит после каждой записи лога, чтобы обеспечить максимум информации в случае сбоя), но в основном "ноги" у транзакций растут именно из бизнеса. Сам бизнес рассматривается как набор процессов, которые представляют собой цепочки транзакций.
S>При этом в бизнес-транзакцию в отличие от того, что происходит по begin tran, может включаться много всяких ресурсов. Например, транзакция "обработка заказа" может включать в себя, помимо записи чего-то в базу, поиск товара на складе, упаковку его в тару и передачу в транспортную компанию, а также отправку емейла. И всё это должно удовлетворять требованиям ACID. Именно бизнес определяет, не поделить ли этот процесс на другие транзакции — например, для оптимизации выделить передачу в транспортную компанию в отдельную транзакцию.

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

Вот тут:

Re[8]: Оформление работы с БД в корпоративных приложениях -

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

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

A>>Практически к любой ORM можно прикрутить поддержку практически любой БД.
A>Да, може тогда поможете мне прикрутить поддержку диалекта FB к одному из симпатичных мапперов без данной поддержки?

Если ORM поддерживает подобные расширения (нормальная поддерживает), то не вижу проблем в решении этой здачи. Мапер BLT изначально писалься для MSSQL, но потом добавился Оракл, народ с MySql использует, про тот же firebird что-то слышал но не уверен.
По поводу вопроса — вряд ли. Я с Firebird не работал, пользы от меня в такой задаче будет крайне мало.

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

S>Декларативность языка, говоря неформально — это описание того, что нужно получить, а не как.

Наличие декларативных элементов не делает язык декларативным. А то мы и C# можем обозвать декларативным следуя этой логике.

S>В этом смысле и Пролог, и SQL вполне себе декларативны.

SQL не является декларативным языком программирования потому, что он не является языком программирования ВООБЩЕ.

http://ru.wikipedia.org/wiki/SQL

S>Более того, Пролог тоже является информационно-логическим языком, если говорить о более формальной классификации.

Не понял с чего Вы решили, что Пролог является информационно-логическим языком?

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

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

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

kuj это в народе называется прыгать на словах. Вот тут, несколькими сообщениями выше
http://www.rsdn.ru/forum/message/2669032.1.aspx
ты утверждал что бизнес-транзакций нет. А сейчас вдруг выяснил что они есть, но не тоже самое, что БД-транзакции. Я конечно рад, что ты так быстро умнеешь, но всё же я ценю в людях постоянство.
А началось всё ещё раньше — http://www.rsdn.ru/forum/message/2668397.1.aspx когда ты заявил что транзакции выполняются на сервере (гениально, а мужики-то не знали!) правда забыл уточнить на каком именно.

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

Никогда бы не подумал, что вопрос использования хранимых процедур может вызвать такой прямо-таки шквал полярных мнений.
Правильный ответ: всё зависит от сценария.
Нельзя воспринимать БД отдельно от приложения.

На всякий случай напомню, что хранимые процедуры позволяют (как и многие другие средства) ввести еще один уровень в приложение. С этой точки зрения и нужно их рассматривать.

Сценарий 1. Простое приложение.
Нафига лишний слой? Чтобы было что пописать?
Рассказы про планы запросов и про некомпетентных девелоперов здесь неуместны. Маленькое приложение не пишется командой в 40 человек с разными умениями; планы всех запросов прекрасно построит СУБД, а нужные индексы легко добавить и по результатам опытной эксплуатации.

Сценарий 2. СУБД как сервер приложений
Если потребная приложению бизнес-логика мало выходит за пределы вопросов обработки данных, это неплохой вариант. Перенести характерные сценарии в ХП гораздо лучше, чем гонять их из толстого клиента. Это улучшит и масштабируемость, и поддерживаемость.
Чего стоит бояться — введения ХП на каждый чих. К примеру, поддержку справочников вовсе незачем запихивать в ХП — это всего лишь увеличение объема кода, который нужно править при добавлении еще одной колонки. ХП должны формировать интерфейс сервера приложений. Если есть там какой-то сложный процесс обработки заказа, с поиском распределения по складам и оптимального формирования набора пакетов — так и пишите, create procedure ProcessOrder.
Критерий того, что стоит писать ХП — изменение списка параметров менее вероятно чем изменение логики. Именно поэтому хранимки для CRUD — фигня в 99.9% случаев.

Сценарий 3. Работа с сервером приложений.
Если у вас есть выделенный сервер приложений или слой, играюший его роль, то интерфейсом серверной части заведует именно он. В этом случае введение еще одного слоя в виде ХП в большинстве случаев неоправдано. У вас уже будет метод StoreSystem.ProcessOrder, а как уж он там внутри устроен — его дело. Там может быть использован O/R маппер или прямые SQL запросы. Но опять же, в этом случае использование ХП в большинстве случаев приведет только к увеличению объема кода и дополнительным возможностям по рассогласованию.

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

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

S>>Декларативность языка, говоря неформально — это описание того, что нужно получить, а не как.
kuj>Наличие декларативных элементов не делает язык декларативным. А то мы и C# можем обозвать декларативным следуя этой логике.

Фигасе. В SQL оказывается декларативные элементы. Кодд вероятно перевернулся в гробу раза два.

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

kuj>Ну может расскажете или хотя бы ссылку на ресурс дадите о тестировании ХП в СУБД?

Visual Studio — пишите любые тесты, какие вам нужно. При поиске в поисковиках думаю сможите найти и что-то специализированое. Или вас интересует теория о том как тестировать ХП в СУБД?

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

A>>>Нет, значит ты меня утомил. Не надо искать всемирный заговор там, где его нет. Ты задаёшь глупые вопросы, пересказываешь лозунги, но сам по сути ничего существенного кроме "ОRМ-рулят" не сказал. Все тво комментарии сводятся к "ну-ну" и "вы вообще знаете?". Мне такая дискуссия не интересна, она скучна и утомительна. Я не буду отвечать на твои вопросы не потому что нет ответов, а потому что меня не интересуют твои вопросы.

kuj>>Рекомендую в будущем не ввязываться в спор, если не имеете представления о предмете спора, чтоб не выставлять себя клоуном, как это случилось в этом топике.

A>Хотя, конечно, заявления что SQL не декларативный язык и что бизнес-транзакций не существует ещё надолго запомнятся. Я понимаю, когда люди спорят о чём-то новом и не известном, но когда начинают определять факты данные по определению это просто утомляет.
Спорите о неизвестном здесь только Вы.

Кстати, по поводу языков программирования... надеюсь Вы разобрались с разницей между T-SQL и SQL, а так же знаете теперь, что T-SQL это процедурный язык программирования, что есть синоним императивного программирования? А так же что SQL не является языком программирования?

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

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

kuj>>Ну может расскажете или хотя бы ссылку на ресурс дадите о тестировании ХП в СУБД?

I>Visual Studio — пишите любые тесты, какие вам нужно.
Эээ в VS нету средств для тестирования ХП в БД или я что-то пропустил?

I>При поиске в поисковиках думаю сможите найти и что-то специализированое.
Так может все-таки подскажете?

I>Или вас интересует теория о том как тестировать ХП в СУБД?
Теорию тоже хотелось бы послушать или хотя бы подскажите где об этом можно почитать?

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

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

kuj>А так же что SQL не является языком программирования?

В английской версии статьи, которой я доверяю гораздо больше, этого утверждения нет.

P.S. Твоя манера поучать уже порядком затрахала. Давай договоримся, ты не самый умный. Просто прими это к сведенью и как-нибудь проживи оставшуюся жизнь с этой мыслью.

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

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

A>kuj это в народе называется прыгать на словах. Вот тут, несколькими сообщениями выше
A>http://www.rsdn.ru/forum/message/2669032.1.aspx
A>ты утверждал что бизнес-транзакций нет. А сейчас вдруг выяснил что они есть, но не тоже самое, что БД-транзакции. Я конечно рад, что ты так быстро умнеешь, но всё же я ценю в людях постоянство.
A>А началось всё ещё раньше — http://www.rsdn.ru/forum/message/2668397.1.aspx когда ты заявил что транзакции выполняются на сервере (гениально, а мужики-то не знали!) правда забыл уточнить на каком именно.

Так, простите, каким боком бизнес-транзакции относятся к БД, к DAL, к хранимым процедурам и к ORM? Или Вы это ляпнули так ... для проформы?

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

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

kuj>Так, простите, каким боком бизнес-транзакции относятся к БД, к DAL, к хранимым процедурам и к ORM? Или Вы это ляпнули так ... для проформы?

Бизнес-транзакции очень даже относятся и к DAL, и к ORM, так как иногда надо делать не только commit, но и rollback. Это должно как минимум поддерживаться, не говоря уже об эффективной поддержке. А ещё бывают аппаратные сбои в результате которых тоже надо делать откаты. Например, ты перевёл клиента в статус должника, но если ему не отправился СМС об этом оповещающий, то клиент не переводится. А срок доставки СМСа сутки и за это время сервера могут даже перегрузить.

А теперь подумай над двумя вопросами:
Как эффективно решить эту проблему с помошью кеша второго уровня Hibernate о котором я ничего не знаю?
Причём тут ХП, с которых начался весь разговор?

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

I>>Visual Studio — пишите любые тесты, какие вам нужно.
kuj>Эээ в VS нету средств для тестирования ХП в БД или я что-то пропустил?

I>>Или вас интересует теория о том как тестировать ХП в СУБД?
kuj>Теорию тоже хотелось бы послушать или хотя бы подскажите где об этом можно почитать?

Неподскажу

Целенаправленым поиском, о том как тестировать конкретно ХП в СУБД не занимался, не считал что для этого нужно специальные теории читать. Работал точно так же как и с кодом, отлаживал пошагово. Писал сам ручками приложения, которые проверяют корректность работы ХП, причем и знать не знал, что это такая проблемма для общественности.

Просто еще раз попытаюсь высказать свою мысль. Есть люди с разными складами ума, есть различные инструменты для работы, есть различные задачи и цели. Нельзя распространять один подход на всех и вся, даже если он супер-пупер распрекрасный. В коные концов профессионал своего дела не должен быть рабом своего инструмента. В этом плане я полностью поддерживаю Sinclair с его примером (Простое приложение; СУБД как сервер приложений; Работа с сервером приложений).

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

A>Здравствуйте, Cyberax, Вы писали:
C>>Ага, ты нашел самую гадостную для РБД вещь

A>Она меня сама нашла несколько лет назад. Причём меня тогда поразило то что я не то чтобы не смог с наскоку сделать хоть как-то, а то что я с наскоку вообще ничего не смог сделать. Пришлось задуматся. А потом я начал понимать, что БД и объекты совсем разные вещи и разрабатывать их надо отдельно.
Ну тут если "по книжке" действовать — как раз все в полиморфный mapping и разворачивается.

Другое дело, что его сильно пинать потом надо до рабочего состояния — для этой задачи нет нормальных идеальных решений из-за ограничений самой модели, поэтому приходится идти на компромисы и делать хаки, чтобы оно работало на практических объемах данных

C>>2) Делаем полиморфное отношение с join-таблицами и полем-дискриминатором. Масштабироваться будет достаточно неплохо, но не неограничено.
A>Ну вот что-то типа этого и внедрили в итоге. Мне вообще такие гадостные вещи попадаются достаточно часто. Наверное я неудачник и пока все остальные счастливы на стандартных, легко отображаемых задачах, я ломаю голову над своими плохо отображаемыми

У меня подобные же проблемы — вот тут часть описана http://www.rsdn.ru/Forum/Default.aspx?mid=2629471&flat=0

Только вот после этого всего я стал жутко нелюбить базы данных и все что с ними связано

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

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

S>>>Декларативность языка, говоря неформально — это описание того, что нужно получить, а не как.
kuj>>Наличие декларативных элементов не делает язык декларативным. А то мы и C# можем обозвать декларативным следуя этой логике.

A>Фигасе. В SQL оказывается декларативные элементы. Кодд вероятно перевернулся в гробу раза два.

декларативное:
SELECT ...

императивное:
CREATE TABLE, VIEW, INDEX, ...
DROP TABLE, VIEW, INDEX, ...

Так понятнее?

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

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

I>>>Visual Studio — пишите любые тесты, какие вам нужно.
kuj>>Эээ в VS нету средств для тестирования ХП в БД или я что-то пропустил?

I>>>Или вас интересует теория о том как тестировать ХП в СУБД?
kuj>>Теорию тоже хотелось бы послушать или хотя бы подскажите где об этом можно почитать?

I>Неподскажу

Целенаправленым поиском, о том как тестировать конкретно ХП в СУБД не занимался, не считал что для этого нужно специальные теории читать. Работал точно так же как и с кодом, отлаживал пошагово. Писал сам ручками приложения, которые проверяют корректность работы ХП, причем и знать не знал, что это такая проблемма для общественности.

В том и проблема, что тестировать процедуры самописными приложениями полноценно не выйдет. Для тестирования CLR у меня есть средства для мокинга, благодаря которым я могу тестировать конкретно нужный мне метод, а не этот метод И все методы, которые он вызывает, как пример.

IProjectView projectView = mocks.CreateMock<IProjectView>();
Expect.Call(projectView.Title).Return("Project's Title");

Посмотрите, например http://www.ayende.com/projects/rhino-mocks.aspx

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

Здравствуйте, Aviator, Вы писали:
A>Был задан очень хороший и вполне конкретный вопрос. Причём этот вопрос задавался неоднократно по этой теме. Ты сказал что тестируешь ХП и БД. Общественность заинтересовалась как ты это делаешь. У меня вот, например, так и не получилось

, так что я с удовольствием почитаю как.
Ну, вот я лично не тестирую, но знаю, что тестирование приложений с БД вообще значительно затруднено. В принципе. Просто потому, что поведение системы зависит от очень большого и размазанного состояния.

Ну вот как мы тестируем функции? Функция замкнута относительно своих параметров, поэтому достаточно проверить ее на некотором наборе.

Assert(4 == Mul(2, 2));
Assert(0 == Mul(0, 2));
Assert(0 == Mul(2, 0));
Assert(1 == Mul(-1, -1));

Как мы тестируем класс?
Приводим объект в некоторое состояние, выполняем вызовы методов. Приводим в другое состояние, снова выполняем вызовы методов.

Как мы тестируем, к примеру, отчет в корпоративном приложении?
Запускаем на продакшн-базе, сидим с калькулятором в руках.

В теории всё должно работать так же, как и везде:
1. создали тестовую БД
2. наполнили ее тестовыми данными
3. прогнали набор тестовых операций
4. проверили нужные ассерты.
Я не вижу принципиальной разницы в сложности п.3 для ХП и ORM. Вся сложность обвчно в п.2. Если его выполнить, остальное сработает примерно одинаково.
Поэтому сейчас появляются инструменты тестирования data-приложений, которые делают именно так. Например, MS VS for Database Professionals. Там можно тестовые данные генерить, можно снимать образец с production базы. Можно делать нагрузочное тестирование и проверять плазы запросов. И всё это в том числе автоматически и по расписанию.

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

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

kuj>>Так, простите, каким боком бизнес-транзакции относятся к БД, к DAL, к хранимым процедурам и к ORM? Или Вы это ляпнули так ... для проформы?

A>Бизнес-транзакции очень даже относятся и к DAL, и к ORM, так как иногда надо делать не только commit, но и rollback. Это должно как минимум поддерживаться, не говоря уже об эффективной поддержке. А ещё бывают аппаратные сбои в результате которых тоже надо делать откаты. Например, ты перевёл клиента в статус должника, но если ему не отправился СМС об этом оповещающий, то клиент не переводится. А срок доставки СМСа сутки и за это время сервера могут даже перегрузить.

A>А теперь подумай над двумя вопросами:
A>Как эффективно решить эту проблему с помошью кеша второго уровня Hibernate о котором я ничего не знаю?

При чем тут кеш второго уровня? oO

И с чего Вы решили, что транзакции БД это единственный способ организации бизнес-транзакций? А так же почему Вы думаете, что я не могу организовать бизнес-транзакцию средствами управления транзакций БД в ОРМ?

Разберитесь сначала в терминологии и не сваливайте все в одну кучу.

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

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

kuj>декларативное:
kuj>SELECT ...

kuj>императивное:
kuj>CREATE TABLE, VIEW, INDEX, ...
kuj>DROP TABLE, VIEW, INDEX, ...
kuj>Так понятнее?

Так не понятнее, потому что глупость. DDL не является императивной частью, он точно такая же декларативная часть. Ты указываешь конечный результат — таблицу, а не пришешь генерацию внутреней структуры файлов: записей, индексов.

Даже если на 5 минут сойти с ума и предположить что ты прав, это всё равно не корректный способ сравнения — считать ключевые слова относящиеся к той или иной обласни. SELECT пишется гораздо гаще, на порядки чаще, чем CREATE, а исполняется в миллиарды раз чаще.

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

kuj>В том и проблема, что тестировать процедуры самописными приложениями полноценно не выйдет. Для тестирования CLR у меня есть средства для мокинга, благодаря которым я могу тестировать конкретно нужный мне метод, а не этот метод И все методы, которые он вызывает, как пример.

Ты видимо не очень это понимаешь, но SQL и обсуждемые расширения с диалектами не являются ОО, а значит мок-объекты им не светят. По определению.
Кроме того, если мы говорим о тестировании, БД не являются сущностями, которые можно протестировать полностью. По той же причине, что и многопоточные приложения, например.

	От:	kuj
	Дата:	25.09.07 03:43
	Оценка:	-1

От:	adontz	http://adontz.wordpress.com/
Дата:	25.09.07 03:45
Оценка:

	От:	kuj
	Дата:	25.09.07 03:50
	Оценка:	-2

От:	adontz	http://adontz.wordpress.com/
Дата:	25.09.07 03:51
Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	25.09.07 03:53
Оценка:	5 (2) +1