Здравствуйте, Sinclair, Вы писали:

.>>Нет, совсем нет. Ещё оператор примитивной рекурсии забыл.
S>Но-но, не надо тут метамодели привлекать. А то недалеко и до Зеноновых парадоксов. Вот где у нас "оператор применения оператора"? А без него непонятно, почему это мы считаем себя вправе применить рекурсию.
Это к чему? Чтобы система стала turing complete, "ноль, инкремент, и выбор N-го аргумента" не хватит, нужно ещё, например, оператор примитивной рекурсии добавить — получится ПРФ. Классический sql не обладает turing-completeness, скажем, на нём невозможно написать неостанавливающийся (т.е. хотя бы тупо зависающий) алгоритм.

Здравствуйте, Cyberax, Вы писали:

C>Ну добавь:
C>

C>select pr.id, pr.name, ..., grp.id, grp.name, grp.code from prefect pr
C>inner join group grp on pr.parent_group=grp.id
C>inner join student st on st.parent_group=grp.id
C>where st.id=?
C>

C>Т.е. сразу загружаем нужные данные.
Вот! Вот!

S>>Во-вторых, этот код никакого отношения к принципу Деметры не имеет, поскольку здесь нет разыменования ссылок. Совсем.
C>Есть. Точно такое же, как и в student.getParentGroup().getPrefect(). Просто оно выражается по-другому — через объединения по PK.
Во-первых, не точно такое же. Перечитай свой запрос. Ему вообще нет никакого аналога в ООП — мы отобразили некий граф кортежей в список кортежей. Это атомарная операция, как, к примеру, умножение матриц. Или ты полагаешь, что принцип Деметры запрещает писать F = A * B * C в одной строке?

C>Ну так берём коллекцию AllObjects — и выбираем на ней нужные объекты с помощью фильтра. То же самое получится. Только вот это глупо, без where мы полную фигню получим. А с where у нас симметрия моментально теряется.
Это иллюзия.

Здравствуйте, Sinclair, Вы писали:

C>>Есть. Точно такое же, как и в student.getParentGroup().getPrefect(). Просто оно выражается по-другому — через объединения по PK.
S> Во-первых, не точно такое же. Перечитай свой запрос. Ему вообще нет никакого аналога в ООП — мы отобразили некий граф кортежей в список кортежей.
student.getParentGroup().getPrefect() — это тоже операция над графом объектов, взятие объекта по заданной оси. Я могу это записать на декларативном языке JDOM: "jdom.query("student/parentGroup/prefect", student).execute()". То что эта операция записывается в виде вызова обычных методов — ну уж извините, просто используем фичи языка.

S>Это атомарная операция, как, к примеру, умножение матриц. Или ты полагаешь, что принцип Деметры запрещает писать F = A * B * C в одной строке?
Ну да, мой пример — прямой аналог A * B * C.

Так что если оно нарушает этот принцип, то и SQL-запрос его будет нарушать.

C>>Ну так берём коллекцию AllObjects — и выбираем на ней нужные объекты с помощью фильтра. То же самое получится. Только вот это глупо, без where мы полную фигню получим. А с where у нас симметрия моментально теряется.
S>Это иллюзия.
Где?

Здравствуйте, Cyberax, Вы писали:

JDOM: "jdom.query("student/parentGroup/prefect", student).execute()".
Молодец, правильно мыслишь. Как только ты так сделаешь, ты обойдешь принцип Деметры.
C> То что эта операция записывается в виде вызова обычных методов — ну уж извините, просто используем фичи языка.
А если операция будет записана в виде ассемблерной вставки, мы по прежнему будем говорить о применимости принципа Деметры?

C>Ну да, мой пример — прямой аналог A * B * C.
C>Так что если оно нарушает этот принцип, то и SQL-запрос его будет нарушать.
Я думаю, самое время тебе перечитать определение принципа Деметры и попытаться понять разницу в применениях, и соотношение этого принципа с границами инкапсуляции.

