LSVДа уж 1С просто образец высокой производительности и оптимальности. Ога.уж какой есть :)
по распространнести может конкурировать очень со многими
эффективность решения в целом состоит не только из быстрой отработки запросов
но и из скорости и простоты разработки и сопровождения
если ты 1с пишешь конфигурацию за два часа, и она делает то же самое, что и ХП, которые пишутся неделю...
пусть даже не настолько оптимально с точки зрения БД
какое решение будет более эффективно? :)
LSVСделано это в т.ч. для портируемости. Один код для любой СУБД. А сама СУБД в данном случае - свалка таблиц.
Аналогично кстати в большинстве западных ERP систем.
видать были аргУменты для принятия такой архитектуры... :)
LSVпереносить бизнес-логику в БД - добавлять лишнее звеноТак и запишем - ХП и триггеры придумали дураки. :)
да записывай как угодно, я этого не говорил
но чем больше длина цепочки - тем более высока вероятность искажения сигнала, тем более высока стоимость передачи
от этого никуда не денешся

Voland_de_mortНе даром 1С используется как вариант "из коробки" и для не больших контор.
Серьезные вынуждены разрабатывать свои системы учета, которые будут оптимизированы под конкретные задачи. Почему-то еще не встречал серьезных бизнес решений с высокими требованиями по производительности которая бы использовала БД как свалку таблиця встречал "серьезные бизнес-решения для больших контор" на 1с (правда на 8-ке, 7-ка тяжело тянула...), не из коробки, которые разрабатывались и оптимизировались под конкретные задачи
зы. правда и 1с не относится к БД как к свалке таблиц, и я БД свалкой таблиц не считаю :)

зыы. тут еще вопрос, что считать серьезным решением, и что считать большой конторой...
Евросеть, насколько знаю, 8-ку юзала, это большая контора? :)
Voland_de_mortничего подобного, звенья цепочки теже самые.ничего подобного - не те же
в нашем примере добавляется "прог БД" (либо же "слой БД", куда мы пихаем бизнес-логику)
Voland_de_mortЕсли человек считает, что БД - груда хлама из данных - то я не вижу смысла таким использовать клиент-сервеные БД - юзайте файловые, что в лоб, что полбунаоборот, таким как раз и надо юзать сервера БД, которые сделают работу, ни о чем и никого не спрашивая :)
Voland_de_mortЕсли человек не знает, как это реализовать, то это не значит, что это такой подход не правильный.согласен
Voland_de_mortChop а как на счет производительности обработки массивов данных? десятки и сотни тысяч строк? тоже клиет будет делать?смотря какая и чего обработка
смотря на чем написан клиент
смотря какие политики безопасности

в общем случае, учитывая предыдущий опыт и с-но привычки, я бы, скорее всего, пихал SQL-запрос
и из под 1с, вероятно, тоже прямой SQL-запрос, если критична производительность

LSVавторесли ты 1с пишешь конфигурацию за два часа, и она делает то же самое, что и ХП, которые пишутся неделю.Аналогично и наоборот: запрос из 10 строк с группировками, сложным суммированием, подзапросами(пишем за 5-7мин) может быть аналогичен нескольким сотням строк плохочитаемого кода приложения, кот. пишутся за 2-3 дня.
трудно такое представить...
в общем случае программирование на каком-либо языке программирования гибче, чем на чистом SQL
читабельность кода сюда тоже никаким боком, все дело в плечах - на плечах должна быть голова, и из них должны расти руки

тем более, если ты приводишь в пример 1С, которая работает с метаданными и в которой документ "договор", так и называется Документ.Договор, а не "таблица dc000035 с полем priznak=586" :)
как минимум пропадает необходимость документировать, что такое dc000035 и что такое priznak=586

рискуем скатиться в религиозный холивар и тогда вы меня потеряете :)
суть же в том, что ты согласился - это не является доказательством ни одной точки зрения, ни другой :)
LSVПро производительность и бешенный Ethernet-трафик (иногда очень важно) - отдельная тема.
да, трафик можно сделать любой, как в первом случае, так и во втором
LSVВаяние же SQL-кода внутри приложения ничем не отличается от ваяния ХП. С той лишь разницей, что ХП проще хранить в VSS/ST/CVS.
я изначально писал "размазывание бизнес-логики по слоям"
с этой точки зрения - отличается
и, может дело привычки, но мне удобней логически связанные блоки хранить в одном месте
в БД код приложения не запихаешь, а вот SQL-код в код приложения - лехко

LSVА ну да... Большинство 1С-ников даже никогда не слышали слово SQL.
те которые решают задачки, которые ты задаешь, очень даже слышали :)
LSVНе даром же появилось мнение, что 1С-ник - не программист. Конфиг.. дальше сами знаете
я так подозреваю, что ты меня причисляешь к славному племени конфигурастов?
могу сообщить - с 1с не работаю уже скоко лет, как-то так сложилось
как раз сейчас занимаюсь SQL-запросам с редкими вставками xBase-а
хотя сделать то же самое на 1с (пусть даже с использованием прямых запросов) было существенно проще и быстрее, но увы и ах - у нас 1с-а нет даже для бухии :)

