DrKonitoДопускаю, что есть задачи где она уместна, но те системы, которые я видел - (автоматизация склада, торговли итп для не особо больших предприятий (100-200раб мест) ) к таким имхо не относятся.
Безусловно. Здесь нет вариантов, при которых многозвенка пригодится - помним, что она имеет смысл только для задач, для которых КС в чем-то неудачен, а вот уж что много лет успешно решается на КС, так это именно названные задачи :)

C моей точки зрения здесь можно говорить только о том, что в некоторых случаях пригодится формальная многозвенка. Формальная - имеется в виду, что одно из звеньев не имеет собственного логического смысла, а выполняет сугубо технические функции. Я такие системы не считаю многозвенными, но есть любители.

DrKonitoне очень понял - вы имеете в виду 2х звенку с бизнес-логикой вынесенной в отдельный слой на клиенте?
Нет. Я имею в виду, например, типичное веб-приложение, в котором "клиентом" называется то, что в обычном КС называется драйвером дисплея :) Или промежуточное звено, которое обеспечивает специфическую прокачку данных между сервером и клиентом и ничего более. Или прочее в том же духе.

ВМоисеевКакая то умная голова выдала, если им требуются графики, то давайте аппраксимируем сплайном. При этой идее сжатие тысяче кратное. Очень красиво - передавать только параметры сплайна.
Хм. Вообще-то это очень давно известное решение :) В семидесятых годах его могли скорее "вспомнить", чем "придумать".

Сейчас, имея прототип, я бы её решил.
А зачем для этого "прототип"?

Не знаю, на сколько удобно применять, например, T-SQL для задач вычислительной математики.
Чем хорош здесь .Net - могу применять разные молули из разных языков.
Ну и применяйте .Net Его обещали встроить в Oracle 10gR2, который уже вышел. Не проверял, встроили ли. Обещают поддержку и в T-SQL. А Java уже давно поддерживается.

Смею заметить, что такие задачи есть. Мы просто не умеем их готовить.
Ключевая - вторая фраза :)

DrKonito
А зачем так сложно? Написать на чем угодно и подключить в СУБД как внешнюю процедуру. Упоминалось раньше в этом топике.

Если говорить об Oracle - у него есть такая интересная особенность, как картриджи. Фактически это - плагины к серверу. Например, картриджем реализованы работа с географический информацией и полнотекстовый поиск. Интерфейс специфицирован, можно сесть и дописать, если задача достаточно сложна и просто внешних процедур будет маловато.

DrKonito
А зачем так сложно? Написать на чем угодно и подключить в СУБД как внешнюю процедуру. Упоминалось раньше в этом топике.

Имхо наоборот это самый простой вариант.
Как Вам сказать... это мнимая простота. Примерно так же "проще" не пользоваться "сложной" конструкцией цикла, заменив ее "простыми" if-goto.

DrKonitoНе всякий сервак БД дает возможность делать расширенные хранимки.
Хм. Не всякий сервак вообще дает делать хранимки :) Но мы кажется говорим о мало-мальски серьезных проектах; да и адекватного сервака, который не дает делать внешних хранимок, я сходу не назову.

DrKonitoА если и дает то пишутся они обычно на ЦПП (MS SQL 2000).
Хм. "Обычно" - это, безусловно, сильный аргумент. И при чем тут MSSQL?

DrKonitoА я вот например на ЦПП писать не умею.
Это тоже сильный аргумент.

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

DrKonitoДа и вообще, не хотелось бы грузить в адресное пространство боевого сервака самопальную длл.
Ну и не грузите, если не хотите, никто не заставляет. Хотя лично я бы предпочел просто хорошо ее написать.

DrKonitoА так на чем хошь, на том и пиши- хошь на шарпе, хошь на фортране, хошь на прологе. Можно и батник в конце концов :).
О подключении внешней процедуры из батника не думал, хотя наверное возможно. Да и все остальное без проблем.