S>>Это иллюзия.
C>Где?
Что симметрия теряется.

Здравствуйте, Sinclair, Вы писали:

S>JDOM: "jdom.query("student/parentGroup/prefect", student).execute()".
S>Молодец, правильно мыслишь. Как только ты так сделаешь, ты обойдешь принцип Деметры.
А если я JDOM встрою в язык:

var prefect=student/parentGroup/prefect

?

Где границу проводить-то будем?

S> А если операция будет записана в виде ассемблерной вставки, мы по прежнему будем говорить о применимости принципа Деметры?
Да, этот принцип точно так же применим, и точно так же контр-продуктивен.

C>>Так что если оно нарушает этот принцип, то и SQL-запрос его будет нарушать.
S>Я думаю, самое время тебе перечитать определение принципа Деметры и попытаться понять разницу в применениях, и соотношение этого принципа с границами инкапсуляции.
Вот я и говорю — принцип неприменим нормально ни к чему.

C>>Где?
S>Что симметрия теряется.
Теряется. Мы начинаем объединение с одного конца.

Здравствуйте, mogadanez, Вы писали:

M>Это не так.
Хм.. Ну я вот, будучи практикующим разработчиком, чужой код не враз вкурю, а просто заказчик со стороны... Меня терзают смутные сомненья.

M>скорее DSL, на крайний случай fluent-interface.
Так ведь SQL существенно больше DSL напоминает, чем императивный шарп.

Здравствуйте, ., Вы писали:

.>скажем, на нём невозможно написать неостанавливающийся (т.е. хотя бы тупо зависающий) алгоритм.

Только язык тут не при чем, язык таки, при помощи CTE, рекурсию позволяет. Просто реальные сервера ограничивают рекурсию вглубь вполне конкретным небольшим числом.

Здравствуйте, Aikin, Вы писали:

A>А вообще, Cyberax, не хочешь -- не используй этот закон. Что я к тебе привязался

Так всегда бывает. Я не знаю ни одного программиста, которому, когда укажешь на то, что он багу наплодил или сделал кривой дизайн, не бросился бы доказывать обратное. Вопрос только в степени этого явления. Некоторые (я не Cyberax имею ввиду) упираются рогом до последнего, переходя на демагогию, но свою неправоту не признают.

Здравствуйте, AndrewVK, Вы писали:

AVK>Так всегда бывает.
Я хочу думать, что а не такой // хотя развернув мысль, понял что не от каждого я бы "стерпел" Надо работать над собой

AVK>Я не знаю ни одного программиста, которому, когда укажешь на то, что он багу наплодил или сделал кривой дизайн, не бросился бы доказывать обратное. Вопрос только в степени этого явления. Некоторые (я не Cyberax имею ввиду) упираются рогом до последнего, переходя на демагогию, но свою неправоту не признают.
Я старался, бегал с идеей, ночами не спал, а тут какой-то "хмырь с соседнего совхоза" говорит что я НЕПРАВ




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

СУВ, Aikin

Здравствуйте, AndrewVK, Вы писали:

AVK>Так всегда бывает. Я не знаю ни одного программиста, которому, когда укажешь на то, что он багу наплодил или сделал кривой дизайн, не бросился бы доказывать обратное. Вопрос только в степени этого явления. Некоторые (я не Cyberax имею ввиду) упираются рогом до последнего, переходя на демагогию, но свою неправоту не признают.
Я иногда признаю, что был неправ Но тут я готов спорить (с примерами!) до конца.

Здравствуйте, AndrewVK, Вы писали:

.>>скажем, на нём невозможно написать неостанавливающийся (т.е. хотя бы тупо зависающий) алгоритм.
AVK>Только язык тут не при чем, язык таки, при помощи CTE, рекурсию позволяет.
Я имел в виду классический SQL (выросший из реляционной алгебры), в духе какого-нибудь стандарта типа ANSI SQL-99. А с рекурсивным CTE — да, уже turing complete... Вроде бы, всё ещё не очень уверен ибо как я тут вспомнил, что даже ПРФ не turing-complete, оператора примитивной рекурсии недостаточно, ещё нужен оператор минимизации.

