Рефакторинг в SQL

[DIzer]

это если тупо "в лоб" - лучшие результаты (если это поле проиндексированно) групировка - SELECT FNAME FROM  TNAME GROUP BY FNAME ORDER BУ FNAME -  навскидку 

[vlad]

Забавно, с чего бы это? у меня противоположное.. -  по мне так SQL высокоуровневый ЯП для определения структур , их модификации, а также работы с данными (усвоил идеологию и вперед)- а вот работа через  API с БД напрямую- кака -бяка которой нужно избегать (уровень знаний НЕОБХОДИМЫЙ для выполнения СЛОЖНЫХ действий неизмеримо выше)  - ваш пример с модификациями системных таблиц хорошая иллюстрация тому....

API с БД - это вообще машкоды
Системные таблицы использовались, чтобы выцепить зависимости и тела процедур. Стандартного SQL решения для этого нет. Может еще для чего-то (даже вспоминать не хочу этот содом).

SQL по факту вообще ничего не может, что касается модификации "определений структур". Пример с размером колонки очень показателен. Максимум на что он (SQL сервер) способен - это обеспечить consistency, причем на абсолютно тупом уровне (с этой херней ничего нельзя сделать, потому что ее использует другая херня, досвидания). Причем хорошо, если он это скажет сразу, а не потом, когда запустится хранимая процедура. При всей кажущейся "правильности" строгого определения связей между структурами, на практике оказывается, что гемор с последующей модификацией структур не стоит этой "правильности". Применительно к M$ SQL у меня сейчас примерно такое практическое ограничение: все за пределами foreign key и primary key - идет нафиг. Причем foreign key изначально тоже ставится под вопрос. Весь остальной контроль за структурами, их связями и consistency делает не SQL сервер, а кто-то более умный.

[DIzer]

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

[vlad]

Все он может... снимите ограничения (например , удалите индексы,  деактивируйте триггеры) - и будет вам счастье (а потом создайте заново) - не будьте эгоистом 

Да, да. Именно этого "счастья" я и не хочу Создать трудности, чтобы потом их преодолевать. Именно об этом я писал в первом сообщении - слишком трудоемко.

[alexus]

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

Проблемы уйдут, когда все будет "правильно". Это я и так знаю Хотелось решения здесь и сейчас (а вдруго я чего-то недочитал, все таки SQL далеко не мой профиль).

Из общих выводов у меня пока сформировался такой: SQL - это ассемблер. Говорить, что он говно - неконструктивно, надо просто на нем не писать 

Простите, я не Вас имел ввиду... Нехорошо получилось...
SQL - это не ассемблер, он является высокоуровневым декларативным языком. Правда, с появлениями процедур и триггеров, декларативность становится относительной... В новой версии стандарта SQL, языком процедур предлагается/навязывается Java, которую СУБД могут/обязаны поддерживать.
Но сам опыт создания и развития SQL довольно интересен.
Работать с SQL надо... полезно. Мне, наоборот, не хватает "SQL" в... других частях проектов. Как бы было удобно: описал форму/отчёт один раз вне всяких приложений... и пользуешься из любого приложения, активируешь запросом и получаешь результат... с удалённым сервером... по готовой (декларативной) схеме взаимодействуешь стандартными средствами языка...
Наверное, в каждой приличной задаче можно выделить описательную/декларативную часть (схему), и работу через неё.
С моей точки зрения - это удобно... дело за стандартами...

[alexus]

Забавно, с чего бы это? у меня противоположное.. -  по мне так SQL высокоуровневый ЯП для определения структур , их модификации, а также работы с данными (усвоил идеологию и вперед)- а вот работа через  API с БД напрямую- кака -бяка которой нужно избегать (уровень знаний НЕОБХОДИМЫЙ для выполнения СЛОЖНЫХ действий неизмеримо выше)  - ваш пример с модификациями системных таблиц хорошая иллюстрация тому....

