Bogdanov Andrey drev
Давайте я попробую привести Вам пример некоей архитектуры, а Вы скажите, есть ли выигрыш в использовании процедур или нет.
<skipped>

Замечу, что описаное не имеет никакого отношения к SUID-процедурам. Это тот самый слой бизнес представления информации храняшейся в базе данных. Соответственно клиентское приложение работает не с таблицами, а некоторыми бизнес-объектами, которые вы называете XML-документами. И в данном случае реализация средствами ХП это не вопрос выбора удобного интерфейса к СУБД, а вопрос выбора места реализации бизнес-логики.

Ну и немного по-поводу преимуществ:
drev
- реальная структура базы полностью изолирована от аппликации
- изменение структуры документа не требует изменения модуля доступа к БД.

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


1. SUID-процедуры - частный случай представленной архитектуры
2. организация ввода-вывода информации в базу данных не совсем бизнес логика, правда?
3. Вы почему то не обратили внимание на слова "изменения модуля доступа к БД." Он не включает в себя экранные формы, к счастью.

Давайте я приведу Вам пример:

Предположим, в базе было принято решение изменить хранение одного из details. Вместо отдельной таблицы использовать XML-type.

Приложение (в месте отправки информациии в базу данных) не изменится.

А фразы, выделеной красным, я вообще не понял

Aviant drev- реальная структура базы полностью изолирована от аппликации
Ну вот опять. Это не преимущество само по себе. Ну изолирована, ну и что ?

drev - ваша схема работы понятна, схема как схема, если отточили и работает то и ладненько. Однако вы имеете каждый раз накладные расходы по составлению и распарсиванию XML на клиенте и сервере просто так, ради красоты идеи.

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


1. Про изоляцию смотрите пример с XML-type выше. Я уже не говорю о миграции на другой сервер.
2. А кто вам сказал, что ХМЛ парсается и составляется на клиенте? Он там может жить:) Или передаваться из другого приложения.
3. Попробуйте сравнить время выполнения такой процедуры и нескольких десятков инсеров из аппликацции. Сильно будете удивлены.
4. Подозрения не оправданы

Bogdanov Andrey[quot drev]
То есть у вас между экранными формами, которые могли бы работать с БД напрямую , и базой данных навернуто еще три слоя? Сначала преобразование данных формы в XML, потом некий "модуль доступа", а потом еще ХП, делающие обратное преобразование? И это плата за изоляцию?
Но в вашем варианте какие-то преимущества подхода я обнаруживаю. Хотя на мой взгляд недостатков они не покрывают (хотя это зависит от внешних требований). А вот для случая SUID-процедур я никаких преимуществ не вижу.

1. Понимаете, формы не всегда работают ц БД напрямую:) Если совсем честно, за последние лет 10 я такого не видел. Умные люди придумали такое понятие как data access layer.

2. Понимаете, есть такие приложения, когда данные из формы приходят в виде XML :) И их преобразовывать не нужно:)

Aviant drev Я уже не говорю о миграции на другой сервер. ... где этого типа может и не быть.


Вы мне нравитесь:) Логикой:) Вернее.. Cлова "Не говоря уже" являются семантическим разделителем. грубо говоря, это уже другое высказывание, независимое от первого. Суть ВТОРОГО высказывания в том, что в данной модели приложению безразличного какие фунциональные возможности предоставляет вендор и какова реально структура базы.


Aviant


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


Может, криво написали?:) 2005.

Aviant

drev4. Подозрения не оправданы Конечно, всего лишь каждый раз ручками быстренько написать xml-чик. Круче этого только все передавать blob-ом или огромной битовой маской

.
Вы не пробовали при тестировании не каждый раз писать ручками, а , сохранять скажем:) и почему ручками?:)
Aviant
сейчас специалисты попьют кофе и расскажут вам про XML



с удовольствием послушаю:)

Bogdanov Andrey drev
1. Понимаете, формы не всегда работают ц БД напрямую:) Если совсем честно, за последние лет 10 я такого не видел. Умные люди придумали такое понятие как data access layer.

Умные люди не занимаются бессмысленными сериализациями/десериализациями данных внутри этого data access layer. Да и напрямую умные люди очень даже работают.

