Leonid Kudryavtsevвадятебе просто хочется пов...ся, в любом случае необходимо указывать имя субд mssql, mysql, fb,....
и этим будет сказаны все языковые тонкости и различия sql.
Да нет языковых тонкостей
SQL (Select) для программирования (написания кода) не предназначен. И Select изначально предназначен исключительно как язык доступа к нормализованным реляционным данным, представленный в виде нормализованных табличек и описания отношений между ними.
Для программирования сторед процедур предназначены языки ПРОГРАММИРОВАНИЯ.
В последних, проблем с ООП нет как класс. Ну хочешь ООП, ну создай себе классы хотья на Java, хоть на PL/SQL. В чем-пробема?
Проблемы начинаются при попытке скрестить ежа и удава. ООП и реляционной базы данных.
Специально нашел Гради Буча "Объектно ориентированный анализ и проектирование". На 3-ей же страницы
Пять признаков сложной системы
Исходя из такого способа изучения, можно вывести пять общих признаков любой сложной системы. Основываясь на работе Саймона и Эндо, Куртуа предлагает следующее наблюдение [7]:
1. "Сложные системы часто являются иерархическими и состоят из взаимозависимых подсистем, которые в свою очередь также могут быть разделены на подсистемы, и т.д., вплоть до самого низкого уровням."
Саймон отмечает: "тот факт, что многие сложные системы имеют почти разложимую иерархическую структуру, является главным фактором, позволяющим нам понять, описать и даже "увидеть" такие системы и их части" [8]. В самом деле, скорее всего, мы можем понять лишь те системы, которые имеют иерархическую структуру.
Важно осознать, что архитектура сложных систем складывается и из компонентов, и из иерархических отношений этих компонентов. Речтин отмечает: "Все системы имеют подсистемы, и все системы являются частями более крупных систем... Особенности системы обусловлены отношениями между ее частями, а не частями как таковыми" [9].
Что же следует считать простейшими элементами системы? Опыт подсказывает нам следующий ответ:
2. Выбор, какие компоненты в данной системе считаются элементарными, относительно произволен и в большой степени оставляется на усмотрение исследователя.
Низший уровень для одного наблюдателя может оказаться достаточно высоким для другого.
Саймон называет иерархические системы разложимыми, если они могут быть разделены на четко идентифицируемые части, и почти разложимыми, если их составляющие не являются абсолютно независимыми. Это подводит нас к следующему общему свойству всех сложных систем:
3. "Внутрикомпонентная связь обычно сильнее, чем связь между компонентами. Это обстоятельство позволяет отделять "высокочастотные" взаимодействия внутри компонентов от "низкочастотной" динамики взаимодействия между компонентами" [10].
Это различие внутрикомпонентных и межкомпонентных взаимодействий обуславливает разделение функций между частями системы и дает возможность относительно изолированно изучать каждую часть.
Как мы уже говорили, многие сложные системы организованы достаточно экономными средствами. Поэтому Саймон приводит следующий признак сложных систем:
4. " Иерархические системы обычно состоят из немногих типов подсистем, по-разному скомбинированных и организованных" [11].
Иными словам и, разные сложные системы содержат одинаковые структурные части. Эти части могут использовать общие более мелкие компоненты, такие как клетки, или более крупные структуры, типа сосудистых систем, имеющиеся и у растений, и у животных.
Выше мы отмечали, что сложные системы имеют тенденцию к развитию во времени. Саймон считает, что сложные системы будут развиваться из простых гораздо быстрее, если для них существуют устойчивые промежуточные формы [12]. Гэлл [13] выражается более эффектно:
5. "Любая работающая сложная система является результатом развития работавшей более простой системы... Сложная система, спроектированная "с нуля", никогда не заработает. Следует начинать с работающей простой системы".
В процессе развития системы объекты, первоначально рассматривавшиеся как сложные, становятся элементарными, и из них строятся более сложные системы. Более того, невозможно сразу правильно создать элементарные объекты: с ними надо сначала повозиться, чтобы больше узнать о реальном поведении системы, и затем уже совершенствовать их.
Найдите хоть один из них в РЕЛЯЦИОННОЙ и нормализованной базе данных.
Нафига тогда приплетать ООП, к языку ЗАПРОСОВ для реляционной БД ?
ООП предназначено в первую очередь уменьшить сложность систем...
Реляционные базы данныхи и SQL, аналогично уменьшить сложность, за счет замены сети и иерархии (есть/были еще сетевые, иерархические СУБД) на таблицы и отношения между таблицами.
В настоящий же момент, зачем-то пытаются наоборот, увеличить сложность системы.
В общем, почти как трусы и крестик. Отсюда и образуются два координально разных подход к скрещиванию ООП и Реляционных Баз данных:
1. Реляционный - переложить модель внешнего мира в нормальную структуру таблиц и по возможности максимально нормализовать ее. Но при этом, ООП становится нужен как собаке пятая нога.
(для программ и сторед процедур, ООП как бы и не плохо, просто как развитие идеи модульности. Но никто и не мешает его использовать в этом качестве)
2. ООП-сериализационный - сделать табличку ID, Object и в Object запихать все данные объекта. В XML, Json'е или вообще бинари. А потом удивляться, что реляционная БД плохо работают. Точнее, что разница между реляционной БД и обычным текстовым файлом становится чуть больше, чем ни какая. В крайнем случае, вполне можно и key - value БД обойтись.
Ну и разные попытки скрестить ежа и удава... Только IMHO до сих пор получается колючая проволока.
Эээх))) Хотел было поизголяться, ибо тут есть над чем, но не буду, а то всех распугаю)))
В общем, понимаю Ваше отношение, оно основано на совершенно правильных, современных представлениях.
Видно что Вы прекрасный специалист. Но поймите, что иногда ситуация меняется. появляются инновации. Вот у Вас же наверное в гараже машина а не в пещере лошадь?
Так и здесь, есть инновация, которая позволяет гармонично скрестить ООП и реляционную модель, которые, как оказалось не так уж друг другу ортогональны. Что и пытались сделать много лет назад все кому не лень, но просто не вышло.
Иначе вся бизнес-логика давно уже жила бы в СУБД, ибо с точки зрения архитектуры систем это дает множество преимуществ, которые я описал выше.
