Oberon space
General Category => Общий раздел => Тема начата: vlad от Апрель 13, 2012, 03:37:57 pm
-
Раз уж пошла такая пьянка (про SQL)...
Рефакторинг, наверное, даже слишком громко сказано (alexus сразу начнет говорить "ибо нефиг")....
Просто. Была колонка CHAR(100). Стало мало. Надо сделать CHAR(255). Речь, естественно, не только о модификации таблицы, но и о модификации всяких триггеров и хранимых процедур. Их не очень много, но искать их (имеющих отношение к данной таблице) и в них нужное крайне трудоемко (по сравнению с традиционными статически типизированными языками). Что нужно делать, чтобы такие простые вещи не требовали столько усилий?
P.S. Применительно к M$ SQL. Я знаю, что в интербейзе было что-то типа typedef'ов. Не знаю насколько они полезны там, но в M$ SQL они тоже есть и они абсолютно бесполезны (для описанной проблемы).
P.S.S. Считаю SQL (как язык) полным говном. Не хотелось бы выплескивать негатив, но SQL мне кажется крайне неудачным языком для чего-либо кроме SELECT.
-
А триггеры и хранимые процедуры - это SQL?
-
А триггеры и хранимые процедуры - это SQL?
Я знаю, что у разных СУБД свои "языки хранимых процедур", но тем не менее, они пытаются выглядеть похожими на обычный SQL. Не вижу смысла здесь что-то противопоставлять (если только ты не считаешь это важным для решение сабжевой проблемы).
-
Я напрямую с СУБД не работаю, потому про рефакторинг ничего не скажу.
1С всю реструктуризацию при внесении изменений делает автоматически, там это возможно т.к. приложение абстрагировано от уровня таблиц. Тоже выход в принципе, если вы готовы пожертвовать гибкостью немного ;)
А SQL да дрянь... даже SELECT...
Нужен очень хороший конструктор запросов, чтобы с ним без напряга работать :)
Либо его чуток императивным сделать. Кто-нибудь использовал LINQ? Вроде там нечто такое сделали.
-
Я напрямую с СУБД не работаю, потому про рефакторинг ничего не скажу.
1С всю реструктуризацию при внесении изменений делает автоматически, там это возможно т.к. приложение абстрагировано от уровня таблиц. Тоже выход в принципе, если вы готовы пожертвовать гибкостью немного ;)
Т.е., общий ответ - ORM?
-
О! Вот как оказывается архитектура 1С называется ;D
Не знал, что этому подходу есть название.
Ну примерно так... да.
-
Раз уж пошла такая пьянка (про SQL)...
Рефакторинг, наверное, даже слишком громко сказано (alexus сразу начнет говорить "ибо нефиг")....
Просто. Была колонка CHAR(100). Стало мало. Надо сделать CHAR(255). Речь, естественно, не только о модификации таблицы, но и о модификации всяких триггеров и хранимых процедур. Их не очень много, но искать их (имеющих отношение к данной таблице) и в них нужное крайне трудоемко (по сравнению с традиционными статически типизированными языками). Что нужно делать, чтобы такие простые вещи не требовали столько усилий?
P.S. Применительно к M$ SQL. Я знаю, что в интербейзе было что-то типа typedef'ов. Не знаю насколько они полезны там, но в M$ SQL они тоже есть и они абсолютно бесполезны (для описанной проблемы).
P.S.S. Считаю SQL (как язык) полным говном. Не хотелось бы выплескивать негатив, но SQL мне кажется крайне неудачным языком для чего-либо кроме SELECT.
А зачем модифицировать триггеры и хранимые процедуру при изменении ширины колонки? Это ж как надо извратиться при написании тригера, чтобы в нем явно фигурировал размер колонки. Неужели имеет место?
Полное говно - это, видимо, про TRANSACT-SQL :)
-
Vlad - обычно в том случае, когда есть подозрение на то, что будут изменятся поля (типы, размеры) - используются домены (DOMAIN) - еще 10 лет назад любая уважающая себя sql СУБД - поддерживала работу с ними... ВСЕ изменения шли с помощью одного запроса вида ALTER DOMAIN DNAME SET....
-
А зачем модифицировать триггеры и хранимые процедуру при изменении ширины колонки? Это ж как надо извратиться при написании тригера, чтобы в нем явно фигурировал размер колонки. Неужели имеет место?
Дык, об чем и речь. Как? Например, как завести переменную (куда временно будет складываться что-то) размером с размер колонки? Никто бы не писал "DECLARE @var CHAR(100)" если бы можно было сослаться на тип колонки.
Полное говно - это, видимо, про TRANSACT-SQL :)
Да, видимо.
-
ЧУШЬ ;) :D
-
На вопрос конкретно как - ответ в руководстве по диалекту SQL соответствующей СУБД - в разделах DDL (язык определения данных - для синтаксиса определения домена, и его изменения) Разумеется таблицы ДОЛЖНЫ быть созданы с использование доменов а не базовых типов...
-
Vlad - обычно в том случае, когда есть подозрение на то, что будут изменятся поля (типы, размеры) - используются домены (DOMAIN) - еще 10 лет назад любая уважающая себя sql СУБД - поддерживала работу с ними... ВСЕ изменения шли с помощью одного запроса вида ALTER DOMAIN DNAME SET....
Видимо MS SQL не относится к "уважающим себя" :)
-
На вопрос конкретно как - ответ в руководстве по диалекту SQL соответствующей СУБД - в разделах DDL (язык определения данных - для синтаксиса определения домена, и его изменения)
Я ж говорю - не работает оно. Помню было у нас так поле объявлено через DDL - огребли больше, чем если бы ручками надо было искать CHAR(100). Подробностей сейчас не помню, но это было что-то из серии хардкорного ковыряния в системных таблицах и пересоздания всех хранимых процедур, в которых эта херня исользовалась. С тех пор было решено этой штукой не пользоваться никогда :)
-
Значит просто не поддерживает концепцию ... сочувствую :) - в следующей версии авось добавится - и Билли в очередной раз сдерет свое бабло... пользователям других СУБД - радостно гоготать, показывая пальцем... не несчастливцев ;D
-
На вопрос конкретно как - ответ в руководстве по диалекту SQL соответствующей СУБД - в разделах DDL (язык определения данных - для синтаксиса определения домена, и его изменения) Разумеется таблицы ДОЛЖНЫ быть созданы с использование доменов а не базовых типов...
Есть подозрение, что мы говорим о разных вещах, поэтому давайте конкретизирую:
Итак, MS SQL2005 и выше. Как объявить колонку в таблице, чтобы потом безболезненно ее расширять? Как ссылаться на тип этой колонки в хранимых процедурах и триггерах? Как, собственно, потому менять этот тип? Сразу оговорюсь, что пересоздание (ручное) всех процедур/триггеров не катит - нет полного контроля над базой (юзера могут сами туда чего-то добавлять/менять).
-
На вопрос конкретно как - ответ в руководстве по диалекту SQL соответствующей СУБД - в разделах DDL (язык определения данных - для синтаксиса определения домена, и его изменения) Разумеется таблицы ДОЛЖНЫ быть созданы с использование доменов а не базовых типов...
Есть подозрение, что мы говорим о разных вещах, поэтому давайте конкретизирую:
Итак, MS SQL2005 и выше. Как объявить колонку в таблице, чтобы потом безболезненно ее расширять? Как ссылаться на тип этой колонки в хранимых процедурах и триггерах? Как, собственно, потому менять этот тип? Сразу оговорюсь, что пересоздание (ручное) всех процедур/триггеров не катит - нет полного контроля над базой (юзера могут сами туда чего-то добавлять/менять).
Ответ для MS SQL2005 никак - просто эта фича, которая есть в стандарте аж 92 года не поддерживается , для других СУБД как я описал... результат выполнения запроса на изменения домена зависит от конкретной субд - в DB2 например у меня было изменена структура несколько таблиц, конвертированы данные но после того, как я переправил несколько процедур и триггеров (то есть пришлось делать запрос несколько раз - после неудачи выдавались зависимости мешающие его выполнению).
-
А триггеры и хранимые процедуры - это SQL?
Я знаю, что у разных СУБД свои "языки хранимых процедур", но тем не менее, они пытаются выглядеть похожими на обычный SQL. Не вижу смысла здесь что-то противопоставлять (если только ты не считаешь это важным для решение сабжевой проблемы).
Но похожесть на SQL не делает их SQL-ом (или делает? я не читал стандарт). А SQL - полным говном.
А единственное решение, приходящее мне в голову - не править БД вручную. Делать это через инструмент. Некий графический интерфейс. Правим какое-то поле, и изменения вносятся как в таблицы, так и в хранимые. Это всё. Чего-то более конкретного подсказать не могу. И более простого - тоже.
-
А единственное решение, приходящее мне в голову - не править БД вручную. Делать это через инструмент. Некий графический интерфейс. Правим какое-то поле, и изменения вносятся как в таблицы, так и в хранимые. Это всё. Чего-то более конкретного подсказать не могу. И более простого - тоже.
А практически все нормальный "инструменты"используют для правок БД либо SQL либо функции официального API - так что разница такая же как при работе с файлами через файловый менеджер vs командной строкой. :) Если необходимо разрешить конкретную ситуацию (а не рассуждать как в нее не попадать и какие есть средства в стандартном SQL, и говно он или нет ;D) например как у Влада то порядок возможных действий через SQL
1. Создать нужное временное поле в таблице ALTER TABLE....
2. Скопировать туда данные из изменяемого поля
3. Пробовать уничтожить ненужное поле - БД это не даст, пока есть зависимости (в триггерах, индексах....) которые она выдает в сообщениях - эти зависимости нужно разрешать (либо деактивировать триггеры, индексы.. если это возможно),
4. После того как зависимости разрешены а поле уничтожено, поменять название нового поля на старое
5 Активировать триггеры , построить (перестороить) индексы....
Это общий план для любой SQL Cубд- конкретика зависит от возможностей той СУБД в которой эти манипуляции производятся и структуры и зависимостей рассматриваемой таблицы (например, может быть просто достаточно изменить исходное поле)
-
Самое главное-то я и забыл сказать...
Поскольку, нужного инструмента не существует, то его нужно написать самому. Вот тут-то и появляются неприятные ощущения.
А практически все нормальный "инструменты"используют для правок БД либо SQL либо функции официального API - так что разница такая же как при работе с файлами через файловый менеджер vs командной строкой. :)
Может, аналогия с файловым менеджером и применима, но если я правильно понял Влада, то у него вполне определённая проблема, которую можно решить внешним инструментом (если такая возможность отсутствует в SQL).
Например, есть две таблицы. В одной имеются реквизиты владельцев, а в другой - реквизиты счёта. Целостность данных помогает поддерживать внешний ключ. Например, удаления в таблице владельцев запустят удаления в таблице счетов. То есть, в SQL есть механизм привязывания к ресурсу. Все, кто привязались к данному ресурсу, реагируют на определённые события.
Проблема Влада, если я её правильно понял, заключается в том, что в SQL нет адекватного механизма, привязывающего триггеры и хранимые к некоторым ресурсам. Инструмент, связывающий две таблицы - это внешний ключ, а инструмента, привязывающего действия к типам данных, нет. Решение - сделать инструмент, хранящий всю схему БД внутри себя и дополняющий её своими правилами. Если выполнять изменения БД через инструмент, то в СУБД будут передаваться команды вроде тех, которые Вы привели выше.
-
Самое главное-то я и забыл сказать...
Поскольку, нужного инструмента не существует, то его нужно написать самому. Вот тут-то и появляются неприятные ощущения.
.....
;) Как это не существует ? Стандартная консоль (аналог cmd) есть практически во всех SQL СУБД, Гуйный мэнагер в MSSQL изначально был одним из лучших...
;D А насчет неприятных ощущений... они возникают всегда, когда не понимаешь задачу и/или не знаешь как ее решить... и без разницы что это.
-
Про сторонние мэнагеры как общего плана, так с заточкой под MSSQL , бесплатные и не очень даже не говорю...
-
Это болезнь СИ шников лезть в СИСТЕМНЫЕ таблицы и править там что -то ни х. не понимая ВСЕХ последствий - (дело в том, что информация в этих таблицах МОЖЕТ отображаться точно также как и в обычных (и даже иметь сходную структуру), но из этого не следует что в общем случае ОБРАБАТЫВАТЬСЯ она будет также), правда есть исключения - системные таблицы, домены... в DB2 - обрабатываются обычными SQL -запросами.
-
Самое главное-то я и забыл сказать...
Поскольку, нужного инструмента не существует, то его нужно написать самому. Вот тут-то и появляются неприятные ощущения.
.....
;) Как это не существует ? Стандартная консоль (аналог cmd) есть практически во всех SQL СУБД
То есть, Вы хотите сказать, что консоль найдёт мне, какие элементы связаны с данным ресурсом? Хотя бы найдёт. Поменять я поменяю вручную, но ковыряться во всей схеме БД, чтобы найти пять или сем хранимок - это то ещё удовольствие.
-
Самое главное-то я и забыл сказать...
Поскольку, нужного инструмента не существует, то его нужно написать самому. Вот тут-то и появляются неприятные ощущения.
.....
;) Как это не существует ? Стандартная консоль (аналог cmd) есть практически во всех SQL СУБД
То есть, Вы хотите сказать, что консоль найдёт мне, какие элементы связаны с данным ресурсом? Хотя бы найдёт. Поменять я поменяю вручную, но ковыряться во всей схеме БД, чтобы найти пять или сем хранимок - это то ещё удовольствие.
:) Хочу - некоторые СУБД поддерживают команды возвращающие зависимости по обьекту... а если нет, или вы ленивы и/или не умеете работать с документацией- то ход действий я описал - пытаетесь уничтожить поле ПОСЛЕ того как сохранили информацию в поле НУЖНОЙ структуры (каждая НЕУДАВШАЯСЯ попытка вскрывает зависимости).
Да разумеется - этот выход НЕ ДЛЯ квалифицированных специалистов - те работают СТРОГО по принципу - выявил зависимости, выбрал ОПТИМАЛЬНЫЙ порядок действий, выполнил их.
-
Конечно "сохранили информацию в поле НУЖНОЙ структуры" - не грамотно сказано... речь идет о сохранении данных (записей).
-
Может, аналогия с файловым менеджером и применима, но если я правильно понял Влада, то у него вполне определённая проблема, которую можно решить внешним инструментом (если такая возможность отсутствует в SQL).
Например, есть две таблицы. В одной имеются реквизиты владельцев, а в другой - реквизиты счёта. Целостность данных помогает поддерживать внешний ключ. Например, удаления в таблице владельцев запустят удаления в таблице счетов. То есть, в SQL есть механизм привязывания к ресурсу. Все, кто привязались к данному ресурсу, реагируют на определённые события.
SQL накладывает требования на язык, но он не регламентирует структуру метаданных и работу с ними (см. например (http://ru.wikipedia.org/wiki/SQL/Schemata)). Это остаётся в руках разработчиков СУБД. И это правильное решение. Стандартизация хороша до определённого момента. В ЯВУ тоже стандарты языков не распространяются на реализацию компиляторов, линкеров, мапперов и пр.
Далее, если к каким-то объектам БД (таблицам, представлениям (view), процедурам или триггерам, ...) происходит обращение от других объектов БД, то эти связи хранятся в метаданных. При удалении, например, поля таблицы СУБД должна либо отказать в удалении, либо предупредить, что связи с другими объектами будут разорваны, что чревато неприятными последствиями.
Проблема Влада, если я её правильно понял, заключается в том, что в SQL нет адекватного механизма, привязывающего триггеры и хранимые к некоторым ресурсам. Инструмент, связывающий две таблицы - это внешний ключ, а инструмента, привязывающего действия к типам данных, нет. Решение - сделать инструмент, хранящий всю схему БД внутри себя и дополняющий её своими правилами. Если выполнять изменения БД через инструмент, то в СУБД будут передаваться команды вроде тех, которые Вы привели выше.
Проблемы Влада, если я их правильно понял... совсем в другом... Правда, он уже начал читать, может быть начнёт думать, а если ещё и практику приложит, то есть шанс, что... проблемы, о которых он пытался рассказать, уйдут сами собой...
-
Проблемы Влада, если я их правильно понял... совсем в другом... Правда, он уже начал читать, может быть начнёт думать, а если ещё и практику приложит, то есть шанс, что... проблемы, о которых он пытался рассказать, уйдут сами собой...
Проблемы уйдут, когда все будет "правильно". Это я и так знаю :) Хотелось решения здесь и сейчас (а вдруго я чего-то недочитал, все таки SQL далеко не мой профиль).
Из общих выводов у меня пока сформировался такой: SQL - это ассемблер. Говорить, что он говно - неконструктивно, надо просто на нем не писать :)
-
Забавно, с чего бы это? у меня противоположное.. - по мне так SQL высокоуровневый ЯП для определения структур , их модификации, а также работы с данными (усвоил идеологию и вперед)- а вот работа через API с БД напрямую- кака -бяка которой нужно избегать (уровень знаний НЕОБХОДИМЫЙ для выполнения СЛОЖНЫХ действий неизмеримо выше) - ваш пример с модификациями системных таблиц хорошая иллюстрация тому....
-
2Valexey SELECT DISTINCT FIELDNAME FROM TABLENAME (здесь FIELDNAME,TABLENAME название фактических поля и таблицы - для большинства диалектов SQL (но могут быть исключения - нужно смотреть сверится с руководством SQL конкретной базы в разделе DML (DATA MANIPULATION LANGUAGE) ) )
-
2Valexey SELECT DISTINCT FIELDNAME FROM TABLENAME (здесь FIELDNAME,TABLENAME название фактических поля и таблицы - для большинства диалектов SQL (но могут быть исключения - нужно смотреть сверится с руководством SQL конкретной базы в разделе DML (DATA MANIPULATION LANGUAGE) ) )
Угу. Спасибо.
-
это если тупо "в лоб" - лучшие результаты (если это поле проиндексированно) групировка - SELECT FNAME FROM TNAME GROUP BY FNAME ORDER BУ FNAME - навскидку ;)
-
Забавно, с чего бы это? у меня противоположное.. - по мне так SQL высокоуровневый ЯП для определения структур , их модификации, а также работы с данными (усвоил идеологию и вперед)- а вот работа через API с БД напрямую- кака -бяка которой нужно избегать (уровень знаний НЕОБХОДИМЫЙ для выполнения СЛОЖНЫХ действий неизмеримо выше) - ваш пример с модификациями системных таблиц хорошая иллюстрация тому....
API с БД - это вообще машкоды ;)
Системные таблицы использовались, чтобы выцепить зависимости и тела процедур. Стандартного SQL решения для этого нет. Может еще для чего-то (даже вспоминать не хочу этот содом).
SQL по факту вообще ничего не может, что касается модификации "определений структур". Пример с размером колонки очень показателен. Максимум на что он (SQL сервер) способен - это обеспечить consistency, причем на абсолютно тупом уровне (с этой херней ничего нельзя сделать, потому что ее использует другая херня, досвидания). Причем хорошо, если он это скажет сразу, а не потом, когда запустится хранимая процедура. При всей кажущейся "правильности" строгого определения связей между структурами, на практике оказывается, что гемор с последующей модификацией структур не стоит этой "правильности". Применительно к M$ SQL у меня сейчас примерно такое практическое ограничение: все за пределами foreign key и primary key - идет нафиг. Причем foreign key изначально тоже ставится под вопрос. Весь остальной контроль за структурами, их связями и consistency делает не SQL сервер, а кто-то более умный.
-
Все он может... снимите ограничения (например , удалите индексы, деактивируйте триггеры) - и будет вам счастье (а потом создайте заново) - не будьте эгоистом :) то что вы хотите сделать делается на работающей базе (с потенциальными пользователями и запущенными внутренними процессами) -должна же у БД быть какая то защита от Владов ковыряющихся в таблицах ;D
-
Все он может... снимите ограничения (например , удалите индексы, деактивируйте триггеры) - и будет вам счастье (а потом создайте заново) - не будьте эгоистом :)
Да, да. Именно этого "счастья" я и не хочу ;) Создать трудности, чтобы потом их преодолевать. Именно об этом я писал в первом сообщении - слишком трудоемко.
-
Проблемы Влада, если я их правильно понял... совсем в другом... Правда, он уже начал читать, может быть начнёт думать, а если ещё и практику приложит, то есть шанс, что... проблемы, о которых он пытался рассказать, уйдут сами собой...
Проблемы уйдут, когда все будет "правильно". Это я и так знаю :) Хотелось решения здесь и сейчас (а вдруго я чего-то недочитал, все таки SQL далеко не мой профиль).
Из общих выводов у меня пока сформировался такой: SQL - это ассемблер. Говорить, что он говно - неконструктивно, надо просто на нем не писать :)
Простите, я не Вас имел ввиду... Нехорошо получилось...
SQL - это не ассемблер, он является высокоуровневым декларативным языком. Правда, с появлениями процедур и триггеров, декларативность становится относительной... В новой версии стандарта SQL, языком процедур предлагается/навязывается Java, которую СУБД могут/обязаны поддерживать.
Но сам опыт создания и развития SQL довольно интересен.
Работать с SQL надо... полезно. Мне, наоборот, не хватает "SQL" в... других частях проектов. Как бы было удобно: описал форму/отчёт один раз вне всяких приложений... и пользуешься из любого приложения, активируешь запросом и получаешь результат... с удалённым сервером... по готовой (декларативной) схеме взаимодействуешь стандартными средствами языка...
Наверное, в каждой приличной задаче можно выделить описательную/декларативную часть (схему), и работу через неё.
С моей точки зрения - это удобно... дело за стандартами...
-
Забавно, с чего бы это? у меня противоположное.. - по мне так SQL высокоуровневый ЯП для определения структур , их модификации, а также работы с данными (усвоил идеологию и вперед)- а вот работа через API с БД напрямую- кака -бяка которой нужно избегать (уровень знаний НЕОБХОДИМЫЙ для выполнения СЛОЖНЫХ действий неизмеримо выше) - ваш пример с модификациями системных таблиц хорошая иллюстрация тому....
Стоп, стоп... не так быстро... :)
Через API взаимодействуют с сервером БД, то есть, с СУБД, а посредством SQL взаимодействуют с БД. Мы можем посредством API попросить сервер соединиться с БД, стартовать транзакцию или выполнить запрос, но сам запрос к БД пишется на SQL. Разные сервера имеют, соответственно, разный API, но SQL один для все... почти один... Поскольку СУБД и БД - разные понятия, то...
Конечно, есть некоторая область пересечения, и здесь я с Вами полностью согласен, в таких областях желательно максимально дистанцироваться от API... если потеря каких-то долей процентов производительности не является критическим фактором.
-
Из общих выводов у меня пока сформировался такой: SQL - это ассемблер. Говорить, что он говно - неконструктивно, надо просто на нем не писать :)
Простите, я не Вас имел ввиду... Нехорошо получилось...
SQL - это не ассемблер, он является высокоуровневым декларативным языком.
Не важно какие у него заявленные/формальные свойства. Для описания/решения логики бизнес уровня - это ассемблер. Могу, конечно, оговориться, что для "моих задач"... но зачем, все известные проблемы ассемблера налицо. Да, конечно под "SQL" я подразумеваю все, что исполняется на конкретном SQL сервере.
Правда, с появлениями процедур и триггеров, декларативность становится относительной... В новой версии стандарта SQL, языком процедур предлагается/навязывается Java, которую СУБД могут/обязаны поддерживать.
ИМХО, тупиковый путь все равно. Хотя, конечно, если сравнивать с теми уродствами, которые я повидал в TRANSACT-SQL - жаба выглядит конфеткой.
Работать с SQL надо... полезно. Мне, наоборот, не хватает "SQL" в... других частях проектов. Как бы было удобно: описал форму/отчёт один раз вне всяких приложений... и пользуешься из любого приложения, активируешь запросом и получаешь результат... с удалённым сервером... по готовой (декларативной) схеме взаимодействуешь стандартными средствами языка...
Наверное, в каждой приличной задаче можно выделить описательную/декларативную часть (схему), и работу через неё.
С моей точки зрения - это удобно... дело за стандартами...
По вашему описанию я бы подумал, что вы говорите о веб сервисах ;) Использовать SQL для такого могут предложить только в книжках про SQL какого-нибудь лохматого года (на заре появления клиент-серверных архитектур).
-
Не важно какие у него заявленные/формальные свойства. Для описания/решения логики бизнес уровня - это ассемблер. Могу, конечно, оговориться, что для "моих задач"... но зачем, все известные проблемы ассемблера налицо. Да, конечно под "SQL" я подразумеваю все, что исполняется на конкретном SQL сервере.
SQL не предназначен для "описания/решения логики бизнес уровня"!.. Для этого есть IDEF, ARIS и пр. На SQL декларируется структура БД (DDL часть) и запросы для работы с ней (DML часть).
Работать с SQL надо... полезно. Мне, наоборот, не хватает "SQL" в... других частях проектов. Как бы было удобно: описал форму/отчёт один раз вне всяких приложений... и пользуешься из любого приложения, активируешь запросом и получаешь результат... с удалённым сервером... по готовой (декларативной) схеме взаимодействуешь стандартными средствами языка...
Наверное, в каждой приличной задаче можно выделить описательную/декларативную часть (схему), и работу через неё.
С моей точки зрения - это удобно... дело за стандартами...
По вашему описанию я бы подумал, что вы говорите о веб сервисах ;) Использовать SQL для такого могут предложить только в книжках про SQL какого-нибудь лохматого года (на заре появления клиент-серверных архитектур).
Любая приличная задача явно требует стадии анализа и моделирования предметной области. Структура БД - это частный случай модели, выполненной по определённым правилам (построение реляционной модели). Здесь нет/не должно быть бизнес-логики (правил/порядка выполнения каких-либо операций), только элементы и связи.
-
......
Конечно, есть некоторая область пересечения, и здесь я с Вами полностью согласен, в таких областях желательно максимально дистанцироваться от API... если потеря каких-то долей процентов производительности не является критическим фактором.
Вот это я и имел ввиду (полностью формулировать такие элементарные вещи лень, как показывает пример ilovb, они воспринимаются с трудом - и потом, народ тут обидчивый, чуть что так - так претензии мол. не считайте меня за лоха.... а при этом требуют КОНКРЕТНЫХ решений и недоумевают в тех случаях, когда ответ очевиден ). :D