Абстрактное о ЯП для СУБД

>Благодарю.

не за что, обращайся

>почему именно Haskell?

потому что Phooey на нем ;)

>ну это всё от неправильного подхода к обучению :)

или к понятию "удобный интерфейс". /me проникся идей tuomov'а (это не отменяет его "умности" относительно шревтов и ксинерамы) о том что approachability != usability. на самом деле крысу нужно зарезать и отправить назад в ксерокс. только клавиатура (лебедевская клава - один из шагов), экран и окна.

> А я встречался много раз. Как-то справляются.

Ну не знаю, может мы говорим о немного разных приложениях.. Лет десять назад я на pl/sql писал много чего, вплоть до веб-серверов, но это были относительно простые и не нагруженные приложения для внутреннего пользования. Если речь идёт о чём-то более серьёзном, я бы голосовал за использование сервера приложений под логику.

> И походу платят охрененное бабло Ораклу за поддержку.

Корпоративщики в любом случае платят ораклу за поддержку, если на нём сидят. Только вот, придут-то в конечном итоге всё равно к разработчику если дело касается его софта.

> Внедрение ОО в массы, всякого рода динамика на уровне языка. Да, придумали их давно - но широко в продакшне эти вещи используют относительно недавно. И где это все в SQL?

Слишком умная субд не нужна, итак тормоз. Если туда внести еще какие-либо сущности, будет еще сложнее.

> wm title . {OOP Sucks}

Ну и что? tcl/tk тоже ООП-нутый, только это не сразу видно:

> set f [frame .f -relief flat -background BLACK]

создаем объект класса frame

> place $f -in .

вызываем метод place для объекта .f

(Не зря же tcl/tk так легко интегрируется в питон.)

Смотри Erlang - там интересно
SQL он везде такой - БД

>Не представляю хотя бы маленькое GUI-приложение без ООП

а оно как раз отлично делается без ООП-овских костылей

>как объекты реального мира без ООП то описывать будешь

ФП

> без ООП-овских костылей

> ФП

Ох уж мне эти дети...

Я так вижу, что товарищ svu уже и SQL собирается хоронить, потому что он давно не обновлялся? :)

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

P.S. Все расширения, что мне были нужны от sql-я реализовывались препроцессором к нему.

> Ну и что? tcl/tk тоже ООП-нутый, только это не сразу видно:

Бгг, где ты в tk увидел наследование? А инкапсуляцию? Полиморфизм есть, это да, но двух других слонов ооп не видно.

Есть, например, KDB http://kx.com/q/d/primer.htm

точнее, лучше отсюда http://kx.com/q/d/kdb+.htm

Ещё есть функциональный Links / SLinks вроде окамла, который на деле транслируется в обычный SQL. То есть, приложения пишутся на функциональщине, а какой там SQL получится -- это транслятор нагенерирует.

> Внедрение ОО в массы, всякого рода динамика на уровне языка. Да, придумали их давно - но широко в продакшне эти вещи используют относительно недавно. И где это все в SQL?

а где в SQL динамика? нет там её. Если хочется чего-то более динамичного, придётся отказаться от SQL в пользу какой-то ООБД или функциональщины вроде K.

> ЗЫ Видимо, к программистам СУБД это не относится. Судя по всему, это очень консервативная почти-мафия,

да-да, все те же MUMPS'ы кругом и SQL -- это уже верх современной мысли :)))

> Вопрос должен звучать по-другому: "почему существовавшие _языки программирования_ БД тихо сошли со сцены, уступив место _языку запросов_".

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

> ООСУБД всех зохавают. Не случилось.

в своей нише -- вполне себе зохавали.

>> ООСУБД всех зохавают. Не случилось.

> в своей нише -- вполне себе зохавали.

В "своей" - это какой, CAD? А планировалось, что зохавают _всё_, или по крайней мере объем рынка будет сравним с рынком РСУБД.

>> Думаю прежде всего по экономическим соображениям SQL рулит

>Думаю, это зависит от того, как именно считать деньги. С т.зр. эффективности разработки и поддержки я не думаю, что SQL это высший взлет разума.

А что взлет? XML-базы вот обещали, так вообще пук в лужу получился.. сейчас всякие tuple store'ы в моде от амазона/гугла/кого-хошь, но запросы к ним являются строгим и очень-очень небольшим подмножеством sql'я

> В смысле, а что вредного то в ООП?

это смотря какое ООП.

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

не, на автоматном программировании. Автоматы вполне себе заменяют объекты. Нужен rule-based язык описания автоматов, и их автоматическая генерация. Концепция шире ООП.