drev
2. Понимаете, есть такие приложения, когда данные из формы приходят в виде XML :) И их преобразовывать не нужно:)
То есть пользователь в форму прямо xml вбивает? Я вам завидую - мне бы таких пользователей. :)

1. я же объяснил, сериализация не всегда нужна.

2. Формы могут на web находится. И приходить на сервер в виде XML.

3. Это Вы про что-то типа Oracle Forms?:)

Bogdanov Andrey drev2. Формы могут на web находится. И приходить на сервер в виде XML.
Web-формы вполне и без xml обходиться могут. А вот без сервера приложений - наверное не могут.

drev3. Это Вы про что-то типа Oracle Forms?:)
Сейчас достаточно инструментариев для разработки клиент-серверных приложений. И большинство из них вполне адекватно работают с базой данных. Хотя некоторые программисты пытаются приделать даже к этим инструментариям пятую ногу в виде дополнительной прослойки между программистом и базой данных.
Я подозрерваю, что это от безграмотности - вижу множество людей неплохо пишущих на C или Java, но при слове Oracle их почему-то в дрожь бросает.

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

Эти задачи - разные и решать их одинаковыми методами - неразумно.
Но почему-то все апологеты процедурного сохранения пытаются представить их как нечто универсальное.

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

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

Bely drevВарианта б) практически не существует.. В большинстве случаев не приложение интерфейс базы данных, а база данных - одно из хранилищ информации приложения. И это не единственное хранилище.Мой опыт говорит как раз об обратном - в нормальных системах все вертится вокруг базы (или нескольких баз), а приложения - это обработка/отображение/представление данных из базы.

Не помню кто, но кто-то из классиков сформулировал принцип: не алгоритм управляет данными - а данные управляют работой алгоритма.
Это к вопросу о том, кто главнее - данные или программы.

Будет очень интересно услышать мнение людей, которые написали CISCO Call Manager по этому поводу :)
Что SQL Server, который был использован в четверке как место хранения - главная часть их системы:)

Bely drev BelyНе помню кто, но кто-то из классиков сформулировал принцип: не алгоритм управляет данными - а данные управляют работой алгоритма.
Это к вопросу о том, кто главнее - данные или программы.

Будет очень интересно услышать мнение людей, которые написали CISCO Call Manager по этому поводу :)
Что SQL Server, который был использован в четверке как место хранения - главная часть их системы:)Не передергивайте.
Для CCM главные данные - VoIP пакеты и таблицы маршрутизации этих пакетов.

Если смотреть на коня сзади, то может показаться, что управлять им надо дергая за хвост.
Смотреть надо - с правильной стороны.

Хм.. это я передергиваю? Леги где хранятся?:) В базе, правда?

Bely drev Bely drev BelyНе помню кто, но кто-то из классиков сформулировал принцип: не алгоритм управляет данными - а данные управляют работой алгоритма.
Это к вопросу о том, кто главнее - данные или программы.

Будет очень интересно услышать мнение людей, которые написали CISCO Call Manager по этому поводу :)
Что SQL Server, который был использован в четверке как место хранения - главная часть их системы:)Не передергивайте.
Для CCM главные данные - VoIP пакеты и таблицы маршрутизации этих пакетов.

Если смотреть на коня сзади, то может показаться, что управлять им надо дергая за хвост.
Смотреть надо - с правильной стороны.

Хм.. это я передергиваю? Леги где хранятся?:) В базе, правда?Учимся читать...
авторДля CCM главные данные - VoIP пакеты и таблицы маршрутизации этих пакетов.

1. Учимся не хамить :)
2. Учимся отвечать на вопросы по существу, а не прикрывать свое непонимание демагогией :)

drev Bely drev Bely drev BelyНе помню кто, но кто-то из классиков сформулировал принцип: не алгоритм управляет данными - а данные управляют работой алгоритма.
Это к вопросу о том, кто главнее - данные или программы.

Будет очень интересно услышать мнение людей, которые написали CISCO Call Manager по этому поводу :)
Что SQL Server, который был использован в четверке как место хранения - главная часть их системы:)Не передергивайте.
Для CCM главные данные - VoIP пакеты и таблицы маршрутизации этих пакетов.