AVK>Просто реальные сервера ограничивают рекурсию вглубь вполне конкретным небольшим числом.
И это именно ограничение языка, а не серверов, ибо в том смысле какой ты имеешь в виду все языки не turing-complete, т.к. мы всегда имеем какие-то ограничения ресуров, хотя бы количество атомов во Вселенной

Здравствуйте, ., Вы писали:

\.>>>скажем, на нём невозможно написать неостанавливающийся (т.е. хотя бы тупо зависающий) алгоритм.
AVK>>Только язык тут не при чем, язык таки, при помощи CTE, рекурсию позволяет.
.>Я имел в виду классический SQL (выросший из реляционной алгебры), в духе какого-нибудь стандарта типа ANSI SQL-99.

Вот как раз в этом стандарте CTE И появились.

Здравствуйте, ., Вы писали:

.>Здравствуйте, AndrewVK, Вы писали:

.>>>скажем, на нём невозможно написать неостанавливающийся (т.е. хотя бы тупо зависающий) алгоритм.
AVK>>Только язык тут не при чем, язык таки, при помощи CTE, рекурсию позволяет.
.>Я имел в виду классический SQL (выросший из реляционной алгебры),
Ну во-первых, классический SQL имеет очень косвенное отношение к реляционной алгебре. Это становится очевидно, если внимательно посмотреть на саму алгебру и попытаться найти общие черты с SQL. SQL построен скорее "по мотивам" реляционной алгебры, в том смысле, что в нем не было специальных навигационных операций (типичных для сетевых и иерархических СУБД руливших в момент его появления).

.> в духе какого-нибудь стандарта типа ANSI SQL-99.
Ага, как раз в нем CTE и были введены. Вообще, тут в форуме термин "ANSI SQL" часто поминают всуе, в то время как живьем этот документ видели, наверное, всего пара человек. Я вот, к примеру, в них не вхожу.

.>даже ПРФ не turing-complete, оператора примитивной рекурсии недостаточно, ещё нужен оператор минимизации.
И оператор подстановки.

Здравствуйте, AndrewVK, Вы писали:

AVK>\.>>>скажем, на нём невозможно написать неостанавливающийся (т.е. хотя бы тупо зависающий) алгоритм.
AVK>>>Только язык тут не при чем, язык таки, при помощи CTE, рекурсию позволяет.
.>>Я имел в виду классический SQL (выросший из реляционной алгебры), в духе какого-нибудь стандарта типа ANSI SQL-99.

AVK>Вот как раз в этом стандарте CTE И появились.
что-то судя по гуглу там оно нерекурсивное.

Здравствуйте, Sinclair, Вы писали:

.>>>>скажем, на нём невозможно написать неостанавливающийся (т.е. хотя бы тупо зависающий) алгоритм.
AVK>>>Только язык тут не при чем, язык таки, при помощи CTE, рекурсию позволяет.
.>>Я имел в виду классический SQL (выросший из реляционной алгебры),
S>Ну во-первых, классический SQL имеет очень косвенное отношение к реляционной алгебре. Это становится очевидно, если внимательно посмотреть на саму алгебру и попытаться найти общие черты с SQL. SQL построен скорее "по мотивам" реляционной алгебры, в том смысле, что в нем не было специальных навигационных операций (типичных для сетевых и иерархических СУБД руливших в момент его появления).
Да вроде один к одному (если рассматривать SELECT) — таблицы-отношения, проекции, джойны.

.>> в духе какого-нибудь стандарта типа ANSI SQL-99.
S>Ага, как раз в нем CTE и были введены. Вообще, тут в форуме термин "ANSI SQL" часто поминают всуе, в то время как живьем этот документ видели, наверное, всего пара человек. Я вот, к примеру, в них не вхожу.
В интуитивном понимании: "пересечение возможностей всех популярных СУБД".