> Охх, Вы наступаете на мою больную мозоль. Я как жабщик тоже так считаю. Но есть реальный мир. В нем есть всякое. И есть менеджеры и проекты, которые требуют делать ЭТО внутри БД.

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

> Почему встроенные ЯП программирования СУБД фактически замерли в развитии? Все крутятся вокруг SQL-а (которому скоро уж полвека). Ну да, вставляют тот же SQL в дотнет или в жабку, тем или иным способом - но получается какая-то фигня. Почему сам по себе SQL замерз и практически не меняется (в смысле введения новых языковых концепций)?

Потому, что чтобы поулчалась не "какая-то фигня", нужна мощная математическая основа, эффективные алгоритмы и тд.

Сейчас кстати есть последний писк - все параллельные базы кинулись поддержку MapReduce добавлять (кстати никто не видел где-нибудь достаточно технического описания, что именно делают? гуглю-гуглю, один баллшит нахожу)

>задавать о Третьем Манифесте.

о "манифесте Трёх"

>> задавать о Третьем Манифесте.

> о "манифесте Трёх"

Это разные манифесты :)

Когда русские начинают рассуждать о CS при полном отсутствии образования(а у них у всех его нету), становится очень смешно. Сбегал за попкорном.

> SQL имеет под собой тщательно продуманную матчасть,
Я уже сказал - это все про "под собой", про интерфейс с компом и всем что ниже. Мой вопрос про "над" - про интерфейс с программистом.

> А нескончаемые модификации и улучшения --- удел наколенных поделок вроде жабы.
А ничего, что даже языки С и С++ обновляются (вон Строструп даже годится следующее поколение плюсов выдать)? И даже всякие D придумывают и пр. и пр. Есть движуха-то! Мысля работает!

> Все расширения, что мне были нужны от sql-я реализовывались препроцессором к нему.
Пусть даже так, хотя это и криво, ибо препроцессор по определению животное довольно тупое. Где работы над стандартизацией препроцессора, хотя бы в оракле? м4 не предлагать;)

Еще один вопрос - кто-нибудь задавался вопросом про рефакторинг PL/SQL-ного кода? Насколько я представляю, это невозможно автоматизировать, в том смысле как это всякие эклипсы, идеи и нетбинзы делают с жабкой. А то вот я вот помечтал об XP в программировании на PL/SQL;)

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

Он ограничивает минимальный набор абстракций. Но я не вижу, как бы он мешал _добавлять_ новые абстракции.

>> SQL имеет под собой тщательно продуманную матчасть,
> Я уже сказал - это все про "под собой", про интерфейс с компом и всем что ниже. Мой вопрос про "над" - про интерфейс с программистом.
Препроцессором, батенька, препроцессором. Пишешь "select only needed data and make zaebis", прогоняешь через препроцессор и получаешь то, что нужно.

>> А нескончаемые модификации и улучшения --- удел наколенных поделок вроде жабы.
> А ничего, что даже языки С и С++ обновляются (вон Строструп даже годится следующее поколение плюсов выдать)? И даже всякие D придумывают и пр. и пр. Есть движуха-то! Мысля работает!
Предметная область языка общего назначения значительно шире области языка доступа к данным, вот и не придумали ещё языка общего назначения, настолько же хорошего как sql (просьба (молчать 'лисперы ":)")).

>> Все расширения, что мне были нужны от sql-я реализовывались препроцессором к нему.
> Пусть даже так, хотя это и криво, ибо препроцессор по определению животное довольно тупое. Где работы над стандартизацией препроцессора, хотя бы в оракле? м4 не предлагать;)
При чём тут m4? У меня был свой специализированный не тупой препроцессор. Вернее, он и сейчас есть, только я там уже не работаю. Разбирал sql-подобный запрос на языке, содержащем sql как подмножество, и делал из него чистый sql.
Кроме того, не следует забывать и более распространённые препроцессоры, например, тот же hibernate.

> Еще один вопрос - кто-нибудь задавался вопросом про рефакторинг PL/SQL-ного кода?
Не, мы такие грибы не едим %)

> Препроцессором, батенька, препроцессором.
Препроцессору не доступна вся та инфа, которая есть у компилятора-интерпретатора. Поэтому я и сказал "тупой". Что препроцессор знает о типах, например?

> У меня был свой специализированный не тупой препроцессор
Урл? Или секретная разработка КГБ?

> Разбирал sql-подобный запрос на языке, содержащем sql как подмножество, и делал из него чистый sql.
Можно пример кода какого-нибудь, демонстрирующего мощь этого разрекламированного препроцессора?

