Нелюбимый язык?

[DDoS]

Вот меня наезды на SQL как-то даже озадачивают...
Ещё один аспект, кстати - SQL это пока самый успешный язык с поддержкой параллелизма.

Меня тоже озадачивают наезды на SQL. Вполне нормальный язык для своих задач. А если у кого-то 5 таблиц с одинаковой структурой в базе и ему позарез надо динамически передать параметр имя таблицы - так это не в SQL, это в структуре базы проблема.

Но еще больше озадачивает "поддержка параллелизма" и сравнение с pthreads...
Мне всегда казалось, что в SQL нет абсолютно никакой поддержки параллелизма. Нет конструкций вроде
insert into tbl ... values ... ASYNC
или
select AWAIT n from (select max(id) as n from tbl ASYNC)

Или я отстал давно?

[M. Ridcully]

Но еще больше озадачивает "поддержка параллелизма" и сравнение с pthreads...
Мне всегда казалось, что в SQL нет абсолютно никакой поддержки параллелизма. Нет конструкций вроде
insert into tbl ... values ... ASYNC
или
select AWAIT n from (select max(id) as n from tbl ASYNC)

Или я отстал давно?

Имелось в виду, делая обычный select вы скорее всего запускаете параллельно задачи, даже не подозревая об этом.
То есть SQL, помимо всего прочего, чистый success story параллельного программирования, если измерять с точки зрения удобства использования.

[DDoS]

Но еще больше озадачивает "поддержка параллелизма" и сравнение с pthreads...
Мне всегда казалось, что в SQL нет абсолютно никакой поддержки параллелизма. Нет конструкций вроде
insert into tbl ... values ... ASYNC
или
select AWAIT n from (select max(id) as n from tbl ASYNC)

Или я отстал давно?

Имелось в виду, делая обычный select вы скорее всего запускаете параллельно задачи, даже не подозревая об этом.
То есть SQL, помимо всего прочего, чистый success story параллельного программирования, если измерять с точки зрения удобство использования.

В этом случае success story будет удачная имплементация SQL-сервера. В каком-нибудь Firebird Embedded старых версий (<2.5) никаких параллельных задач не было.

[M. Ridcully]

Но еще больше озадачивает "поддержка параллелизма" и сравнение с pthreads...
Мне всегда казалось, что в SQL нет абсолютно никакой поддержки параллелизма. Нет конструкций вроде
insert into tbl ... values ... ASYNC
или
select AWAIT n from (select max(id) as n from tbl ASYNC)

Или я отстал давно?

Имелось в виду, делая обычный select вы скорее всего запускаете параллельно задачи, даже не подозревая об этом.
То есть SQL, помимо всего прочего, чистый success story параллельного программирования, если измерять с точки зрения удобство использования.

В этом случае success story будет удачная имплементация SQL-сервера. В каком-нибудь Firebird Embedded старых версий (<2.5) никаких параллельных задач не было.

Имплементация тоже важна, да.
Но это успех и языка тоже - он на таком уровне абстракции, чтобы позволять параллелизацию на уровне имплементации с одной стороны, и при этом "параллельные программы" на нём может писать бухгалтер.
А будь в нём кое-какие фичи которые тут OtherSide хочет - явно заданный план там, и т.д. - как знать, быть может это сделало бы его менее доступным для пользователя и при этом связало руки тем, кто его имплементирует.

[Dmitry67]

У SQL много проблем
Но представьте каков его возраст при требовании совместимости!!!

[OtherSide]

https://ru.wikipedia.org/wiki/%D0%A0%D0 ... 0.B8.D0.B5" onclick="window.open(this.href);return false;

Вот пожалуйста. Почем не реализованы операции Intersect и Divide?
Почему нельзя запрос разбивать на подзапросы для большего удобства отладки

План построения запроса часто непредсказуемый, для меня например было сюрпризом, что between и два < и > работают по-разном (between использует индекс!)

В Ms sql передавать таблицу как аргуемнт нельзя

[iDesperado]

OtherSide, вы бы про SQL чего нибудь почитали, начните с этого
http://courses.cs.vt.edu/~cs4604/Fall09 ... lgebra.pdf" onclick="window.open(this.href);return false;

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

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

