Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5 6 7   вперед  Ctrl      все
 Re: SQL - полнота по тьюрингу  [new]
Пилотажный
Member

Откуда: NGC 6137
Сообщений: 2771
Nitro_Junkie

Кстати чисто из любопытства : какие вы декларативные функциональные и логические языки знаете? особенно прикладные в бизнес-решениях? на самом деле интересно... тока не говорите что Haskell и :) ...

В смысле "знаю" - что-то программировал, так конечно? И бизнес-решения - что сам или коллективы, где работал, использовали?

Прологи, а также привлекался к программированию на Рефале для одного проекта.

И когда нужно быстрее что-то приличное лабать - как-то сразу не до этих языков.

Вообще в бизнес-решениях по наблюдениям - не густо функц. и лог.
11 дек 09, 14:41    [8053815]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1090
Пилотажный,

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

Под революционным я имел ввиду, не то что завтра перевернет мир и все такое (это покажет время)... А то что не как во всех современных фреймворках (а таких тысячи) ООП, SQL, UI принимаются за аксиому, и идет надстройка как бы их так связать вместе... а предлагается другой принцип (язык если хотите) построения бизнес-решений, в общем-то самодостаточный, и как предполагается универсальный. В нем нету различия на поля и функции (поля частный случай), которые объединены в свойства, все они множественные, формализованы группировки, наследование поддерживается по принципу defgeneric в CLISP, формализованы формы в контексте объектов\свойств и т.п.

В принципе некоторые частичные решения где-то иногда проскакивают (концепция свойств, правда одиночных и в очень странном виде есть в C#,Delphi и т.д., множественная диспетчеризация похожа на функциональные языки и т.п.), некоторых принципиально нигде не видел, но важно что в ней идет все вместе в единой монолитной конструкции...

Про драйвер, да я видел, тоже смешно... Но если задуматься то даже крупные игроки иногда предлагают технологии основная суть которых, решить какую-то небольщую проблемку что нужно нажать не 5 а 3 кнопки, или как с LINQ (немного утрировано конечно) что можно прямо в родном синтаксисе select написать ( а не в кавычках и вызвать метод ) и это преподносится как откровение... И почему то над ними никто не смеется :)
11 дек 09, 15:03    [8054125]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1090
SergUser,

А что вас про UI смущает, если вы получаете высоко-декларативную логику, то естественно "легко" формализовать (и даже автоматически выстроить) ее представление пользователю..
11 дек 09, 15:05    [8054154]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1090
_мод,

Не понял вашу мысль... Да АДА вообщем-то обычный императивный, даже не функциональный, язык, в этом смылсе PL\SQL чем принципиально лучше, обычной связки Java\C# + SQL-92 (99)... То что альтернатив SQL в плане декларативных языков нет мы в курсе... И у него кстати масса недостатков, одного факта того, что он не с объектами и свойствами работает а таблицами и строками уже достаточно, что его нельзя самого по себе использовать в разработке бизнес-приложений... Но разве это как раз не повод "развить" его и сделать полностью декларативную среду разработки ;-)
11 дек 09, 15:12    [8054258]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
Пилотажный
Member

Откуда: NGC 6137
Сообщений: 2771
Nitro_Junkie

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

Когда был ближе к науке, то интересовался всяким новым - вот наверно всегда выкатить несколько десятков названий.
Но когда всё задает практика, то и интересуешься практически ценным.
Вот понемного Erlang раскуриваю - вот
есть практически ценное и при этом своеобразное.

Nitro_Junkie

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


РЕВОЛЮЦИОННОСТЬ - всё же это когда много народу в чем-то мучалось и страдало - и тут опа - революция и счастье всем в этом. Вот, например, появление SQL - революция.
А какое счастье, в чем и каким мученникам предполагает дать Ваше создание? Картинка с другого сайта.


Nitro_Junkie

крупные игроки иногда предлагают технологии основная суть которых, решить какую-то небольщую проблемку что нужно нажать не 5 а 3 кнопки,


Тут интерфейс хотел заменить у одного внедренного уже модуля (такой как для детей типа "дави пипку" на серьезный такой, похожий на всякий другой в программах от софтгигантов) - так операторы возмутились.
Вот что народу надо - "дави пипку", "нажми на кнопку - получишь результат и твоя мечта осуществится".
11 дек 09, 15:49    [8054714]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1090
Пилотажный,

