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

[perasperaadastra]

Ну, КОБОЛ-то есть еще. Кажется, АРАРАТ писал, что работает с legacy кодом на нем. Да и фортран, я слышал, в некоторых лабораториях еще используется...

[oleg lebedev]

SQL вне конкуренции

для задач, под которые он создан, он вполне приличен. Но ГУЙ на нем проблематично писать.

Да нет, для задач, которых он предназначен, он кусок говна

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

[rgx]

powershell

[Dmitry67]

powershell

+1
Он мощный, но тот кто его делал был обделен эстетическим чувством

[OtherSide]

SQL вне конкуренции

для задач, под которые он создан, он вполне приличен. Но ГУЙ на нем проблематично писать.

Да нет, для задач, которых он предназначен, он кусок говна

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

Еще ближе к правде - вы теорию БД никогда не учили, и как лучше делать не знаете, от того вам и говно как карамелька.

[ALV00]

Еще ближе к правде - вы теорию БД никогда не учили, и как лучше делать не знаете, от того вам и говно как карамелька.

Какие есть лучшие языки для работы с базами данных?

[M. Ridcully]

Вот меня наезды на SQL как-то даже озадачивают...
Ещё один аспект, кстати - SQL это пока самый успешный язык с поддержкой параллелизма. Большинство пользователей даже не задумываются об этом.
Попробуйте сравнить с pthreads, Open CL и т.д. с точки зрения порога вхождения.

[mikeG]

Язык, на котором .bat файлы пишут (у него и названия-то нет)

Под линуксом shell script называется.

Я думаю mikeG пишет о языке командных файлов для MS-DOS. Типа autoexec.bat , если кто помнит.

Да, о нем

Code: Select all

for /f "tokens=1,* delims= " %%a in ("%*") do set params=%%b

[perasperaadastra]

Ох. Можно я поменяю свой вариант? VBA по сравнению с ЭТИМ выглядит даже элегантно...

[OtherSide]

Вот меня наезды на SQL как-то даже озадачивают...
Ещё один аспект, кстати - SQL это пока самый успешный язык с поддержкой параллелизма. Большинство пользователей даже не задумываются об этом.
Попробуйте сравнить с pthreads, Open CL и т.д. с точки зрения порога вхождения.

Теория БД связана с рельяционной алгеброй, но в самом SQL рел. алгебра никак не фигурирует.
Код на нем трудно читать и поддерживать, сложно отлаживать и искать баги.
нет никаких инструментов для модульного подхода. нельзя запрос разбить на части и по частям отладить. нет пространств имен, нельзя передать таблицу как аргуемент, при написании запроса нельзя сразу задать его план ну и т.д.
плюс ко всем нестандартизирован, все субд кто во что гаразд

[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. ты просто индус.

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