[OtherSide]

OtherSide, вы бы про SQL чего нибудь почитали, начните с этого
http://courses.cs.vt.edu/~cs4604/Fall09 ... lgebra.pdf" onclick="window.open(this.href);return false;

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

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

Ну да типа декларативный, но на деле декларативность исполнена через жопу и реально ее нет, один и тот же результат можно получить разными запросами, с разной эффективностью.
Зачем нужна такая декларативность, когда не уверен что будет отдан ожидаемый результат?

По передаче таблиц я уже писал. У меня задача - есть десяток хранимок и 4 таблицы с идентичной структурой, каждые по миллиард записей. Почему я не могу повторно использовать код, а приходится делать копипаст. Можно конечно объединить в одну и добавить поле и индекс, но ведь это забирает место на диске и замедляет время выполнения запроса.

[iDesperado]

Ну да типа декларативный, но на деле декларативность исполнена через жопу и реально ее нет, один и тот же результат можно получить разными запросами, с разной эффективностью.
Зачем нужна такая декларативность, когда не уверен что будет отдан ожидаемый результат?

что бы оптимизатор перестраивал автоматом план по мере роста данных, а не как в бигдата/MapReduce ставил перед тупыми дилемами дурачка-индуса при банальном джоине пары датасетов. когда индус зашивает способ на века и естественно никогда не угадывает оптимальный вариант.

По передаче таблиц я уже писал. У меня задача - есть десяток хранимок и 4 таблицы с идентичной структурой, каждые по миллиард записей. Почему я не могу повторно использовать код, а приходится делать копипаст. Можно конечно объединить в одну и добавить поле и индекс, но ведь это забирает место на диске и замедляет время выполнения запроса.

индусы в родственниках есть ? там миллион вариантов, начиная с view поверх 4 таблиц, заканчивая динамическим SQL и создания синонима на ходу.
вы явно занимаетесь не своим делом.

[OtherSide]

индусы в родственниках есть ? там миллион вариантов, начиная с view поверх 4 таблиц, заканчивая динамическим SQL и создания синонима на ходу.
вы явно занимаетесь не своим делом.

А у вас кто в родственниках? Таджики или может чукчи? Которые писатель, не читатель?
Я что, писал, что нет способов? Я писал о говно-языке, которые раздражает и который можно было сделать гораздо изящнее.
Если бы вы немного умели думать, то поняли бы что пляска через view
а) кривая по сути
б) с непредсказуемым планом выполнения, скорее всего неоптимальным

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

[iDesperado]

А у вас кто в родственниках? Таджики или может чукчи? Которые писатель, не читатель?

те кто вот таким индусам руки отрывает

Почему я не могу повторно использовать код, а приходится делать копипаст.

чувак, ты классический индус, тебя с такими знаниями к субд нельзя подпускать

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

что бы получить читаемый код, а не еще один perl

[OtherSide]

А у вас кто в родственниках? Таджики или может чукчи? Которые писатель, не читатель?

те кто вот таким индусам руки отрывает

Почему я не могу повторно использовать код, а приходится делать копипаст.

чувак, ты классический индус, тебя с такими знаниями к субд нельзя подпускать

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

что бы получить читаемый код, а не еще один perl

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

[OtherSide]

Вот это, что у нас, "не перл"?

where a = 1 and b = 2 and c between 3 and 4

По изяществу синтаксиса легко может конкурировать с регэкспами

[iDesperado]

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

просто я привык за такое "Почему я не могу повторно использовать код, а приходится делать копипаст. " натягивать индусам опу на глаз.
чувак, займись балетом, тебе просто противопоказано писать код. ты не нашел в SQL union, не слышал про schema. ты просто индус.

[OtherSide]

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

просто я привык за такое "Почему я не могу повторно использовать код, а приходится делать копипаст. " натягивать индусам опу на глаз.
чувак, займись балетом, тебе просто противопоказано писать код. ты не нашел в SQL union, не слышал про schema. ты просто индус.

А ты чем занимался, олеводством? Если для тебя ОК объединять через вьюху несколько табличек в сотни гигабайт?