VoDAЕгоров АлександрМассовая обработка данных - это, например, поток заявок покупателя, каждую позицию которых нужно проверить на корректность скидки? Представляете какой трафик поднимется между СП и БД, если таких заявок забивается тысячи в день, и в среднем состоят из десятков позиции, а некоторые и до сотни? ;) согласен, что оперирование массивом данных проще на СУБД.
А я говорю не о массиве. Я говорю о нормальной рабочей ситуации - рабочий поток документов. Просто их много, они приходят из разных мест и упираются в СП. Ведь всё у нас делает он, и проверкой, и "проведением", и "пересчетом итогов", и получением данных для отчетов, и т.д. и т.п.... А СУБД просто занимается хранением данных в более удобном виде, чем куча отдельных dbf-ов, и возможностью бакапить эти данные в онлайне.

VoDAВот пару лет назад нам аутсорсили софт для формацевтических лабораторий, а в прошлом году эм... софт для голосового управления / помощи работникам складов перепиливали под нужды ... сортировочного цеха. Системы совсем не связанные друг с другом. Только принципы остаются общие, да написаны на одних и тех же фреймворках (Java) + требуют одинаковые сервера.
Ну как я и думал - разработка на заказ. И никаких тиражных систем "для среднего бизнеса". Везет Вам. :)
Собсно и вопросы про поддержку тогда снимаются - у Вас просто не может возникнуть ситуации, когда один проект разваливается на две ветки из-за прихоти клиентов :)

VoDAОпять же в совсем больших системах с сотнями апп-серверов переносить БЛ с Апп на СУБД... ИМХО убьет производительность.Давайте немного посчитаем. Огрубим понятие "трафик" до "запрос" и возьмем наш пример с проверками на скидки. Будем считать, что документ проверку пройдет. Обработка ошибок нам сейчас непринципиальна. Возьмем вырожденный случай - Клиент выписал 1 заявку с 1 позицией в ней.

Вариант с логикой проверки и обработки на СП:
1. Клиент->СП = 2 запроса (передача заголовка заявки+строки товар\количество).
2. СП -> БД = запрос из "Таблица стоимости товара" по @ID
3. БД -> СП = Стоимость товара @ID
4. СП -> БД = запрос из "Таблица ввода товара впродажу"
5. БД -> СП = Дата ввода товара
6. СП -> БД = запрос из "Таблица разререшений менеджеров по товару"
7. БД -> СП = Флаг разрешения менеджера по товару @ID
8. СП -> БД = запрос из "Таблица свободных остатков по товару"
9. БД -> СП = количество свободных остатков
тут СП убедился, что по текущей БЛ заявку можно принять.
11. СП -> БД = 2 запроса (записать шапку заяки + записать строку товар\количество)
тут СП резервирует товар по текущей БЛ
12. СП -> БД = 1 запрос ("уменьшить количество свободных остатков")
13. СП -> Клиент= "Заявка принята".
"Трафик СП<->БД" = " Д окументов" * (2 + 11 * " С трок").

Вариант с логикой проверки и обработки на БД:
1. Клиент->СП = 2 запроса (передача заголовка заявки+строки товар\количество).
2. СП -> БД = 2 запроса (заголовок+строка).
4. СП -> БД = exec RequestCheck(@IDDOC)
5. БД -> СП = Check passed. No Errors found.
6. СП -> БД = exec RequestApply(@IDDOC)
7. БД -> СП = Request applied successfully.
8. СП -> Клиент = "Заявка принята".
"Трафик СП<->БД" = Д * (1 + С + 6) .

Пускай в день выписывается 1000 заявок по 20 строк в каждой.
Вариант 1 = 1000*(2+11*20) = 222000 "запросов"
Вариант 2 = 1000*(1+20+6) = 27000 "запросов".

Теперь добавляем условие "...а если клиент...":

Вариант 1. Добавляются запросы
7.1 СП -> БД = запрос из "Таблица контрагентов"
7.2 БД -> СП = Тип контаргента @ID
Формула меняется на Д * (2 + 13 * С). Дневной трафик увеличивается до 262000 "запросов"

Вариант 2. Ничего не добавляется и трафик остается неизменным.

Меняем документооборот на 1000 заявок по 50 строк:
Вариант1: 1000*(2+13*50)=652000 "запросов"
Вариант2: 1000*(1+50+6)=57000 "запросов"

Понимаю, что цифры эти не более чем "попугаи", но стоит подумать о разнице нагрузки на порядок и геометрическую зависимость от сложности БЛ. Кластер из "сотни Апп-серверов" нас, конечно, выручит. ;) Но ведь кластер - это не только серверное железо, это еще и внешние дисковые массивы, и сверхскоростные межсерверные коммуникации. А это тянет за собой грамотного админа, дорогостоящего помещения с вентиляцией и кондиционированием. Да и бесперебойное питание всему эту делу понадобится немаленкое...

И все потому, что разработчику невыгодно держать в штате БД-программиста?.. ;)