Проблема программистов в том что при создании технологий они не умеют подходить системно к решению проблем... Обычно увидят какое-то неудобство, и раз вот уже фреймворк\библиотека\технология, кто-то увидит еще и раз такая же хрень сверху... Итого получается какое-нить J2EE, в котором чтобы написать Hello World нужно 7 лет образования, 5 лет опыта и 2 часа работы.
А проблема математиков, что они не программисты... Их всегда уносит в теорию... Так появляются Haskell'ы, Erlang'и и иже с ними

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

Я не говорю, что это абсолютно бесполезно уменьшать количество кнопок. Речь шла о позиционировании этих "серьезных" нововведений... Похоже на тот самый новый драйвер с какими-то "мелкими" фишками...
11 дек 09, 16:16    [8055007]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1090
А что касается мучеников... То у нас сейчас типовые настройки делают бизнес-аналитики... без программистов... то есть вообще без программистов... Конечно если возникнет вопрос с подключением симплекс-методов и иже с ними там надо будет использовать точки входа и подключать программистов, но например в управлении торговлей, расчетами, CRM и т.п. таких вопросов не возникает... А в конечном итоге, предполагается что формы будут создавать сами пользователи, а особо продвинутые пользователи и бизнес-логику (конечно не тети Маши :) )
11 дек 09, 16:53    [8055392]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
Alex_new1
Guest
Nitro_Junkie,

На счет Осло зря вы так отмахиваетесь , вот пожалуйста что пишут в МСе

If Microsoft is able to achieve this vision and its goals—taking into account the required huge support and integration among all of the technical runtimes and “Oslo” (the “Oslo” product team really has to get support from many different Microsoft product teams)—it could really be the start of a revolution in the applications-development field. It will be like changing from assembler and native code bits to high-level programming languages—even better, because, as Doug says, every person (business user) will be, in a certain way, a programmer, because business-expert users will be creating applications.

http://msdn.microsoft.com/en-us/architecture/aa699436.aspx
11 дек 09, 19:58    [8056551]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

Nitro_Junkie wrote:
> парадигмы программирования). И общая идея нужно обоснование того, что
> любую задачу можно решить при помощи ее (естественно есть точки входа
> для императивных языков, но цель максимально минимизировать их
> учавствие, вплоть до нуля).

Если идея в том, чтобы любую задачу написать на SQL -- то идея дурацкая
безотносительно полноты SQL.

Posted via ActualForum NNTP Server 1.4

11 дек 09, 22:12    [8057041]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
web_fox
Member

Откуда: Киев
Сообщений: 444
Nitro_Junkie
_мод,

То что альтернатив SQL в плане декларативных языков нет мы в курсе... И у него кстати масса недостатков, одного факта того, что он не с объектами и свойствами работает а таблицами и строками уже достаточно, что его нельзя самого по себе использовать в разработке бизнес-приложений...


Хм, а я таблицы рассматриваю как раз как массивы объектов, а поля как свойства. Именно поэтому не позволяю программистам именовать таблицы во множественном числе, потому что плохо читается SELECT Apples.colour FROM. Да, у таких объектов нет методов. Но, в Оракле, например, можно создавать таблицы объектов с методами (хотя работать с этим всем практически невозможно, т.к. сейчас у них слишком много ограничений), а в Постгрессе схемы можно расматривать как объекты с методами (а в следующей версии у этих "объектов" даже появятся свойства). Кстати, очевидно ваше сравнение объекты-свойства и таблицы-строки не коректно.

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

А вот это святая правда, дающая твердейшую почву для ваших начинаний.

Nitro_Junkie
типовые настройки делают бизнес-аналитики... без программистов... то есть вообще без программистов... Конечно если возникнет вопрос с подключением симплекс-методов и иже с ними там надо будет использовать точки входа и подключать программистов, но например в управлении торговлей, расчетами, CRM и т.п. таких вопросов не возникает... А в конечном итоге, предполагается что формы будут создавать сами пользователи, а особо продвинутые пользователи и бизнес-логику

Интересную задачу вы берёте. В принципе, это как упростить в компании пирамиду, убрать, так сказать, лишние слои абстракции и подчинить всех рабочих сразу генеральному директору. Хотя, мнение, что отношение Java\C# + SQL далекто от оптимального у меня сомнений не вызывает, улучшать есть что, и даже в революционном смысле.