Стоп, стоп... не так быстро...
Через API взаимодействуют с сервером БД, то есть, с СУБД, а посредством SQL взаимодействуют с БД. Мы можем посредством API попросить сервер соединиться с БД, стартовать транзакцию или выполнить запрос, но сам запрос к БД пишется на SQL. Разные сервера имеют, соответственно, разный API, но SQL один для все... почти один... Поскольку СУБД и БД - разные понятия, то...
Конечно, есть некоторая область пересечения, и здесь я с Вами полностью согласен, в таких областях желательно максимально дистанцироваться от API... если потеря каких-то долей процентов производительности не является критическим фактором.

[vlad]

Из общих выводов у меня пока сформировался такой: SQL - это ассемблер. Говорить, что он говно - неконструктивно, надо просто на нем не писать 

Простите, я не Вас имел ввиду... Нехорошо получилось...
SQL - это не ассемблер, он является высокоуровневым декларативным языком.

Не важно какие у него заявленные/формальные свойства. Для описания/решения логики бизнес уровня - это ассемблер. Могу, конечно, оговориться, что для "моих задач"... но зачем, все известные проблемы ассемблера налицо. Да, конечно под "SQL" я подразумеваю все, что исполняется на конкретном SQL сервере.

Правда, с появлениями процедур и триггеров, декларативность становится относительной... В новой версии стандарта SQL, языком процедур предлагается/навязывается Java, которую СУБД могут/обязаны поддерживать.

ИМХО, тупиковый путь все равно. Хотя, конечно, если сравнивать с теми уродствами, которые я повидал в TRANSACT-SQL - жаба выглядит конфеткой.

Работать с SQL надо... полезно. Мне, наоборот, не хватает "SQL" в... других частях проектов. Как бы было удобно: описал форму/отчёт один раз вне всяких приложений... и пользуешься из любого приложения, активируешь запросом и получаешь результат... с удалённым сервером... по готовой (декларативной) схеме взаимодействуешь стандартными средствами языка...
Наверное, в каждой приличной задаче можно выделить описательную/декларативную часть (схему), и работу через неё.
С моей точки зрения - это удобно... дело за стандартами...

По вашему описанию я бы подумал, что вы говорите о веб сервисах Использовать SQL для такого могут предложить только в книжках про SQL какого-нибудь лохматого года (на заре появления клиент-серверных архитектур).

[alexus]

Не важно какие у него заявленные/формальные свойства. Для описания/решения логики бизнес уровня - это ассемблер. Могу, конечно, оговориться, что для "моих задач"... но зачем, все известные проблемы ассемблера налицо. Да, конечно под "SQL" я подразумеваю все, что исполняется на конкретном SQL сервере.

SQL не предназначен для "описания/решения логики бизнес уровня"!.. Для этого есть IDEF, ARIS и пр. На SQL декларируется структура БД (DDL часть) и запросы для работы с ней (DML часть).

Работать с SQL надо... полезно. Мне, наоборот, не хватает "SQL" в... других частях проектов. Как бы было удобно: описал форму/отчёт один раз вне всяких приложений... и пользуешься из любого приложения, активируешь запросом и получаешь результат... с удалённым сервером... по готовой (декларативной) схеме взаимодействуешь стандартными средствами языка...
Наверное, в каждой приличной задаче можно выделить описательную/декларативную часть (схему), и работу через неё.
С моей точки зрения - это удобно... дело за стандартами...

По вашему описанию я бы подумал, что вы говорите о веб сервисах Использовать SQL для такого могут предложить только в книжках про SQL какого-нибудь лохматого года (на заре появления клиент-серверных архитектур).

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

[DIzer]

......
Конечно, есть некоторая область пересечения, и здесь я с Вами полностью согласен, в таких областях желательно максимально дистанцироваться от API... если потеря каких-то долей процентов производительности не является критическим фактором.

Вот это я и имел  ввиду (полностью формулировать такие элементарные вещи лень, как показывает пример ilovb,  они воспринимаются с трудом - и потом, народ тут обидчивый, чуть что так - так претензии мол. не считайте меня за лоха.... а при этом требуют КОНКРЕТНЫХ решений и недоумевают в тех случаях, когда ответ очевиден ).