skmdeveloperВ 1С в основном вся логика на клиенте. С точки зрения производительности (да и со многих прочих) это не оптимальный вариант.
Уже можно в 1С тот же самый код клиента выполнять и на сервере приложений. Не без ньюансов, но можно. Правда, на работу платформы с БД это никак не сказывается :)

iscrafmalneoСвято верю, что бизнес-логика должна лежать в бизнес-слое, возможно частично в сервисном(API).
Для нача определитесь что зверь такой бизнес-слой. Tier vs Layer многие путают.
Это же верующий человек! :) Определяться - это же от лукавого! :)

Странно только, почему апологеты "объктной бизнес-логики" в большинстве случаев используют именно РСУБД. При этом активно отрицая их возможности, делая из них простые "dbf-помойки", лепя костыли из ORMа и удивляясь, что это оно так медленно работает... Вместо использования готовых ООБД, которые под это дело самое оно и не нужно никаких костылей? Неужели только потому, что в MSVS нет нормально драйвера для Cache, а для MSSQL есть? ;) Или потому, что в Java о поддержки того же Cache что-то вообще не слыхать? :)

Bogdanov AndreyОстается только сравнить "пропускную способность" сети и сервера базы данных и понять в каком из двух вариантов мы раньше "упремся". Вряд ли ответ столь очевиден.А почему Вы считаете, что на SQL сервере будет выполняться "построчная" проверка? В выбранном примере проверка всех условий по всем строкам одного документа - это один "запрос". Выполненный приложением, которая оптимизирована на такие запросы. И почему Вы считаете, что "+еще некая математика" на сервере БД потребует бОльшей нагрузки, чем на сервере приложений?
Bogdanov AndreyУмные люди для разных задач используют разные инструменты. Для реализации бизнес-логики одни, для хранения данных - другие. И для каждой задачи стараются выбрать наиболее подходящий инструмент.Умные люди по-максимому используют возможности РСУБД. А не используют их только для хранения данных. Вопрос-то почему другие умные люди не используют по-максимому возможности ООБД? Или Вы считаете, что РСУБД - это самый подходящий инструмент для ОО-работы с данными? Или Вы считаете, что ООБД не лучший инструмент для ОО-работы с данными? Или Вы сомневаетесь, что РСУБД имеет какие-либо преимущества перед ООБД в умении хранить данные?

VoDAтеперь прикинем что есть устройства генерирующие эти "запросы". Сама обработка запроса имеет нагрузку эм... 100 MHz и длительность 10 секунд, обращения каждые 30 секунд, CPU на СУБД - 2 000 MHz. Тогда какие то 60 устройств выведут СУБД из строя ибо CPU на управление данными уже не останется - все уйдет на обработку запросов клиентов.
Я вроде нигде не говорил, что все нужно делать в БД. "Вся логика только в БД" это такая же крайность, как и "Вся логика только на СП" или "Вся логика только на клиенте". Я говорю лишь о том, что "бизнес-логика" имеет вполне разделяемые части. Одну из которых, "манипуляцию данными", лучше всего размещать в СУБД, которая для этого и предназначена.

И давайте посмотрим Ваш вариант: CPU на СУБД - 2000Mhz, CPU на СП - тоже 2000MHz. Обработка Клиент<->СП - 3 "запроса", обработка БД<->СП в первом варианте - 13 "запросов", во втором - 5 запросов. То есть использование варианта "обработка данных на СП" в два раза больше грузит и СУБД, и СП. СУБД имеет даже больший чем в два раза увеличенный поток "клиентских запросов" (ведь СП для СУБД тоже клиент), СП в два раза больше занят "отправкой запросов к БД и обработкой ответов"... И при усложнении "бизнес-логики" эти лишние "вопросы-ответы" растут геометрически, хотя могли бы расти арифметически...

VoDAPS у нас в одном из проектов БД мелко нашинкована между Oracle-овыми инстансами. СУБД-хи уже затыкаются на записи. зареганых пользователей у системы вроде около 0,5 млн. И DBA у них пачка сидит и программеров целый штат.
Я правильно выделил? ;) Помимо оплаты самого проекта, клиенту пришлось прикупить еще пачку DBА с программерами? Или они там были изначально? Если это ваш проект, значит именно так Вы и спроектировали. ;)

skmdeveloperЯ о реальной жизни а не о грибах. ПО, какими бы замечательными характеристиками не обладало, но вокруг которого обязательно должны бегать с бубном SQL-гуру и еще толпа узких специалистов, обязательно будет занимать мизерную долю на рынке
Вот странно, почему вокруг 1С "бегающие с бубном SQL-гуру и еще толпа узких специалистов" позволяют 1Су даже расширять свой рынок? :) Вы же вроде сами работаете с 1С? Когда столкнетесь с проблемами быстродействия и масштабируемости 1С, особенно после того, как владелец начнет задавать вопросы типа "как это опять сервер надо покупать??? в прошлом году только купили, тебе опять мало???" - сами быстро станете и "SQL-гуру", и "узким специалистом", и с бубном танцевать научитесь. :)