автор
It will be like changing from assembler and native code bits to high-level programming languages—even better, because, as Doug says, every person (business user) will be, in a certain way, a programmer, because business-expert users will be creating applications

Если честно, - пустые слова, чистый маркетинг. Совершенно очевидно, что бизнес-пользователь, даже на просто SQL ничего серьёзного не напишет, - придётся стать программистом. Куда усложнять то? Да чего уж там душой кривить, даже бизнес-процес в IDEF0 будет сидеть и долго разглядывать... Возможным подходом может стать визард, но уж очень продвинутый, страшно представить насколько :) Потому что у пользователей не так хорошо получается придумывать решения, но сравнительно хорошо получается описывать проблемы - между этими двумя шагами великая работа.
11 дек 09, 22:49    [8057297]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
Пилотажный
Member

Откуда: NGC 6137
Сообщений: 2771
Nitro_Junkie

Обычно увидят какое-то неудобство, и раз вот уже фреймворк\библиотека\технология, кто-то увидит еще и раз такая же хрень сверху... Итого получается какоенить J2EE, в котором чтобы написать Hello World нужно 7 лет образования, 5 лет опыта и 2 часа работы.


Программисты делают инструмент для программистов же - и само собой ничего лишнего, компактней, четче, короче, ...
Так и в любой сфере деятельности - кому-то непрофи в этом просто дать весь инструмент - так и тоже как применять - и если сам по себе годы может вникать. Ускоряют процесс - специальные учебные курсы.

Nitro_Junkie

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


Так какая же это проблема программистов?
Это просто разделение труда - когда один человек,
то он же постановщик задачи, и программист, и IT-математик-алгоритмист, и сам себе
IT-менеджер (сам себе режиссер), и системный архитектор, и конфигуратор, ...
К разделение труда во всем достаточно сложном в цивилизованном обществе.
Вообще любой из любой роли может сделать всё из перечисленного, но у кого-то что-то получается лучше - вот и позиционирование. Это всё же не надуманное что-то, а естественно образовавшееся - на всё не хватит ни сил, ни времени, а также для коллективов ценнее глубоко-понимающие и знающие специализирванные, чем поверхостные квазиуниверсальные. Из квазиуниверсальных - достаточно начальников с замами. (Одиночки-герои не рассматриваются.)

Nitro_Junkie

в теорию... Так появляются Haskell'ы, Erlang'и


Erlang, Haskell, ... - это уже прикладные issue общих теории, из которых же C, Paskal, Java, ...
И это видится - как вот есть Европа и Северная Америка (Java, Delphi, C++, C#, ...) - вроде все везде задают, но есть и Азия, Африка, Южная Америка - и там могут жить без Сев. Америки и Европы, и есть такое, чего нет и не может быть в Сев.Америке и Европе, и это великолепно,
и ... когда-то и эти регионы моугт выйти на такой уровень, что будут задавать почти всё в Мире.


К Microsoft Oslo и Rosario - что-то темнили-мудрили и потом заявили, что в основе - UML. (Смех в зале). И где эти сверхязыки суперинжениринга - TLA+ и ...?
12 дек 09, 10:53    [8058089]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
Ggg_old
Member

Откуда: Одесса
Сообщений: 1342
пытаюсь вот поизучать OCAML. Но функциональный код, даже на окамле читается крайне тяжело, что-бы понять алгоритм, надо превратить мозг в интерпретатор рекурсивных вражений, что мозгу вообще не свойственно по природе. А если использовать чисто императивные возможности, то не видно особых преимуществ перед существующими языками.
Я в сове время очень долго не принимал преимуществ ООП. Вернее понимал, что инкапсуляция - это хорошо, а вот ооп-проектирование не понимал по-настоящему. Понимание идеалогии пришло только после прочтения книги GoF. C функциональным программированием сейчас такая-же проблема, технологию можно изучить, а вот методологи как ее использовать пока не нашел.
13 дек 09, 22:12    [8060742]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1090
Alex_new1,

Достаточно просто почитать описание Oslo, и увидеть что они предлагают... ;-)

MasterZiv,