Voland_de_mort1. что касается проще хранить:
в БД хранится не только сама ХП, но и ее план выполнения. В случае SQL запроса извне - план оптимизатор будет делать при каждом вызовене все БД занимаются оптимизацией запросов...
а сопровождать?
считать надо, стоит ли оно того...
в каждом конкретном случае
Voland_de_mort2. для того, что бы получить сумму товаротранспортной накладной ( сотсоящей из 100 накладных, в которых по 100 наименований.) после переоценки товара - будете все тащить на клиент и там считать?в 1с, пока не припечет, даже не буду задумываться что и куда она тянет :)
не в 1с, ес-но, сумму я запихаю в простенький запрос и потяну одно число :)

зы. кстати, не понял, зачем пересчитывать накладную после переоценки товара...
зыы. сумма по 100 докам по 100 наименований - фигня вопрос, никакой оптимизации не надо, ИМХО

LSVИ ..для этого нанимаем отдельного "БД-прогера" ? Да ? :)ес-но нет :)
LSVРазве это не встраивание того самого "лишнего слоя", но внутрь приложения ?похоже у нас разное понимание термина "слой" :)
"людоеды они как лук, у них есть слои .." (с) Шрек
код приложения тоже может и зачастую должен делиться на слои :)
но мне больше нравится иметь дело с одной луковицей, чем с несколькими :)
LSV* Проверка будет только при работе приложения.ты о юнит-тестах? или о чем?
о том, что его нельзя выполнить при неработающем приложении?
зачастую можно
зачастую не нужно
LSV* Одинаковый SQL-код нужно будет дублировать со всем вытекающими.не нужно

LSV1. В смысле не Вы, а "дополнительный БД-прог" (с) ? Запрос к БД как никак....в смысле - я
я же тебе написал, SQL знают даже конфигурасты, которые решают предложенные тобой задачи
а уж тру-прогам по жизни положено :)
LSV2. А если по 50 магазинам по 50тыс. товаров (обычное дело) ?что "по 50 магазинам по 50 тыс.товаров в каждом"?
сумму выручки посчитать за год посчитать?
так даже 1с при всей своей неоптимальности не будет считывать 50х50000х(?) записей...

Voland_de_mortВ студию те БД, которые не занимаются оптимизацией запросов
(с) не мойя всегда, где можно стараюсь делать джоины
во всяком случае на майкрософте он работает на порядок быстрее
под фиребёрдом - подзапросы вообще п...[цезоред]
он всегда подзапросы честно выполняет, вообще без никаких оптимизаций
мы с ... офигели

Voland_de_mortВ студию те БД, которые не занимаются оптимизацией запросов
Advantage Database Server - может и делает, но в доке я пока этого нигде не увидел
и по скромному субъективному мнению - на практике не увидел никакой оптимизации

Voland_de_mortне такой то уж и простенький)
надо взять последнюю переоценку по последнему нужному региону(то же документ)
переоценка 1-2 раза в месяц. в переоценке 30-60 тыс наименований
АП (асортиментный перечень) = 50тыс

в таблицах, отвечающих за тело документа общее кол-во строк свыше 4млрд
бд за 10 лет

так как теперь для "фигня вопроса" буде SQL писать?)) но дело даже не в этом.. как будете оптимизировать? как планы хранить?
задачу не понял
я говорил о сумме накладной

Voland_de_mortУ Sybase есть оптимизатор, и довольно не плохой.
сцилку в студию было бы неплохо :)
можешь ткнуть пальцем, где об этом написано в доке? тынц

Voland_de_mortа задача не менялась - все та же сумма накладной.
только тут надо не меньше 10 join-ов
давай структуру БД
зачем там может понадобиться 10 джоинов?

Voland_de_mort тынц принял
т.е. оптимизация проводится и без хранения запроса в БД,
а и при отправлении оного из пехапы :)

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

LSVРазве парой страниц назад не шла речь о "лишнем слое", для которого нужен "дополнительный БД-прог" ?
Кажется это был основной аргумент против SQL-кодирования. Не ?
так, стоп...

дополнительный прог БД у нас появился в контексте того, что прог.приложений - криворукий :)
и раз уж он появился, то должен чем-то занимацца? :)

речь шла не о лишнем слое, а о переносе бизнес-логики в "слой БД"
в коей я смысла особого не вижу
вижу дополнительные неудобства
LSVВыходит как ни крути, но в подавляющем большинстве случаев "лишний слой" все таки используется.
Тогда зачем его избегать ?
Избежать "лишнего слоя" в общем случае невозможно для прочих сред. Тогда о чем спор ???
я же написал...
не избегать и не "лишний слой", а хранить логически связанные блоки функционала в одном месте
мне так удобней
редкие случаи, когда требуется чрезвычайно высокая производительность, на то и редкие случаи, зачем из-за них менять все?
LSVА сравнение с 1С неудачное. Там отдельная специфическая среда разработки с высоким уровнем абстракции от реалий СУБД.
Подобных систем немного (обычно это западные ERP).
почему неудачное?
тот же линк позволяет писать подобные системы "с высоким уровнем абстракции от реалий СУБД"

кстати, с этого тема и началась :)