Если смотреть на коня сзади, то может показаться, что управлять им надо дергая за хвост.
Смотреть надо - с правильной стороны.

Хм.. это я передергиваю? Леги где хранятся?:) В базе, правда?Учимся читать...
авторДля CCM главные данные - VoIP пакеты и таблицы маршрутизации этих пакетов.

1. Учимся не хамить :)
2. Учимся отвечать на вопросы по существу, а не прикрывать свое непонимание демагогией :)

P.S. Кстати, Вы .. этот .. "все ещё программист" :) Может, слышали про STL? Алгоритмы как бы одни и те же?:) От данных не зависят?:)

Bely drev1. Учимся не хамить :)
2. Учимся отвечать на вопросы по существу, а не прикрывать свое непонимание демагогией :)Никто не хамит, просто в таком ключе, как он идет, разговор вести бессмысленно.
Демагогией занимаетесь именно Вы.
Вы просто игнорируете те фразы, которые вам не удобны и перевираете вырванные из контекста другие фразы.

Про логи IPCC (и любого другого) - это отдельный впомоательный модуль системы.
Если логи хранятся на SQL сервере - то процедура записи в лог может выглядеть как ХП, так и как обычный INSERT. Логи могут вообще писаться в текстовый файл.
Главное здесь - поток логируемых ДАННЫХ. Модуль их обработки - может быть любой, какой удобен в каждом конкретном случае и который справляется с необходимой скоростью поступления данных.

Кроме этого - логи бывают разного уровня.
Debug Info - мало кто пишет в базу. Их обычно пишут в обычный текстовый или бинарный файл.
Классическая программа, которая ТОЛЬКО пишет в лог (ее основная функция) - это SYSLOG.

Теперь что касается данных и алгоритмов.
То что я привел - это мнение (кажется Дэйкстры) по поводу того, что первично - алгоритм или данные.
Так вот, данные - первичны. Именно данные в первую очередь определят КАК работает программа.
Развитием этой концепции стал ООП подход, где к ДАННЫМ пристыковываются МЕТОДЫ их обработки (а не наоборот).

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

за сим откланиваюсь


У Вас удачно получается спорить о вкусе устриц с теми, кто их ел.

Вы с такой уверенностью рассуждали об архитектуре Call Manager, что мне и в голову не пришло, что Вы настолько его не знаете.

drev
Хм.. это я передергиваю? Леги где хранятся?:) В базе, правда?


Я ни разу не упомянул лОги (logs). ЛЕги , упомянутые мной - Call Legs.

A call leg is a logical connection between two router/gateways or between a router/gateway and an IP Telephony device (for example Cisco CallManager, SIP Server, and so forth).

(http://www.cisco.com/warp/public/788/voip/dialpeer_call_leg.html#peers)

Смотрите картинку.

Извините, но в виду того, что мы говорим о телефонии, поговорка "Слышу звон, но не знаю, где он" приобретает двойной смысл:)

Далее становится ещё интереснее:

BelyТо что я привел - это мнение (кажется Дэйкстры) по поводу того, что первично - алгоритм или данные.
Так вот, данные - первичны.

В русской трансляции он скорее Дийкстра, но это так, к слову.

Понимаете, молодой человек, мнение , даже такого уважаемого человека, не обязательно есть истина в последней инстанции.

Помимо ООП (который,судя по Вашим высказываниям, Вы понимаете нескоько упрощённо), есть и другие парадигмы, например, generic programming.

STL (Standard Template Library), есть одна из имплементаций данной парадигмы. Сильно упрощённый пример - создаётся алгоритм, например, sort, который единообразно сортирует любые данные. T.e. алгоритм - первичен, не так ли?

Резюмируя

а) читаем, что сказал собеседник.
б) если не знаем, как в ситуации с лЕгами/лОгами, спрашиваем.
в) забываем юношеский максимализм и начинаем понимать, что мнений может быть больше одного.

Вы пишете о себе: " все еще программист :)"

На мой взгляд, скорее " ещё не ".