Безотносительно нашего проекта, можно узнать почему? Я понимаю что у любого расширения должны быть императивные черты, чтобы реагировать на события, но если их формализовать в виде например ввода свойства или изменения класса объекта, а все остальное рассматривать как следствие декларативных правил, то почему нет. Кроме того я понимаю что есть явные баги SQL Server'ов, когда очевидно что надо использовать index seek, а не scan с проверкой, но их можно пообходить hint'ами, тем более что основные функции оптимизации заключаются в основном в выборе join'ов, и обработки вложенных подзапросов, все остальное не дает экспоненциального роста производительности...
14 дек 09, 10:43    [8061910]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1090
web_fox
Хм, а я таблицы рассматриваю как раз как массивы объектов, а поля как свойства. Именно поэтому не позволяю программистам именовать таблицы во множественном числе, потому что плохо читается SELECT Apples.colour FROM. Да, у таких объектов нет методов. Но, в Оракле, например, можно создавать таблицы объектов с методами (хотя работать с этим всем практически невозможно, т.к. сейчас у них слишком много ограничений), а в Постгрессе схемы можно расматривать как объекты с методами (а в следующей версии у этих "объектов" даже появятся свойства). Кстати, очевидно ваше сравнение объекты-свойства и таблицы-строки не коректно.


Если у вас свойство от нескольких объектов, что бывает в большинстве случаев. Например остаток товара на складе, и очевидно что должна быть таблица с ключом склад, товар и свойством остаток количество, вы ее как что рассматриваете?

Вы немного сами себе противоречите, говорите что рассматриваете таблицы как массивы объектов и поля как свойства и при этом что сравнение объекты-свойства и таблицы-строки не коректно.
14 дек 09, 10:52    [8061976]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

Nitro_Junkie wrote:

> Безотносительно нашего проекта, можно узнать почему? Я понимаю что у

0) императивность в языке запросов -- это зло. Я так считаю.
1) может и просто тупо зациклиться.
2) не все СУБД это поддерживают.

В общем, пока очень сильно не припрёт, я лучше сам дерево
разошью и буду обычные запросы писать. Результата транзитивного
замыкания дерева для 80% работы с деревом должно хватать.
А писать поиск в глубину на SQL -- это маразм.

Posted via ActualForum NNTP Server 1.4

14 дек 09, 11:04    [8062057]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1090
Пилотажный,

Мы немного о разных вещах говорим, я имел ввиду скорее кто инициирует процесс создании технологий. Понятно что дальше в самом процессе создания учавствуют и директора, и менеджеры и уборщицы и т.п. Но идеологов на мой взгляд можно условно разделить на 2 категории.
14 дек 09, 11:17    [8062177]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1090
MasterZiv,

0) а в языке запросов и нету императивности, вы наверное имели ввиду рекурсивность
1) они и в императивном языке могут зациклиться
2) вообще они вошли в стандарт SQL:1999, который поддерживают очень многие SQL сервера (Postgre, MSSQL, Oracle и т.п.)

Хотя не спорю, что поддержка рекурсивных запросов в SQL далека от совершенства ... Другой вопрос, насколько часто такие проблемы возникают в бизнес-решениях, насколько они сложны, и насколько их нельзя решить "фиксацией" текущих параметров при проведении транзакции(то есть важна целостность во времени, если не понятно могу пояснить что имеется ввиду).... Если отбросить задачи производства то доля такого функционала очень небольшая (да и в производстве не сильно больше)... Поэтому чисто из-за этого ставить крест на чисто декларативных подходах, это все равно что лечить головную боль ампутацией головы.
14 дек 09, 11:26    [8062247]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
Пилотажный
Member

Откуда: NGC 6137
Сообщений: 2771
Ggg_old
пытаюсь вот поизучать OCAML. Но функциональный код, даже на окамле читается крайне тяжело, что-бы понять алгоритм, надо превратить мозг в интерпретатор рекурсивных вражений, что мозгу вообще не свойственно по природе. А если использовать чисто императивные возможности, то не видно особых преимуществ перед существующими языками.
Я в сове время очень долго не принимал преимуществ ООП. Вернее понимал, что инкапсуляция - это хорошо, а вот ооп-проектирование не понимал по-настоящему. Понимание идеалогии пришло только после прочтения книги GoF. C функциональным программированием сейчас такая-же проблема, технологию можно изучить, а вот методологи как ее использовать пока не нашел.


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

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

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