DrKonito softwarer
DrKonitoДа и вообще, не хотелось бы грузить в адресное пространство боевого сервака самопальную длл.
Ну и не грузите, если не хотите, никто не заставляет. Хотя лично я бы предпочел просто хорошо ее написать.
Вы наверное умеете писать на ЦПП вообще без ошибок или по крайней мере обладаете кучей свободного времени для всесторонней отладки. Тогда наверное нельзя не согласиться с вашим видением проблемы :)
Все проще - я не люблю фразу "у меня нет времени делать хорошо", и обычно отвечаю на нее "а у меня нет времени делать плохо и потом переделывать".

Также обращаю Ваше внимание на то, что не хотите dll - не делайте. Ну и по-прежнему не понимаю, причем тут ЦПП - складывается впечатление, что у Вас какой-то пунктик на эту тему.

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

расширеннуюХП мягко говоря неразумно. И на хрена тогда вообще нужна эта расширенная ХП, если вопрос в 90% случаев решается на уровне администратора БД и джоба в 3 строчки?
Боюсь, Ваша мысль так стремительно меняет темы, что мне трудно за ней успеть.

Если вопрос хорошо решается способом X - его надо решать способом X. Если вопрос криво решается способом Y - надо избегать решения его способом Y. Вопрос "нафига способ X если можно криво решить способом Y" - я удачным не считаю.

Почему в данном случае решение будет кривым - потому что на пустом месте требуется организовать взаимодействие процессов, что при серьезной реализации есть весьма нетривиальная задача. Например, я абсолютно уверен в том, что код, который Вы имеете в виду, не сможет написать пользователю: "Извините, но Вам придется подождать часика два-три, поскольку job, который должен вернуть мне данные, тормозится другим длинным job-ом и не может выполниться из-за слишком малого значения параметра job_queue_processes". Например, мне сразу вспоминается, как на сервере однажды глюканули аппаратные часы, и системное время (а за ним и next_date у всех job-ов) перепрыгнули в 2019-й год. Далее системное время вернули на место.... ну а описанная Вами программа так и будет ждать 2019-го года, дабы вернуть результат.

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

DrKonito softwarer DrKonitoА я вот например на ЦПП писать не умею.
Это тоже сильный аргумент. Посрамлен. Обязательно выучу чтобы было чем понтится на форумах.
Увы, снова слишком быстрый для меня полет мысли. Я так полагал, мы обсуждаем средства реализации задачи. Собственно, я так вообще полагаю одним из критериев профессионализма - умение и желание выбрать инструмент, наиболее подходящий для той или иной конкретной задачи. Меня всегда удивляла, например, позиции OracleForms-щиков: мол, не нужно учить еще один язык, чтобы писать клиентов, достаточно PL/SQL.

С Вашей точки зрения, как я понял, необразованностью следует гордиться, ликвидировать ее - только ради понтов на форумах, а что касается "выбрать подходящий инструмент" вопрос не стоит - нет, только ЦПП, поскольку Вы его не знаете и знать не хотите.

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

За последние 20 лет написано достаточно всего, чтобы позволить себе не думать об освобождении памяти и сортировках.
Хм. Боюсь, абсолютно не вижу смысла в этой фразе. Просто не понимаю, какую именно мысль Вы пытались донести.

Валентин КПроходил мимо, и опять господин softwarer поразил меня своей циничностью к оппонентам.
Вы ухитряетесь постоянно быть наполовину правым. В данном случае стоило бы сказать так: к некоторым оппонентам.

Валентин КНа первое - если место строения не влияет на строение, значит мы в космосе :)
Утверждение замечательно тем, что в нем (включая подразумеваемую иронию) содержатся сразу три грубых ошибки.

1. Мы действительно в космосе. Если говорить об ИТ-разработке, мы удивительно, на зависть остальным инженерным специальностям, независимы от "земли".

2. Вы действительно перевернули мир с ног на голову. Язык программирования - это не "место строения", это "материал" - доски, кирпичи, панели.. Место строения - это предметная область, особенности заказчика - в общем то, что можно объединить словами "техническое задание".

3. Глядя, как с грузовика сгружают и ставят стандартную для Москвы синюю будочку, я убеждаюсь, что "место строения" в типовых случаях очень мало влияет на "строение" - в пределах пары досок, подложенных с той либо с другой стороны.

Валентин КНа второе - ответ - просто непонятно зачем.
Поскольку ответ непонятно на что, выглядит более чем логично :)