.>>даже ПРФ не turing-complete, оператора примитивной рекурсии недостаточно, ещё нужен оператор минимизации.
S>И оператор подстановки.
Это вроде есть. Как я понимаю — это делают поздапросы.

Здравствуйте, Sinclair, Вы писали:

S>Ну во-первых, классический SQL имеет очень косвенное отношение к реляционной алгебре. Это становится очевидно, если внимательно посмотреть на саму алгебру и попытаться найти общие черты с SQL.
И чего же на экзамене по реляционной алгебре я доказывал реляционную полноту SQL тогда?

Здравствуйте, Cyberax, Вы писали:
C>И чего же на экзамене по реляционной алгебре я доказывал реляционную полноту SQL тогда?
А какое отношение это имеет к вопросу? С этой точки зрения, клиппер тоже вполне себе реляционо полный.
Это же не означает, что он построен на основе реляционной алгебры.

Здравствуйте, ., Вы писали:

.>Да вроде один к одному (если рассматривать SELECT) — таблицы-отношения, проекции, джойны.
А, ну вот начинается. Для начала мы из всего DDL/DML начинаем рассматривать "только селект".
Затем мы увидим, что в реляционной алгебре есть несколько типов джойнов, но практически ни один из них не соответствует напрямую типам джойнов в SQL.
Оказывается, что большинству операторов РА в SQL нет прямых аналогов. А операторы, знакомые нам по SQL, в РА работают несколько по другому.

Или, нвпример, с точки зрения РА почти ничего из того, что получается в результате применения операторов SQL к таблицам, отношением не является.
Странно для языка, выросшего из реляционной алгебры, не так ли?

.>В интуитивном понимании: "пересечение возможностей всех популярных СУБД".
Это очень странное понимание. Во-первых, оно весьма аморфно (что такое популярные СУБД?), во-вторых, очевидно, что пересечение возможностей будет таки заведомо крайне убогим.

S>>И оператор подстановки.
.>Это вроде есть. Как я понимаю — это делают поздапросы.
Типа того.

Здравствуйте, Sinclair, Вы писали:

C>>И чего же на экзамене по реляционной алгебре я доказывал реляционную полноту SQL тогда?
S>А какое отношение это имеет к вопросу? С этой точки зрения, клиппер тоже вполне себе реляционо полный.
S>Это же не означает, что он построен на основе реляционной алгебры.
Ну давай смотреть. В Вики перечислены следующие свойства реляционной алгебры:
1) Проекция, выборка, фильтрование, переименование — всё есть в прямом виде.
2) Объединения: натуральный джойн, тэта-джойн, outer left/right, inner join — всё тоже есть.

В итоге, SQL прекрасно представляет реляционную алгебру.

Здравствуйте, Sinclair, Вы писали:

.>>Да вроде один к одному (если рассматривать SELECT) — таблицы-отношения, проекции, джойны.
S>А, ну вот начинается. Для начала мы из всего DDL/DML начинаем рассматривать "только селект".
И правильно, остальное чисто инженерная нашлёпка для удобства использования, не несущая теоретического смысла.

S>Затем мы увидим, что в реляционной алгебре есть несколько типов джойнов, но практически ни один из них не соответствует напрямую типам джойнов в SQL.
S>Оказывается, что большинству операторов РА в SQL нет прямых аналогов. А операторы, знакомые нам по SQL, в РА работают несколько по другому.
А подробнее? Что не так? Всё вроде есть, даже агрегатные ф-ции.

S>Или, нвпример, с точки зрения РА почти ничего из того, что получается в результате применения операторов SQL к таблицам, отношением не является.
Эээ... почему не является?

.>>В интуитивном понимании: "пересечение возможностей всех популярных СУБД".
S>Это очень странное понимание. Во-первых, оно весьма аморфно (что такое популярные СУБД?), во-вторых, очевидно, что пересечение возможностей будет таки заведомо крайне убогим.
На то и интуитивное.