> Кроме того, не следует забывать и более распространённые препроцессоры, например, тот же hibernate.
Сорри, я кроме жабского хибернейта про других не слыхал. Чо за зверь?

> Не, мы такие грибы не едим %)
Дык таких грибов в лесу и нет! А я их хочу!

>В "своей" - это какой, CAD? А планировалось, что зохавают _всё_, или по крайней мере объем рынка будет сравним с рынком РСУБД.

где иерархические данные с хорошей локальностью данных. И ОО выступает просто как локальный кеш. CAD, база знаний, принятие решений, управление проектами, и т.п.

> И ОО выступает просто как локальный кеш. CAD, база знаний, принятие решений, управление проектами, и т.п.

Ну то есть они так и не выбрались за пределы песочницы, в которой родились. Собственно, я о том же.

>> Не, мы такие грибы не едим %)
>Дык таких грибов в лесу и нет! А я их хочу!

а вы точно с кактусом не путаете? ;)

>> Препроцессором, батенька, препроцессором.
> Препроцессору не доступна вся та инфа, которая есть у компилятора-интерпретатора. Поэтому я и сказал "тупой". Что препроцессор знает о типах, например?
О типах надо знать далеко не везде и не всегда.

>> У меня был свой специализированный не тупой препроцессор
> Урл? Или секретная разработка КГБ?
Нет, попросту проприетарщина.

>> Разбирал sql-подобный запрос на языке, содержащем sql как подмножество, и делал из него чистый sql.
> Можно пример кода какого-нибудь, демонстрирующего мощь этого разрекламированного препроцессора?
Позволял он доступ к колонкам через несколько связанных таблиц (a.sub1.sub2.sub3.column1), разворачивая нужным образом таблицы в from. Делал тем самым нечто из того, что умеет хибернейт, но с тем вкусным свойством, что его можно более тесно смешивать со стандартным sql и иметь вложенные подзапросы.

>> Кроме того, не следует забывать и более распространённые препроцессоры, например, тот же hibernate.
> Сорри, я кроме жабского хибернейта про других не слыхал. Чо за зверь?
А я именно про него.

>> Не, мы такие грибы не едим %)
> Дык таких грибов в лесу и нет! А я их хочу!
Это надо в Голландию переезжать :)

>>Среда исполнения для языка запросов, это движок базы. Он очень сложный и высокоуровневый, т.е. делает ограничения на абстракции языка.

> Он ограничивает минимальный набор абстракций. Но я не вижу, как бы он мешал _добавлять_ новые абстракции.

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

> Еще один вопрос - кто-нибудь задавался вопросом про рефакторинг PL/SQL-ного кода?

ну если абстрактно потеоретизировать, можно оттранслировать в нечто функциональное, выделить какими-то трансформациями отдельно язык запросов, отдельно PL, раскидать по нужным модулям и собрать заново. А функциональщина здесь будет как glue language описания запросов и методов. Но это будет дикий кактус какой-то.

Кактусы - это к Кастанеде.

Ну новая волна которая выбралась, это например K:
http://kx.com/q/d/a/kdb+.htm#Q%20from%20SQL
http://kx.com/q/e/

Это правда не ООБД.

> О типах надо знать далеко не везде и не всегда.
Отмазка слабая. Хочется гибкости работы с типами, препроцессор тут не поможет.

> А я именно про него.
Ээээ разве это препроцессор сиквеля??? Что-то новое.

> Это надо в Голландию переезжать :)
Да их нигде нет! Нету "PL/SQL next gen" в природе!

> ну если абстрактно потеоретизировать,
Дык о том и вопрос - почему всерьез никто не теоретизирует (ну или хочу ссылок на работы, если ошибаюсь)? Может, из абстрактной теории какой-то полезный выхлоп был бы, хоть минимальный. А такое ощущение, что поле просто покрыто мертвыми костями, а вдоль дороги мертвые с косами. И тишина.

> Но это будет дикий кактус какой-то.
Если с наскоку делать - наверное. Но я даже таких работ не видел!

>> О типах надо знать далеко не везде и не всегда.
> Отмазка слабая. Хочется гибкости работы с типами, препроцессор тут не поможет.
Где в sql нужна "гибкость работы с типами"?

>> А я именно про него.
> Ээээ разве это препроцессор сиквеля??? Что-то новое.
А чем он не препроцессор? Переводит что-то, выглядящее как запрос в запрос.

> Да их нигде нет! Нету "PL/SQL next gen" в природе!
Так это ещё и синтетическое _вещество_?