Так и с декларативными языками - эдак зачем-то начать писать и думать иероглифами.


Вот ещё революционное "программирование без программистов", из советских времен ещё идущее и пытающееся заявиться широко
"Буран" и язык программирования ДРАКОН
(там и URL на общие описания)
14 дек 09, 14:39    [8063696]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
_мод
Guest
Nitro_Junkie
сделать полностью декларативную среду разработки

Можно, но не нужно. Чаще всего цикл лучше рекурсии.
Nitro_Junkie
SQL не с объектами и свойствами работает а таблицами и строками уже достаточно, что его нельзя самого по себе использовать в разработке бизнес-приложений

Ровно наоборот: SQL это рел. алгебра и ее мы и используем при разработки. Объектной алгебры увы не существует.
Операция SQL имет вид: таблица3=таблица1 операция таблица2 ...
Ни один язык не позволяет делать: объект3=объект1 операция объект2
14 дек 09, 14:44    [8063746]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1090
_мод,

а что по вашему в структурном программировании (и ООП) вызов функции как не реляционная алгебра? то есть например:

имя склада = имя(склад(документ))

документ JOIN склад ON склад.id=докуметн.склад
14 дек 09, 15:05    [8063927]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1090
Пилотажный,

ООП добавил очень важный аспект программирования как наследование, только при этом почему-то потребовал присваивать функцию одному объекту и обзывать это дело методом. Как следствие получил массу гемора в виде : неоднозначного определение класса для метода, невозможность множественного полиморфизма, проблемы с модульностью и т.п. В функциональных же языках такой привязки нету (собсно их это как правило и отличает), а наследование они поддерживают как возможность "объединение" функций в одну. Правда кроме Common Lisp'а таких языков я честно гря не припомню. Но они очень недружелюбны что в плане синтаксиса, что в плане поддержки, а жаль :( , впрочем с другой стороны может и хорошо что развитие программирования застряло в "тупиковой" в этом смысле ветке ООП, и порой забавно наблюдать как его пытаются скрестить с SQL, не понимая что это невозможно :)
Хотя справедливости ради, даже в Common Lisp'е не догадались сделать поля множественными и сделать их частным случаем функций, так что он тоже не особо был бы панацеей.
14 дек 09, 15:25    [8064071]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1090
_мод,

Да... и к вам тот же вопрос, часто вы сталкиваетесь с задачами рекурсии (кроме классификации) при разработке бизнес-приложений?
14 дек 09, 15:26    [8064087]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

Nitro_Junkie wrote:

> 1) они и в императивном языке могут зациклиться

Запрос на SQL может зациклится ? Не, это уже слишком.
Не может.

Posted via ActualForum NNTP Server 1.4

14 дек 09, 15:31    [8064121]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1090
MasterZiv,

An incorrectly composed recursive CTE may cause an infinite loop. For example, if the recursive member query definition returns the same values for both the parent and child columns, an infinite loop is created. To prevent an infinite loop, you can limit the number of recursion levels allowed for a particular statement by using the MAXRECURSION hint and a value between 0 and 32,767 in the OPTION clause of the INSERT, UPDATE, MERGE, DELETE, or SELECT statement. This lets you control the execution of the statement until you resolve the code problem that is creating the loop. The server-wide default is 100. When 0 is specified, no limit is applied. Only one MAXRECURSION value can be specified per statement. For more information, see Query Hints (Transact-SQL).

Вполне может, просто по умолчанию стоит ограничение 100 и это не считается исключением... В конце концов в императивном языке тоже можно поставить через аспект ограничение в глубину 100 и возвращать null когда он достигается. То есть и в SQL и в языках "в чистую" рекурсивный цикл не обнаруживается... Так что не велика разница
14 дек 09, 15:40    [8064198]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

Nitro_Junkie wrote:
> Автор: Nitro_Junkie <https://www.sql.ru/forum/memberinfo.aspx?mid=135879>
> MasterZiv,
>
> An incorrectly composed recursive CTE may cause an infinite loop. For

Я просто прочитал это

"1) они и в императивном языке могут зациклиться"

как

"1) они и в декларативном языке могут зациклиться"

Извини.

ПРоцитированное понятно.

Posted via ActualForum NNTP Server 1.4

14 дек 09, 16:15    [8064553]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5 6 7   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить