Сообщение Re[4]: Проблемы современных СУБД от 19.02.2018 18:41
Изменено 19.02.2018 18:46 vdimas
Re[4]: Проблемы современных СУБД
Здравствуйте, gandjustas, Вы писали:
_>>Ну и если говорить об автоматизации этого (чтобы не писать дважды), то и генерация проекции по типу и генерация типа по проекции делаются элементарно в статических языках с базовыми возможностями метапрограммирования и в любых динамических языках.
G>Про динамические языки речи нет. А "возможности метапрограммирования" в 90% случаев и означает цитирование кода
В 100% случаев "возможности метапрограммирования" в статических языках используются для другого — для compile-time выбора специфической реализации для специфических типов. Такое "вычисление" порой само является достаточно сложной программой, но её нет в бинарнике.
G>Есть таблица t а одной колонкой типа a, какой тип будет у проекции таблицы t, состоящей из (a,a,a,a,a,a,a,a,a,a,a,a,a,a,a,a,a...) ? Количество колонок может быть любое и не ограничено сверху разумными пределами.
Для конкретной компиллируемой программы выводимый тип кортежа всегда известен.
_>>Задавать в коде деревья выражений, которые потом будут интерпретироваться в рантайме умеют во множестве языков с незапамятных времён.
G>Назови хотя бы три из них. Чтобы статически типизированные что чтобы "деревья выражений" задавались тем же кодом что и сам язык без дополнительных приседаний.
Любой МЛ-подобный язык, типа того же Хаскеля.
И вообще любой язык с реализованными в нём замыканиями.
Только и это не обязательная фишка, а лишь бонусная к удобству, можно и без замыканий.
_>>Причём для этого в языке совершенно не требуется наличия той рефлексия-подобной штуки, которую подразумевал тут ты.
G>Рефлексия в каком-то виде все равно будет.
Разве что в compile-time.
В бинарнике типы стираются.
G>Ты же не сможешь проверить корректность дерева выражения относительно sql если не имеешь в дереве выражений информацию о типе.
В рантайм этого и не требуется, если компилятор обеспечивает строгую статическую типизацию.
_>>Тут подходят любые статические языки, имеющие элементы метапрограммирования, плюс большинство динамических языков. Т.е. в реальности выбор очень большой.
G>Да-да, назови хотя бы парочку (динамические не интересуют), ну чтобы можно было написать типа такого:
G>
В современном С++ можно что-то типа такого:
auto y = select(
filter(t, [](auto x){ return x.Category.Priority==1; }),
[](auto x){
return tuple(
field(StartDate) = x.StartDate.Date,
field(EndDate) = x.StartDate.Date + x.Duration / 24);
});
Гуглить "named tuple", это довольно популярное игрище.
https://github.com/duckie/named_types/tree/master/test
http://vitiy.info/named-tuple-for-cplusplus/
В "более функциональном" языке можно было с более простым синтаксисом лямбды сделать...
Только причём тут любой из мейнстримовых языков?
Обсуждаемое давно есть в не-мейнстримовых специализированных языках в достатке.
G>Тут и проекция, и соединение, и выражения над элементами кортежа.
Там даже есть сложение и деление!
G>Работа этого кода опирается на возможность цитирования и ad-hoc типы.
На костыли оно опирается.
Ср-вами самого языка не реализуемо, поэтому приходится добавлять в язык "специальные конструкции".
G>Покажи аналог на другом языке без ad-hoc типов или цитирования без потери типизированности или выразительности.
Можно и без ad-hoc типов, объявив тип результата заранее.
А можно и трусы через голову одевать.
G>Про тяжеловесные не надо расказывать. Они — раковая опухоль всей индустрии последние 20 лет. Я уверен что нет других "паттернов" или "технологий" кроме ORM
Он уверен. ))
ORM — это костыль над костылём.
Сейчас всё чаще обмениваются сообщениями известного типа и ORM не нужен.
G>А легковесные orm это не orm, а мапперы рекордсетов на объекты.
Рекордсеты — это динамическая хрень.
Любой маппинг из него тоже динамический.
Смысл это вообще обсуждать в этом топике?
_>>Правда не очень понятно зачем ты вообще об этом заговорил, т.к. все эти решения занимаются грубо говоря трансляцией кода некого языка в sql запрос, в то время как vdimas вроде как говорил о выкидывание самого sql из этой схемы. Правда я не очень вникал что он предложил на замену, но в любом случае все эти ORM и подобные им решения в таком случае будут не у дел.
G>Да, заметно что ты не вникал и мозг не включал.
G>Давай по порядку:
G>1) Чтобы выкинуть sql надо договориться о формате передачи запросов.
Ты проблему пока не озвучил.
G>2) Вряд ли vdimas хочет чтобы он был текстовым, иначе вряд ли бы он этот разговор вообще затеял.
Текстовое представление работает замечательно, оно скармливается компилятору, как скармливаются IDL, protobuf или просто h-файлы.
Бывают и не текстовые представления, типа typelib.
Только какаяя нафик разница — текстовое будет описание или не текстовое?
Ключевое тут в автоматизации распространения описания типов м/у частями системы.
А в каком именно виде — дело десятое.
G>3) На стороне языка должно быть средство генерации запроса в бинарном виде
Это вообще дичь какая-то.
G>желательно на основе типов и выражений самого языка.
Это и есть "просто программа", остальное — забота компилятора.
G>То есть для того кто пользуется orm или linq мало что изменится, но типа как "повысится эффективность".
Это всё тоже мимо, бо не нужно.
G>Но эффективность по факту упирается не в текстовый SQL, а в средства языка по формулированию сложных запросов к базе и скорость дисков.
Эффективность сегодня упирается в динамическое построение вариантов планов запросов и оценку их эффективности.
Само представление планов запросов динамическое, оценивающий код сверху плана интерпретирующий, схема слишком тормозная и слишком прожорливая к памяти.
_>>На самом деле как раз производителям СУБД это сделать довольно просто. Тут больше проблема в миллионах "пользователей", знающих только SQL (и там не только программисты, но и админы, аналитики и ещё много кто) и вряд ли желающих переучиваться на что-то иное даже ради некого повышения эффективности работы БД.
G>Просто сделать что?
Что обсуждается.
Уже давно сделано.
Не на том уровне, как хочется, но заметные подвижки есть.
G>Добавить еще один формат запросов? А зачем? Кому он нужен? Каким образом он добавит эффективности?
В типизированной системе "формат" каждого запроса уникален.
Это просто некое типизированное сообщение, PDU.
G>Понимаешь что амортизированная стоимость парсинга текстового запроса равна нулю?
И? На выходе всё равно получается его AST, которое необходимо интерпретировать в рантайм и это всё жутко тормозит.
G>В целом, кроме некоторых аспектов синтаксиса, sql довольно хороший язык.
С этой точки зрения Фортран тоже неплох.
Был.
G>А протокол взаимодействия программы с базой на основе генерации sql запросов — довольно хороший способ работы.
Часть прикладного кода живёт в самой БД, часть в сервере приложений, часть на клиенте.
Языки реализации всех 3-х частей часто разные.
Никакой проверки на правильность "состыковки" схем данных при передаче от уровня к уровню нет.
Все несостыковки вылазят уже в рантайм.
Сие убого донельзя.
_>>Ну и если говорить об автоматизации этого (чтобы не писать дважды), то и генерация проекции по типу и генерация типа по проекции делаются элементарно в статических языках с базовыми возможностями метапрограммирования и в любых динамических языках.
G>Про динамические языки речи нет. А "возможности метапрограммирования" в 90% случаев и означает цитирование кода
В 100% случаев "возможности метапрограммирования" в статических языках используются для другого — для compile-time выбора специфической реализации для специфических типов. Такое "вычисление" порой само является достаточно сложной программой, но её нет в бинарнике.
G>Есть таблица t а одной колонкой типа a, какой тип будет у проекции таблицы t, состоящей из (a,a,a,a,a,a,a,a,a,a,a,a,a,a,a,a,a...) ? Количество колонок может быть любое и не ограничено сверху разумными пределами.
Для конкретной компиллируемой программы выводимый тип кортежа всегда известен.
_>>Задавать в коде деревья выражений, которые потом будут интерпретироваться в рантайме умеют во множестве языков с незапамятных времён.
G>Назови хотя бы три из них. Чтобы статически типизированные что чтобы "деревья выражений" задавались тем же кодом что и сам язык без дополнительных приседаний.
Любой МЛ-подобный язык, типа того же Хаскеля.
И вообще любой язык с реализованными в нём замыканиями.
Только и это не обязательная фишка, а лишь бонусная к удобству, можно и без замыканий.
_>>Причём для этого в языке совершенно не требуется наличия той рефлексия-подобной штуки, которую подразумевал тут ты.
G>Рефлексия в каком-то виде все равно будет.
Разве что в compile-time.
В бинарнике типы стираются.
G>Ты же не сможешь проверить корректность дерева выражения относительно sql если не имеешь в дереве выражений информацию о типе.
В рантайм этого и не требуется, если компилятор обеспечивает строгую статическую типизацию.
_>>Тут подходят любые статические языки, имеющие элементы метапрограммирования, плюс большинство динамических языков. Т.е. в реальности выбор очень большой.
G>Да-да, назови хотя бы парочку (динамические не интересуют), ну чтобы можно было написать типа такого:
G>
G>from x in t
G>where t.Category.Priority==1
G>select {
G> StartDate = x.StartDate.Date,
G> EndDate = x.StartDate.Date + x.Duration / 24
G>}
G>В современном С++ можно что-то типа такого:
auto y = select(
filter(t, [](auto x){ return x.Category.Priority==1; }),
[](auto x){
return tuple(
field(StartDate) = x.StartDate.Date,
field(EndDate) = x.StartDate.Date + x.Duration / 24);
});
Гуглить "named tuple", это довольно популярное игрище.
https://github.com/duckie/named_types/tree/master/test
http://vitiy.info/named-tuple-for-cplusplus/
В "более функциональном" языке можно было с более простым синтаксисом лямбды сделать...
Только причём тут любой из мейнстримовых языков?
Обсуждаемое давно есть в не-мейнстримовых специализированных языках в достатке.
G>Тут и проекция, и соединение, и выражения над элементами кортежа.
Там даже есть сложение и деление!
G>Работа этого кода опирается на возможность цитирования и ad-hoc типы.
На костыли оно опирается.
Ср-вами самого языка не реализуемо, поэтому приходится добавлять в язык "специальные конструкции".
G>Покажи аналог на другом языке без ad-hoc типов или цитирования без потери типизированности или выразительности.
Можно и без ad-hoc типов, объявив тип результата заранее.
А можно и трусы через голову одевать.
G>Про тяжеловесные не надо расказывать. Они — раковая опухоль всей индустрии последние 20 лет. Я уверен что нет других "паттернов" или "технологий" кроме ORM
Он уверен. ))
ORM — это костыль над костылём.
Сейчас всё чаще обмениваются сообщениями известного типа и ORM не нужен.
G>А легковесные orm это не orm, а мапперы рекордсетов на объекты.
Рекордсеты — это динамическая хрень.
Любой маппинг из него тоже динамический.
Смысл это вообще обсуждать в этом топике?
_>>Правда не очень понятно зачем ты вообще об этом заговорил, т.к. все эти решения занимаются грубо говоря трансляцией кода некого языка в sql запрос, в то время как vdimas вроде как говорил о выкидывание самого sql из этой схемы. Правда я не очень вникал что он предложил на замену, но в любом случае все эти ORM и подобные им решения в таком случае будут не у дел.
G>Да, заметно что ты не вникал и мозг не включал.
G>Давай по порядку:
G>1) Чтобы выкинуть sql надо договориться о формате передачи запросов.
Ты проблему пока не озвучил.
G>2) Вряд ли vdimas хочет чтобы он был текстовым, иначе вряд ли бы он этот разговор вообще затеял.
Текстовое представление работает замечательно, оно скармливается компилятору, как скармливаются IDL, protobuf или просто h-файлы.
Бывают и не текстовые представления, типа typelib.
Только какаяя нафик разница — текстовое будет описание или не текстовое?
Ключевое тут в автоматизации распространения описания типов м/у частями системы.
А в каком именно виде — дело десятое.
G>3) На стороне языка должно быть средство генерации запроса в бинарном виде
Это вообще дичь какая-то.
G>желательно на основе типов и выражений самого языка.
Это и есть "просто программа", остальное — забота компилятора.
G>То есть для того кто пользуется orm или linq мало что изменится, но типа как "повысится эффективность".
Это всё тоже мимо, бо не нужно.
G>Но эффективность по факту упирается не в текстовый SQL, а в средства языка по формулированию сложных запросов к базе и скорость дисков.
Эффективность сегодня упирается в динамическое построение вариантов планов запросов и оценку их эффективности.
Само представление планов запросов динамическое, оценивающий код сверху плана интерпретирующий, схема слишком тормозная и слишком прожорливая к памяти.
_>>На самом деле как раз производителям СУБД это сделать довольно просто. Тут больше проблема в миллионах "пользователей", знающих только SQL (и там не только программисты, но и админы, аналитики и ещё много кто) и вряд ли желающих переучиваться на что-то иное даже ради некого повышения эффективности работы БД.
G>Просто сделать что?
Что обсуждается.
Уже давно сделано.
Не на том уровне, как хочется, но заметные подвижки есть.
G>Добавить еще один формат запросов? А зачем? Кому он нужен? Каким образом он добавит эффективности?
В типизированной системе "формат" каждого запроса уникален.
Это просто некое типизированное сообщение, PDU.
G>Понимаешь что амортизированная стоимость парсинга текстового запроса равна нулю?
И? На выходе всё равно получается его AST, которое необходимо интерпретировать в рантайм и это всё жутко тормозит.
G>В целом, кроме некоторых аспектов синтаксиса, sql довольно хороший язык.
С этой точки зрения Фортран тоже неплох.
Был.
G>А протокол взаимодействия программы с базой на основе генерации sql запросов — довольно хороший способ работы.
Часть прикладного кода живёт в самой БД, часть в сервере приложений, часть на клиенте.
Языки реализации всех 3-х частей часто разные.
Никакой проверки на правильность "состыковки" схем данных при передаче от уровня к уровню нет.
Все несостыковки вылазят уже в рантайм.
Сие убого донельзя.
Re[4]: Проблемы современных СУБД
Здравствуйте, gandjustas, Вы писали:
_>>Ну и если говорить об автоматизации этого (чтобы не писать дважды), то и генерация проекции по типу и генерация типа по проекции делаются элементарно в статических языках с базовыми возможностями метапрограммирования и в любых динамических языках.
G>Про динамические языки речи нет. А "возможности метапрограммирования" в 90% случаев и означает цитирование кода
В 100% случаев "возможности метапрограммирования" в статических языках используются для другого — для compile-time выбора специфической реализации для специфических типов. Такое "вычисление" порой само является достаточно сложной программой, но её нет в бинарнике.
G>Есть таблица t а одной колонкой типа a, какой тип будет у проекции таблицы t, состоящей из (a,a,a,a,a,a,a,a,a,a,a,a,a,a,a,a,a...) ? Количество колонок может быть любое и не ограничено сверху разумными пределами.
Для конкретной компиллируемой программы выводимый тип кортежа всегда известен.
_>>Задавать в коде деревья выражений, которые потом будут интерпретироваться в рантайме умеют во множестве языков с незапамятных времён.
G>Назови хотя бы три из них. Чтобы статически типизированные что чтобы "деревья выражений" задавались тем же кодом что и сам язык без дополнительных приседаний.
Любой МЛ-подобный язык, типа того же Хаскеля.
И вообще любой язык с реализованными в нём замыканиями.
Только и это не обязательная фишка, а лишь бонусная к удобству, можно и без замыканий.
_>>Причём для этого в языке совершенно не требуется наличия той рефлексия-подобной штуки, которую подразумевал тут ты.
G>Рефлексия в каком-то виде все равно будет.
Разве что в compile-time.
В бинарнике типы стираются.
G>Ты же не сможешь проверить корректность дерева выражения относительно sql если не имеешь в дереве выражений информацию о типе.
В рантайм этого и не требуется, если компилятор обеспечивает строгую статическую типизацию.
_>>Тут подходят любые статические языки, имеющие элементы метапрограммирования, плюс большинство динамических языков. Т.е. в реальности выбор очень большой.
G>Да-да, назови хотя бы парочку (динамические не интересуют), ну чтобы можно было написать типа такого:
G>
В современном С++ можно что-то типа такого:
Гуглить "named tuple", это довольно популярное игрище.
https://github.com/duckie/named_types/tree/master/test
http://vitiy.info/named-tuple-for-cplusplus/
В "более функциональном" языке можно было с более простым синтаксисом лямбды сделать...
Только причём тут любой из мейнстримовых языков?
Обсуждаемое давно есть в не-мейнстримовых специализированных языках в достатке.
G>Тут и проекция, и соединение, и выражения над элементами кортежа.
Там даже есть сложение и деление!
G>Работа этого кода опирается на возможность цитирования и ad-hoc типы.
На костыли оно опирается.
Ср-вами самого языка не реализуемо, поэтому приходится добавлять в язык "специальные конструкции".
G>Покажи аналог на другом языке без ad-hoc типов или цитирования без потери типизированности или выразительности.
Можно и без ad-hoc типов, объявив тип результата заранее.
А можно и трусы через голову одевать.
G>Про тяжеловесные не надо расказывать. Они — раковая опухоль всей индустрии последние 20 лет. Я уверен что нет других "паттернов" или "технологий" кроме ORM
Он уверен. ))
ORM — это костыль над костылём.
Сейчас всё чаще обмениваются сообщениями известного типа и ORM не нужен.
G>А легковесные orm это не orm, а мапперы рекордсетов на объекты.
Рекордсеты — это динамическая хрень.
Любой маппинг из него тоже динамический.
Смысл это вообще обсуждать в этом топике?
_>>Правда не очень понятно зачем ты вообще об этом заговорил, т.к. все эти решения занимаются грубо говоря трансляцией кода некого языка в sql запрос, в то время как vdimas вроде как говорил о выкидывание самого sql из этой схемы. Правда я не очень вникал что он предложил на замену, но в любом случае все эти ORM и подобные им решения в таком случае будут не у дел.
G>Да, заметно что ты не вникал и мозг не включал.
G>Давай по порядку:
G>1) Чтобы выкинуть sql надо договориться о формате передачи запросов.
Ты проблему пока не озвучил.
G>2) Вряд ли vdimas хочет чтобы он был текстовым, иначе вряд ли бы он этот разговор вообще затеял.
Текстовое представление работает замечательно, оно скармливается компилятору, как скармливаются IDL, protobuf или просто h-файлы.
Бывают и не текстовые представления, типа typelib.
Только какаяя нафик разница — текстовое будет описание или не текстовое?
Ключевое тут в автоматизации распространения описания типов м/у частями системы.
А в каком именно виде — дело десятое.
G>3) На стороне языка должно быть средство генерации запроса в бинарном виде
Это вообще дичь какая-то.
G>желательно на основе типов и выражений самого языка.
Это и есть "просто программа", остальное — забота компилятора.
G>То есть для того кто пользуется orm или linq мало что изменится, но типа как "повысится эффективность".
Это всё тоже мимо, бо не нужно.
G>Но эффективность по факту упирается не в текстовый SQL, а в средства языка по формулированию сложных запросов к базе и скорость дисков.
Эффективность сегодня упирается в динамическое построение вариантов планов запросов и оценку их эффективности.
Само представление планов запросов динамическое, оценивающий код сверху плана интерпретирующий, схема слишком тормозная и слишком прожорливая к памяти.
_>>На самом деле как раз производителям СУБД это сделать довольно просто. Тут больше проблема в миллионах "пользователей", знающих только SQL (и там не только программисты, но и админы, аналитики и ещё много кто) и вряд ли желающих переучиваться на что-то иное даже ради некого повышения эффективности работы БД.
G>Просто сделать что?
Что обсуждается.
Уже давно сделано.
Не на том уровне, как хочется, но заметные подвижки есть.
G>Добавить еще один формат запросов? А зачем? Кому он нужен? Каким образом он добавит эффективности?
В типизированной системе "формат" каждого запроса уникален.
Это просто некое типизированное сообщение, PDU.
G>Понимаешь что амортизированная стоимость парсинга текстового запроса равна нулю?
И? На выходе всё равно получается его AST, которое необходимо интерпретировать в рантайм и это всё жутко тормозит.
G>В целом, кроме некоторых аспектов синтаксиса, sql довольно хороший язык.
С этой точки зрения Фортран тоже неплох.
Был.
G>А протокол взаимодействия программы с базой на основе генерации sql запросов — довольно хороший способ работы.
Часть прикладного кода живёт в самой БД, часть в сервере приложений, часть на клиенте.
Языки реализации всех 3-х частей часто разные.
Никакой проверки на правильность "состыковки" схем данных при передаче от уровня к уровню нет.
Все несостыковки вылазят уже в рантайм.
Сие убого донельзя.
_>>Ну и если говорить об автоматизации этого (чтобы не писать дважды), то и генерация проекции по типу и генерация типа по проекции делаются элементарно в статических языках с базовыми возможностями метапрограммирования и в любых динамических языках.
G>Про динамические языки речи нет. А "возможности метапрограммирования" в 90% случаев и означает цитирование кода
В 100% случаев "возможности метапрограммирования" в статических языках используются для другого — для compile-time выбора специфической реализации для специфических типов. Такое "вычисление" порой само является достаточно сложной программой, но её нет в бинарнике.
G>Есть таблица t а одной колонкой типа a, какой тип будет у проекции таблицы t, состоящей из (a,a,a,a,a,a,a,a,a,a,a,a,a,a,a,a,a...) ? Количество колонок может быть любое и не ограничено сверху разумными пределами.
Для конкретной компиллируемой программы выводимый тип кортежа всегда известен.
_>>Задавать в коде деревья выражений, которые потом будут интерпретироваться в рантайме умеют во множестве языков с незапамятных времён.
G>Назови хотя бы три из них. Чтобы статически типизированные что чтобы "деревья выражений" задавались тем же кодом что и сам язык без дополнительных приседаний.
Любой МЛ-подобный язык, типа того же Хаскеля.
И вообще любой язык с реализованными в нём замыканиями.
Только и это не обязательная фишка, а лишь бонусная к удобству, можно и без замыканий.
_>>Причём для этого в языке совершенно не требуется наличия той рефлексия-подобной штуки, которую подразумевал тут ты.
G>Рефлексия в каком-то виде все равно будет.
Разве что в compile-time.
В бинарнике типы стираются.
G>Ты же не сможешь проверить корректность дерева выражения относительно sql если не имеешь в дереве выражений информацию о типе.
В рантайм этого и не требуется, если компилятор обеспечивает строгую статическую типизацию.
_>>Тут подходят любые статические языки, имеющие элементы метапрограммирования, плюс большинство динамических языков. Т.е. в реальности выбор очень большой.
G>Да-да, назови хотя бы парочку (динамические не интересуют), ну чтобы можно было написать типа такого:
G>
G>from x in t
G>where t.Category.Priority==1
G>select {
G> StartDate = x.StartDate.Date,
G> EndDate = x.StartDate.Date + x.Duration / 24
G>}
G>В современном С++ можно что-то типа такого:
auto y = select(
filter(t, [](auto x){ return x.Category.Priority==1; }),
[](auto x){
return tuple(
field(StartDate) = x.StartDate.Date,
field(EndDate) = x.StartDate.Date + x.Duration / 24);
});Гуглить "named tuple", это довольно популярное игрище.
https://github.com/duckie/named_types/tree/master/test
http://vitiy.info/named-tuple-for-cplusplus/
В "более функциональном" языке можно было с более простым синтаксисом лямбды сделать...
Только причём тут любой из мейнстримовых языков?
Обсуждаемое давно есть в не-мейнстримовых специализированных языках в достатке.
G>Тут и проекция, и соединение, и выражения над элементами кортежа.
Там даже есть сложение и деление!
G>Работа этого кода опирается на возможность цитирования и ad-hoc типы.
На костыли оно опирается.
Ср-вами самого языка не реализуемо, поэтому приходится добавлять в язык "специальные конструкции".
G>Покажи аналог на другом языке без ad-hoc типов или цитирования без потери типизированности или выразительности.
Можно и без ad-hoc типов, объявив тип результата заранее.
А можно и трусы через голову одевать.
G>Про тяжеловесные не надо расказывать. Они — раковая опухоль всей индустрии последние 20 лет. Я уверен что нет других "паттернов" или "технологий" кроме ORM
Он уверен. ))
ORM — это костыль над костылём.
Сейчас всё чаще обмениваются сообщениями известного типа и ORM не нужен.
G>А легковесные orm это не orm, а мапперы рекордсетов на объекты.
Рекордсеты — это динамическая хрень.
Любой маппинг из него тоже динамический.
Смысл это вообще обсуждать в этом топике?
_>>Правда не очень понятно зачем ты вообще об этом заговорил, т.к. все эти решения занимаются грубо говоря трансляцией кода некого языка в sql запрос, в то время как vdimas вроде как говорил о выкидывание самого sql из этой схемы. Правда я не очень вникал что он предложил на замену, но в любом случае все эти ORM и подобные им решения в таком случае будут не у дел.
G>Да, заметно что ты не вникал и мозг не включал.
G>Давай по порядку:
G>1) Чтобы выкинуть sql надо договориться о формате передачи запросов.
Ты проблему пока не озвучил.
G>2) Вряд ли vdimas хочет чтобы он был текстовым, иначе вряд ли бы он этот разговор вообще затеял.
Текстовое представление работает замечательно, оно скармливается компилятору, как скармливаются IDL, protobuf или просто h-файлы.
Бывают и не текстовые представления, типа typelib.
Только какаяя нафик разница — текстовое будет описание или не текстовое?
Ключевое тут в автоматизации распространения описания типов м/у частями системы.
А в каком именно виде — дело десятое.
G>3) На стороне языка должно быть средство генерации запроса в бинарном виде
Это вообще дичь какая-то.
G>желательно на основе типов и выражений самого языка.
Это и есть "просто программа", остальное — забота компилятора.
G>То есть для того кто пользуется orm или linq мало что изменится, но типа как "повысится эффективность".
Это всё тоже мимо, бо не нужно.
G>Но эффективность по факту упирается не в текстовый SQL, а в средства языка по формулированию сложных запросов к базе и скорость дисков.
Эффективность сегодня упирается в динамическое построение вариантов планов запросов и оценку их эффективности.
Само представление планов запросов динамическое, оценивающий код сверху плана интерпретирующий, схема слишком тормозная и слишком прожорливая к памяти.
_>>На самом деле как раз производителям СУБД это сделать довольно просто. Тут больше проблема в миллионах "пользователей", знающих только SQL (и там не только программисты, но и админы, аналитики и ещё много кто) и вряд ли желающих переучиваться на что-то иное даже ради некого повышения эффективности работы БД.
G>Просто сделать что?
Что обсуждается.
Уже давно сделано.
Не на том уровне, как хочется, но заметные подвижки есть.
G>Добавить еще один формат запросов? А зачем? Кому он нужен? Каким образом он добавит эффективности?
В типизированной системе "формат" каждого запроса уникален.
Это просто некое типизированное сообщение, PDU.
G>Понимаешь что амортизированная стоимость парсинга текстового запроса равна нулю?
И? На выходе всё равно получается его AST, которое необходимо интерпретировать в рантайм и это всё жутко тормозит.
G>В целом, кроме некоторых аспектов синтаксиса, sql довольно хороший язык.
С этой точки зрения Фортран тоже неплох.
Был.
G>А протокол взаимодействия программы с базой на основе генерации sql запросов — довольно хороший способ работы.
Часть прикладного кода живёт в самой БД, часть в сервере приложений, часть на клиенте.
Языки реализации всех 3-х частей часто разные.
Никакой проверки на правильность "состыковки" схем данных при передаче от уровня к уровню нет.
Все несостыковки вылазят уже в рантайм.
Сие убого донельзя.