O_o там ещё и GUI есть http://en.wikipedia.org/wiki/KDB_(database)

> Может, из абстрактной теории какой-то полезный выхлоп был бы, хоть минимальный.

ну были работы по ООБД, вывод из которых: целесообразно строить вокруг аспектно-ориентированного программирования и рефлексии язык запросов, схемы кеширования и обновления данных (с учётом наследования, новых версий методов итп).
С другого направления, с функциональщины, делали трансляторы из своего языка в SQL, вроде LINQ/Links, или APL/K/KDB. Общий вывод, что унифицированный язык БД с возможностью описания данных и логики позволяет описывать свойства, зависимости данных и методы процедуры лучше, гибче.
Например, можно транслировать в SQL и вопрос сводится к эффективному транслятору (на функциональщине описываются данные в виде множеств и структуры, а транслятор уже оптимизирует, раскладывает по таблицам, и т.п. вроде hibernate).
Или можно сделать свой язык вроде APL с "первоклассными" функциями и замыканиями. И вычислять их лениво. То есть, не транслировать в жестко заданный SQL а как бы составить оптимальный набор комбинаторов, описывающих данные и логику вместе.

> Где в sql нужна "гибкость работы с типами"?
А чем в этом смысле sql лучше-хуже других языков?

> А чем он не препроцессор? Переводит что-то, выглядящее как запрос в запрос
Ну да, в каком-то смысле...

> Так это ещё и синтетическое _вещество_?
Да нет, это просто хотелка такая! Хочу рефакторинг. Хочу удобства для внесения изменений в код.

про SLinks http://infoscience.epfl.ch/record/84805
хотя эту гирю пилят про LINQ/Links довольно давно

>> Где в sql нужна "гибкость работы с типами"?
> А чем в этом смысле sql лучше-хуже других языков?
Понятно, "хочется чего-то, а зачем --- не знаю" :о)

> Где в sql нужна "гибкость работы с типами"?

Да взять хоть твой же пример. Вот ты писал препроцессор для доступа по путям вроде a.b.c.d, потому что типы в SQL-атомы и наследования/агрегации не понимает. Но когда a.b.c.d превращается в цепочку JOIN'ов, выясняется что нужны индексы по foreign keys. То есть, в препроцессоре возникает "утечка абстракций", нормальную агрегацию эмулируем составными частями. То есть, по идее "препроцессор" должен генерировать не только целевой SQL с JOIN'ами, но и набор индексов. Теперь допустим, что c -- функция, возвращающая объект класса C. а d - его метод => нужны индексы на классы-потомки C и как-то изобразить метод через функциональную зависимость. Набор оптимальных индексов меняется, то есть индексы зависят от типа запроса.
Получается, "препроцессор" -- только половина дела, к нему ещё нужен оптимизатор, хотя бы полуручной (посмотрели план запроса, руками поправили), и как-то разбивать на подсистемы вот ту штуку с ФЗ (или получаем ограничения, из простого исходника, простой SQL).

>Ну и что? tcl/tk тоже ООП-нутый, только это не сразу видно:

это только если очень хотеть там увидеть ООП. которого там, увы, нет

>(Не зря же tcl/tk так легко интегрируется в питон.)

не Tcl/Tk, а Tk. и не только в питон, но и в R, Erlang, Haskell, Perl, etc. и - внезапно - совсем не потому что тем где-то есть ООП

но с рефакторингом что-то круче выходит. Не транслировать функциональщину в простой SQL, а собрать SQL в функциональщину, сделать трансформации, и разобрать обратно по ORM и "оптимизированному" SQL. Рефакторинг = запись преобразований трансформациями и метаданные ORM. кактус кактус кактус

> Да взять хоть твой же пример. Вот ты писал препроцессор для доступа по путям вроде a.b.c.d, потому что типы в SQL-атомы и наследования/агрегации не понимает. Но когда a.b.c.d превращается в цепочку JOIN'ов, выясняется что нужны индексы по foreign keys. То есть, в препроцессоре возникает "утечка абстракций", нормальную агрегацию эмулируем составными частями. То есть, по идее "препроцессор" должен генерировать не только целевой SQL с JOIN'ами, но и набор индексов.
Зачем? Индексы уже есть там, где нужны. Всё проверено и расставлено руками.

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

> Например, вот темлейтов бы туда, замыканий. Не в ANSI SQL, а во всякие PL/SQL и Transact SQL.

Чур меня, чур... Представляю что будет с "программистами 1С", если оная напихает этого в своё изобретение...