Здравствуйте, IB, Вы писали:
>Ну теперь-то, надеюсь, вопросов будет поменьше, чего тебя тут большинство коллег игнорят, кроме rsdn team и "приближённых"? IB>Ты опять находишь проблемы там где их нет. У меня нет проблем с тем, что меня кто-то игнорит, поэтому переставай пить коньяк по утрам
Я не сказал, что это «проблема», я просто констатирую факт – с тобой общаются не охотно. До тех пор, пока тебя это не беспокоит, это не является для тебя проблемой, разумеется.
V>>Специально за тобой не слежу, просто память хорошая, IB>Ой, ну ладно, не оправдывайся, тут все свои )) Не стесняйся, я уже понял, что ты ко мне не равнодушен =)
Ровно в том же смысле не равнодушен, как и к нескольким сотням других коллег с этого сайта.
V>>Понятно, что у тебя с памятью похуже, IB>Ты про меня уже целую биографию сочинил, хотя казалось бы, собрались пообсуждать недостатки SQL.
Не сочинил, мы с тобой уже общались несколько раз и все разы неудачно.
C тобой "пообсуждать" никак, бо происходящее всегда одинаково – не разобравшись влететь, понаставить диагнозов и гордо удалиться…
Никакие обсуждения тебя не интересуют, тебе подойдёт только «признание твоей правоты».
Как некий элемент традиции, вестимо.
Ну понятно, что "обсуждать" что-либо тут будет глупо, вот с тобой и не обсуждают.
Я ХЗ как некоторые не догоняют простых вещей, например, что сам по себе обмен аргументами в техническом споре – это нормально.
Но когда чел руинит спор, пресекая малейшие попытки обмена аргументами (причём, чаще не специально, а на твой манер — как слон в посудной лавке, что еще больше бесит, бо чел не видит себя со стороны), да еще если сам оказывается не прав технически (твои "невозможно знать заранее"), плюс еще ошибка детская – это всё составляет эпик фейл, аднака.
V>>Да, это всё учат в ВУЗ-ах профильных специальностей еще на 4-м курсе. IB>В свое время, я этот курс читал в одном из не самых плохих вузов нашей прекрасной страны
«Этот курс»…
Этих курсов было как минимум 3 сильно разных.
Так перед кем ты опять пытаешься надуть своё ЧСВ?
Берем на те года специальности 2202 и 2204 — «автоматизированные системы обработки информации», «программное обеспечение выч. систем» или близкие к ним более поздние (с начальными индексами 6 и 7). Согласно твоих представлений о происходящем, скорее всего ты читал именно это. Бо именно в этих специальностях дают заметный упор на БД сугубо в прикладном плане. Они там, действительно, даже SQL учат, даже прямо на лекциях, а не на лабораторках и практических занятиях, ы-ы-ы.
Собсно, именно эти же специальности были и есть в том числе в виде среднего, а не высшего образования. Причём, как у нас, так и во всём мире — всякие колледжи и т.д., где тоже учат языкам программирования, в т.ч. SQL, а так же как правильно админить SQL-сервера, как запускать дефрагментацию индексов, зачем это надо и т.д. ))
Совсем другой курс читается на специальности 2201 «выч. машины, комплексы, сети» и близкой более поздней (после 94-го года) россыпи их. На этом курсе учат разрабатывать не прикладные БД, а именно СУБД. Учат не языку SQL, а навыкам разрабатывать языки, типа SQL, и весь механизм под ними.
Вот и получается у тебя смешная попытка манипулирования перед "остальными". Бо разве что вводный материал у этих курсов где-то похож, но целом м/у этими двумя направлениями чудовищная пропасть.
Чисто для сравнения (кому любопытно).
По первому направлению подготавливаются следующие специалисты (современное положение вещей):
• разработчик робототехнических систем и комплексов
• руководитель соответствующих подразделений
• разработчик систем управления и автоматики
• разработчик моделей обработки данных
• архитектор информационных систем
• специалист по проектированию и эксплуатации локальных вычислительных сетей
• специалист по эксплуатации информационных систем
• системный администратор
Вкратце — прикладуха и обслуживание ПО.
По второму:
• системный аналитик
• научный работник в области IT
• разработчик микропроцессорных систем
• проектировщик вычислительной техники
• специалист по наладке и ремонту выч. техники и их сетей
• системный программист
• инженер-системотехник
Вкратце — разработка программно-аппаратных выч. систем, "платформ", исследования в этом направлении.
На Западе это известное отличие читается как отличие "разработчика информационных систем" от "системного аналитика".
"Системный аналитик" – это наиболее близкий западный аналог нашей специальности «инженер-системотехник», где первое название в последние лет 10-15 всё охотнее применяется вместо второго.
Характерно (опять же, судя по обсуждениям тут) что эту специальность многие наши коллеги не понимают, часто путают с аналитиком предметной области – т.е. с «бизнес-аналитиком». А даже те, кто понимают эту специальность, часто невольно выхолащивают её до «сбора требований и постановки задачи», хотя это лишь малая часть деятельности. Просто одна из самых важных в IT (ИМХО), но всё-равно, это лишь некий этап разработки, а не она вся.
(да, тут на сайте регулярно замечаю даже за весьма неглупыми коллегами откровенно неудовлетворительные навыки формулирования проблематики, поубывав бы).
Системный аналитик не просто ставит задачу, а хорошо ориентируется в техническом аспекте её реализуемости, т.е. проводит поиск решений в ограничениях. Работа циничная и творческая одновременно. Именно для этого его взращивали как междисциплинарного специалиста, т.е. такого, который владеет как прикладными аспектами, так и системными, вплоть до особенностей железа, линий связи и т.д. Вплоть до того, что недостающее железо, линии передачи информации (сам их физический принцип или вплоть до способа модуляции несущих и поднесущих) или недостающее низкоуровневое программное обеспечение – всё это запросто реализуется в рамках проекта и я такое делал не раз.
"Прикладникам" такие фокусы не доступны, но прикладники и не разрабатывают движки БД, а обсуждалось именно это.
Известный "мем" — это как если прикладник в Дельфи не нашёл нужный ТКомпонент, то задача не имеет решения. ))
Собсно, нигде в мире отдельных "низкоуровневых системщиков" не готовили и готовить никогда не будут. Любой "низкоуровневый системщик" во всём мире готовится исключительно как "системный аналитик" и никак иначе, потому что разработка "базы", "платформы" — это наиболее ответственная часть в современном IT, по понятной причине — ошибки на этом уровне чудовищно дорогие из-за эффекта масштабирования.
Например, пользователю БД важно написать правильный SQL запрос к СУБД, но гораздо важнее, чтобы ЛЮБОЙ допустимый запрос правильно отработал на стороне самой СУБД.
IB>так что давай, расскажи мне чему учат на профильных специальностях
А то ты не знал?
Девочку из себя строить было не обязательно.
Пришлось расписать суть твоего манипулирования.
Ну, чтобы, не слишком гордо удалялся, угу.
IB>Буквально как в анекдоте — "там где вы учились, мы преподавали"
Хы-хы.
"Вы" не могли преподавать там, где я учился, иначе бы "вы" не палились насчёт "посмотри, сколько много закешировано планов".
Пока что ты дал понять, что не в курсе, в каком виде эти планы хранятся, какие там структуры данных и как можно на них сэкономить на порядок-другой, если дать достаточно времени на тождественные преобразования замкнутой системы уравнений РИ.
Да и вообще, чужая недогадливость — она всегда раздражает. У тебя достаточно опыта чтобы знать — современные СУБД часто не в состоянии отличить два простых запроса, отличающихся одной вшивой константой в предикате ограничения. Именно поэтому "руководство пользователя" СУБД прямо рекомендует превращать такие однотипные запросы в запросы с параметром и делать им prepare, иначе система будет динамически плодить всё новые и новые планы запросов, к количеству которых ты апеллируешь. Добавь к этому тот факт, что СУБД запросто считает разными даже совершенно идентичные по-сути запросы, но с небольшой переформулировкой выражений в нём, т.е. плодит и плодит в том числе идентичные наборы планов, сцуко. Кароч, из-за всей абсурдности этого цирка я уже не знаю, смеяться мне или плакать и куда я вообще попал? ))
С одной стороны (мне казалось это очевидным для всех), при статической компиляции запросы с параметрами + prepare будут как мёртвому припарка, бо и без подсказок со стороны сопливых компилятор прекрасно разберётся. Причём, он разберётся и найдёт идентичности даже там, где ты и вообразить не мог, даже у тех запросов или частей их, которые никак не кажутся похожими.
С другой стороны, мне тут в лицо аргументы – идите почитайте про "prepare". ))
«Вот вам букварь» — мой ответ.
Но хрен с ним, идём далее.
Когда речь о компиляции алгоритма над константными структурами данных, то сами данные часто исчезают – превращаются тупо в код (раскрутка циклов и рекурсивных вызовов и всё это опять рекурсивно). Тем самым убирается еще один уровень интерпретирования над данными, который практически всегда есть даже в самой-пресамой нейтивной программе над неконстантными данными. Но мы-то говорим о константных данных, т.е. которые можно превращать в код (всё мн-во запросов и планов по ним).
Или еще пример – во многих "больших" системах в избытке наличествуют данные справочного характера, причём, некоторые из этих данных меняются очень редко или не меняются никогда (для примера – виды ордеров, т.е. такие данные, которые бесполезно менять без изменений в коде, т.е. для данного состояния кода они, по-сути, не меняются). Т.е., хватает таблиц небольшого размера, которые можно считать эдаким способом подробного описания enum-ов, просто на стороне базы, а не на клиенте. Всю эту шелуху тоже можно убрать нафик из таблиц (убрать сами таблицы), тупо инлайня код с их участием. Подобных мелочей хватает, но они могут кардинально влиять на происходящее, делая ассоциации "бесплатными" — например, вместо ID такого enum в других таблицах можно хранить физическое смещение на структуру в сегменте константных данных скомпиллированного бинарника. И такий мелочей, стоит только ногтём подцепить, — овердохрена.
Так же я давал оценку «распухания кода» (дополнительного объема) и сравнивал сие с объемом кода, который требуется для работы нынешней динамической системы (изымаемого объема). В динамической системе сегодня живёт и компилятор и интерпретатор, но это ж чудовищный объем функциональности, который и нафик не сдался скомпиллированному бинарнику.
И пусть мои прикидки грубые – это же лишь затравка для начала обсуждения, не? ))
Например, мне тут "напомнили", что в средней прикладной базе живёт пару тыс и более запросов. У меня и ответ давно имеется – там (грубо) 80% кода, считай, дублирует друг друга, а из оставшихся 20% половина является библиотечным слоем. Т.е. в случае компиляции дублирование исчезает и с библиотеками всяко получше, бо для статически собираемой системы объем данных свыше библиотек теоретически не ограничен – всё-равно в бинарь попадёт только используемое по-факту. Совсем другое дело для динамических систем, верно? Там особо не разбежишься с библиотеками.
V>> если предположить гипотеитческий вариант "все запросы известны заранее". IB>Тот факт, что это гипотетическое предположение ошибочно, ты предпочел проигнорировать. IB>Конечно, это же разрушит такую прекрасную теорию.
Если сам не понимаешь — спроси у коллег, хосподя, например, из вашей же rsdn team. Большинство из них (или даже все поголовно) прекрасно понимают, почему в случае статической компиляции "все запросы известны заранее" (С). И это вообще не теория, это постулат, условие существования такой системы.
V>>Мы были вынуждены писать учётные системы с бухгелтериями и прочий сугубо прикладной шлак уровня домохозяек с PHP, вместо того, чтобы участвовать в разработках самих технологий. IB>В очередной раз советую тебе не судить обо всех по себе.
Я могу судить лишь по открытым источникам — по твоим статьям и по тому, что ты писал в форумы в те годы, когда был активен.
Кароч, это всё гребанный PHP, вид сбоку.
Я ХЗ как лично ты на это смотришь, но мне в те годы было стыдно каждую секунду такого времяпрепровождения. С тем же успехом можно было бесконечно админить линуха какие-нить. Тем более, что до этого уже довелось поработать ~6 лет именно системщиком, а не прикладником. И если ты сейчас более не занимаешься такой юзверской деятельностью, а сам участвуешь в разработке технологий, то я только за тебя порадуюсь, мне не жалко. Но в этот спор ты влез, увы, с колокольни махрового юзера с раненным ЧСВ.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, kov_serg, Вы писали:
_>>
Будущий язык будет обеспечивать в процессе работы модули безопасности и контролируемый доступ к данным.
_>>Поддержка сорм из каропки это замечательно.
V>Справедливости ради, удобный язык для удалённого доступа к данным напрашивается уже слишком давно. V>Потому что SQL безбожно устарел и вообще в современной разработке является сущностью второго рода — производной генерируемой хренью/абракадаброй.
Ооо, как я мог пропустить очередной срачЪ на тему "SQL против людей которые считают себя умнее других"...
Причем не от кого-то, а от человека с самым высоким ЧСВ и самой низкой квалификацией на форуме.
Похоже ты открыл для себя работу с СУБД на этот раз...
Люди пользуются SQL добрых 30 лет (+\-) и никто (реально НИКТО) не изобрел ничего лучше. Как думаешь почему?
Попробуем проанализировать причины.
С точки зрения языков общего назначения:
1) В реляционной алгебре (РА) есть проекция. Из-за нее количество типов, которыми оперирует РА, бесконечно. В статически типизированном языке любая попытка сгенерировать типы для работы с данными обречена на провал.
2) Можно генерировать типы ad-hoc, это делается в небольшом количестве языков на сегодня.
3) Нужно уметь в языке представлять операции РА и выражения над элементами кортежей. Если мы работаем с типами языка, то и выражения должны быть выражениями языка, а не dsl. По сути для полноценной реализации нужно цитирование.
4) Посчитаем мейнстрим-языки, которые умеют цитирование и ad-hoc типы. Я знаю C# и F# (он мейнстримый с натяжкой), оба умеют Linq.
5) А что если не генерировать типы и не использовать цитирование? Тогда мы получаем тяжеловесные ORM со всеми их недостатками, которые уже не раз написали в этой теме.
В итоге остается создать только новый язык, который будет лучше C# (в чем? сколько это будет стоить?). А потом продавить производителей СУБД чтобы они новый формат поддержали. Но тут проблема.
С точки зрения производителей БД:
6) Текстовый язык запросов на два порядка легче расширять, чем бинарный.
7) Используя SQL можно получить больше пользователей, чем любой другой язык запросов. Многие нереляционные субд используют sql-подобный язык.
8) Выгоды от использования нетекстового языка запросов — никакой. Парсинг запроса даже в 10кб текста занимает бесконечно малое время по сравнением со временем построения плана. А потом все движки этот план кешируют и повторно текст запроса даже не парсят.
В итоге все, кто думает на два-три шага дальше, чем средний программист с завышенным ЧСВ, понимают что нет смысла устраивать революцию. Лучше спокойно допиливать средства с обоих стороны.
Например на волне хайпа с NoSQL взрослые движки впитали в себя полезные фичи, а языки обзавелись универсальными интерфейсами, с которыми можно и в монгу и в оракл сходить, используя по-максимуму фичи разных движков.
Здравствуйте, gandjustas, Вы писали:
G>1) В реляционной алгебре (РА) есть проекция. Из-за нее количество типов, которыми оперирует РА, бесконечно. В статически типизированном языке любая попытка сгенерировать типы для работы с данными обречена на провал.
G>3) Нужно уметь в языке представлять операции РА и выражения над элементами кортежей. Если мы работаем с типами языка, то и выражения должны быть выражениями языка, а не dsl. По сути для полноценной реализации нужно цитирование.
G>5) А что если не генерировать типы и не использовать цитирование? Тогда мы получаем тяжеловесные ORM со всеми их недостатками, которые уже не раз написали в этой теме.
G>В итоге остается создать только новый язык, который будет лучше C#
G>6) Текстовый язык запросов на два порядка легче расширять, чем бинарный.
G>7) Используя SQL можно получить больше пользователей, чем любой другой язык запросов.
(тут сугубо по способности строить предложения)
G>8) Выгоды от использования нетекстового языка запросов — никакой.
G>Парсинг запроса даже в 10кб текста занимает бесконечно малое время по сравнением со временем построения плана. А потом все движки этот план кешируют и повторно текст запроса даже не парсят.
Особенно доставил пункт 6.
"Бинарный язык запросов"...
Куда? Зачем? При чём тут это, вообще?
Мрак...
Re[28]: В России опять напишут новый объектно-ориентированны
Здравствуйте, vdimas, Вы писали:
V>Я не сказал, что это «проблема», я просто констатирую факт – с тобой общаются не охотно.
То что ты в фактах путаешься уже давно понятно, но твое трогательное внимание к моей персоне по прежнему забавляет =)
V> До тех пор, пока тебя это не беспокоит, это не является для тебя проблемой, разумеется.
Но очевидно это беспокоит тебя!
V>Ровно в том же смысле не равнодушен, как и к нескольким сотням других коллег с этого сайта.
У тебя накоплено несколько сотен описаний биографии и профессиональной квалификации коллег с этого сайта?! Эту бы энергию да в мирных целях...
V>Не сочинил, мы с тобой уже общались несколько раз и все разы неудачно.
С твоим апломбом это не удивительно..
V>Но когда чел руинит спор, пресекая малейшие попытки обмена аргументами (причём, чаще не специально, а на твой манер — как слон в посудной лавке, что еще больше бесит, бо чел не видит себя со стороны), да еще если сам оказывается не прав технически (твои "невозможно знать заранее"), плюс еще ошибка детская – это всё составляет эпик фейл, аднака.
Вот сейчас ты очень верно себя описал. =)
Вот ты капец смешной. Боюсь, что это не лечится... V>Так перед кем ты опять пытаешься надуть своё ЧСВ?
V>Берем на те года специальности 2202 и 2204 — «автоматизированные системы обработки информации», «программное обеспечение выч. систем» или близкие к ним более поздние (с начальными индексами 6 и 7). Согласно твоих представлений о происходящем, скорее всего ты читал именно это.
Не угадал, я же подсказку дал — не самый плохой ВУЗ, профильная специальность.
V>Вот и получается у тебя смешная попытка манипулирования перед "остальными".
У тебя получается смешная попытка оценить мою квалификацию по фотографии. Забавно, но не конструктивно...
V>Пришлось расписать суть твоего манипулирования. V>Ну, чтобы, не слишком гордо удалялся, угу.
Пока что ты расписываешь свое уникальное умение тыкать пальцем в небо...
V>Да и вообще, чужая недогадливость — она всегда раздражает.
Ну или забавляет =)
V> У тебя достаточно опыта чтобы знать — современные СУБД часто не в состоянии отличить два простых запроса, отличающихся одной вшивой константой в предикате ограничения.
Друг мой. Если бы ты, вместо того, чтобы тратить время на описание моей биографии, профессиональной квалификации и эакулирование на образование системного аналитика, взял бы и почитал, наконец, учебник в который я тебя посылаю, то ты бы знал, что твое утверждение устарело лет на пятнадцать.
Оптимизаторы современных баз давно умеют схлопывать одинаковые запросы с разными константами, более того, они давно умеют НЕ схлопывать запросы в тех случаях, когда планы для разных констант отличаются.
V> Именно поэтому "руководство пользователя" СУБД прямо рекомендует превращать такие однотипные запросы в запросы с параметром и делать им prepare, иначе система будет динамически плодить всё новые и новые планы запросов, к количеству которых ты апеллируешь.
Вот щас ты рассуждаешь аккурат как тот прикладник, который дальше введения в учебник не заглядывал. Профильное образование в прок не пошло?
V>С одной стороны (мне казалось это очевидным для всех), при статической компиляции запросы с параметрами + prepare будут как мёртвому припарка, бо и без подсказок со стороны сопливых компилятор прекрасно разберётся.
Как видишь, статическая компиляция здесь не нужна. Более того (мне казалось это очевидным для всех), в рантайме у базы заведомо больше информации для оптимизации запросов, так что переносить это в компайл-тайм — только мешать базе выполнять свою работу.
V>С другой стороны, мне тут в лицо аргументы – идите почитайте про "prepare". )) V>«Вот вам букварь» — мой ответ.
"Садись, два". Ты не дочитал...
V> Всю эту шелуху тоже можно убрать нафик из таблиц (убрать сами таблицы), тупо инлайня код с их участием.
Нельзя. Взгляни на проблему шире — приложение может быть и не одно, а база та же и данные те же. Так что нет, нельзя всосать часть данных в код и сказать, что так и было.
С другой стороны, нет никаких проблем закешировать статические таблицы и работать с ними из памяти, для этого не нужно переностить SQL в компайл-тайм, собственно, обычно так и делают, если это критично.
V>И пусть мои прикидки грубые – это же лишь затравка для начала обсуждения, не? ))
Они слишком грубые, даже для начала обсуждения.
V>Я ХЗ как лично ты на это смотришь, но мне в те годы было стыдно каждую секунду такого времяпрепровождения.
И что мы видим сейчас? Очевидно, твое времяпрепровождение тебе на пользу не пошло =)
Здравствуйте, gandjustas, Вы писали:
G>Попробуем проанализировать причины. G>С точки зрения языков общего назначения: G>1) В реляционной алгебре (РА) есть проекция. Из-за нее количество типов, которыми оперирует РА, бесконечно. В статически типизированном языке любая попытка сгенерировать типы для работы с данными обречена на провал.
Ой, а где же у нас задаётся проекция? Случаем не внутри того же самого статического языка? А почему мы тогда не забыли задать проекцию, но забыли задать соответствующий ей тип? )))
Ну и если говорить об автоматизации этого (чтобы не писать дважды), то и генерация проекции по типу и генерация типа по проекции делаются элементарно в статических языках с базовыми возможностями метапрограммирования и в любых динамических языках.
G>2) Можно генерировать типы ad-hoc, это делается в небольшом количестве языков на сегодня.
Только это вообще не нужно для данной задачи.
G>3) Нужно уметь в языке представлять операции РА и выражения над элементами кортежей. Если мы работаем с типами языка, то и выражения должны быть выражениями языка, а не dsl. По сути для полноценной реализации нужно цитирование.
Задавать в коде деревья выражений, которые потом будут интерпретироваться в рантайме умеют во множестве языков с незапамятных времён. Причём для этого в языке совершенно не требуется наличия той рефлексия-подобной штуки, которую подразумевал тут ты.
G>4) Посчитаем мейнстрим-языки, которые умеют цитирование и ad-hoc типы. Я знаю C# и F# (он мейнстримый с натяжкой), оба умеют Linq.
Тут подходят любые статические языки, имеющие элементы метапрограммирования, плюс большинство динамических языков. Т.е. в реальности выбор очень большой.
G>5) А что если не генерировать типы и не использовать цитирование? Тогда мы получаем тяжеловесные ORM со всеми их недостатками, которые уже не раз написали в этой теме.
Всякие делают. И тяжеловесные, которые при этом удобно задают какие-то часто употребимые шаблоны работы в ущерб производительности. И быстрые (поэффективнее всяких там Linq, т.к. не требуют прогулок рефлексией по дереву), но при этом с близким к SQL синтаксисом (что для реальных задач не всегда удобно). Есть решения на любой вкус.
Правда не очень понятно зачем ты вообще об этом заговорил, т.к. все эти решения занимаются грубо говоря трансляцией кода некого языка в sql запрос, в то время как vdimas вроде как говорил о выкидывание самого sql из этой схемы. Правда я не очень вникал что он предложил на замену, но в любом случае все эти ORM и подобные им решения в таком случае будут не у дел.
G>В итоге остается создать только новый язык, который будет лучше C# (в чем? сколько это будет стоить?). А потом продавить производителей СУБД чтобы они новый формат поддержали. Но тут проблема.
На самом деле как раз производителям СУБД это сделать довольно просто. Тут больше проблема в миллионах "пользователей", знающих только SQL (и там не только программисты, но и админы, аналитики и ещё много кто) и вряд ли желающих переучиваться на что-то иное даже ради некого повышения эффективности работы БД.
Хотя если посмотреть на текущую ситуацию с OpenGL (и соответствующим языком шейдеров) и Vulkan'ом (который пришёл на замену), то прослеживаются некоторые интересные аналогии. Если кто-то создаст нечто типа Vulkan'а (с таким же приростом производительности), только для СУБД, и его примут все основные производители (как произошло с вендорами видеочипов) то возможно что и побежит народ...
G>С точки зрения производителей БД: G>6) Текстовый язык запросов на два порядка легче расширять, чем бинарный. G>7) Используя SQL можно получить больше пользователей, чем любой другой язык запросов. Многие нереляционные субд используют sql-подобный язык. G>8) Выгоды от использования нетекстового языка запросов — никакой. Парсинг запроса даже в 10кб текста занимает бесконечно малое время по сравнением со временем построения плана. А потом все движки этот план кешируют и повторно текст запроса даже не парсят.
Вроде про нетекстовый язык тут особо не говорили. Хотя могу тебе тут напомнить про BSON (бинарный JSON), используемый в MongoDB — можешь посмотреть на мотивы его появления. Но это отдельная тема для разговора, не имеющая особого отношения к утверждению об убогости SQL (его текстовость явно не входит даже в первую десятку минусов языка).
G>В итоге все, кто думает на два-три шага дальше, чем средний программист с завышенным ЧСВ, понимают что нет смысла устраивать революцию. Лучше спокойно допиливать средства с обоих стороны. G>Например на волне хайпа с NoSQL взрослые движки впитали в себя полезные фичи, а языки обзавелись универсальными интерфейсами, с которыми можно и в монгу и в оракл сходить, используя по-максимуму фичи разных движков.
Только после всего этого "не взрослые" nosql движки почему-то не пропали с горизонта, а продолжают вполне себе успешно теснить старые решения. Да, не во всех областях и возможно не такими мощными темпами, как во времена хайпа, но процесс вполне себе продолжается...
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, gandjustas, Вы писали:
G>>Попробуем проанализировать причины. G>>С точки зрения языков общего назначения: G>>1) В реляционной алгебре (РА) есть проекция. Из-за нее количество типов, которыми оперирует РА, бесконечно. В статически типизированном языке любая попытка сгенерировать типы для работы с данными обречена на провал. _>Ой, а где же у нас задаётся проекция? Случаем не внутри того же самого статического языка? А почему мы тогда не забыли задать проекцию, но забыли задать соответствующий ей тип? )))
Чего?
_>Ну и если говорить об автоматизации этого (чтобы не писать дважды), то и генерация проекции по типу и генерация типа по проекции делаются элементарно в статических языках с базовыми возможностями метапрограммирования и в любых динамических языках.
Про динамические языки речи нет. А "возможности метапрограммирования" в 90% случаев и означает цитирование кода, о котором я ниже писал.
G>>2) Можно генерировать типы ad-hoc, это делается в небольшом количестве языков на сегодня. _>Только это вообще не нужно для данной задачи.
Да ладно?
Есть таблица t а одной колонкой типа a, какой тип будет у проекции таблицы t, состоящей из (a,a,a,a,a,a,a,a,a,a,a,a,a,a,a,a,a...) ? Количество колонок может быть любое и не ограничено сверху разумными пределами.
G>>3) Нужно уметь в языке представлять операции РА и выражения над элементами кортежей. Если мы работаем с типами языка, то и выражения должны быть выражениями языка, а не dsl. По сути для полноценной реализации нужно цитирование. _>Задавать в коде деревья выражений, которые потом будут интерпретироваться в рантайме умеют во множестве языков с незапамятных времён.
Назови хотя бы три из них. Чтобы статически типизированные что чтобы "деревья выражений" задавались тем же кодом что и сам язык без дополнительных приседаний.
_>Причём для этого в языке совершенно не требуется наличия той рефлексия-подобной штуки, которую подразумевал тут ты.
Рефлексия в каком-то виде все равно будет. Ты же не сможешь проверить корректность дерева выражения относительно sql если не имеешь в дереве выражений информацию о типе.
G>>4) Посчитаем мейнстрим-языки, которые умеют цитирование и ad-hoc типы. Я знаю C# и F# (он мейнстримый с натяжкой), оба умеют Linq. _>Тут подходят любые статические языки, имеющие элементы метапрограммирования, плюс большинство динамических языков. Т.е. в реальности выбор очень большой.
Да-да, назови хотя бы парочку (динамические не интересуют), ну чтобы можно было написать типа такого:
from x in t
where t.Category.Priority==1
select {
StartDate = x.StartDate.Date,
EndDate = x.StartDate.Date + x.Duration / 24
}
Тут и проекция, и соединение, и выражения над элементами кортежа. И вообще говоря t не обязан быть ссылкой на таблицу, а может быть запросом.
Работа этого кода опирается на возможность цитирования и ad-hoc типы.
Покажи аналог на другом языке без ad-hoc типов или цитирования без потери типизированности или выразительности.
G>>5) А что если не генерировать типы и не использовать цитирование? Тогда мы получаем тяжеловесные ORM со всеми их недостатками, которые уже не раз написали в этой теме. _>Всякие делают. И тяжеловесные, которые при этом удобно задают какие-то часто употребимые шаблоны работы в ущерб производительности. И быстрые (поэффективнее всяких там Linq, т.к. не требуют прогулок рефлексией по дереву), но при этом с близким к SQL синтаксисом (что для реальных задач не всегда удобно). Есть решения на любой вкус.
Про тяжеловесные не надо расказывать. Они — раковая опухоль всей индустрии последние 20 лет. Я уверен что нет других "паттернов" или "технологий" кроме ORM, которые потратили впуствую столько человеческого времени и машинных ресурсов. Помоему в майнинке крипты больше смысла, чем в использовании тяжеловесных ORM. А легковесные orm это не orm, а мапперы рекордсетов на объекты. Но они решают только одну проблему из многих при работе с данными. Причем не самую важную.
_>Правда не очень понятно зачем ты вообще об этом заговорил, т.к. все эти решения занимаются грубо говоря трансляцией кода некого языка в sql запрос, в то время как vdimas вроде как говорил о выкидывание самого sql из этой схемы. Правда я не очень вникал что он предложил на замену, но в любом случае все эти ORM и подобные им решения в таком случае будут не у дел.
Да, заметно что ты не вникал и мозг не включал.
Давай по порядку:
1) Чтобы выкинуть sql надо договориться о формате передачи запросов.
2) Вряд ли vdimas хочет чтобы он был текстовым, иначе вряд ли бы он этот разговор вообще затеял.
3) На стороне языка должно быть средство генерации запроса в бинарном виде, желательно на основе типов и выражений самого языка.
То есть для того кто пользуется orm или linq мало что изменится, но типа как "повысится эффективность".
Но эффективность по факту упирается не в текстовый SQL, а в средства языка по формулированию сложных запросов к базе и скорость дисков.
G>>В итоге остается создать только новый язык, который будет лучше C# (в чем? сколько это будет стоить?). А потом продавить производителей СУБД чтобы они новый формат поддержали. Но тут проблема. _>На самом деле как раз производителям СУБД это сделать довольно просто. Тут больше проблема в миллионах "пользователей", знающих только SQL (и там не только программисты, но и админы, аналитики и ещё много кто) и вряд ли желающих переучиваться на что-то иное даже ради некого повышения эффективности работы БД.
Просто сделать что? Добавить еще один формат запросов? А зачем? Кому он нужен? Каким образом он добавит эффективности?
Понимаешь что амортизированная стоимость парсинга текстового запроса равна нулю?
G>>С точки зрения производителей БД: G>>6) Текстовый язык запросов на два порядка легче расширять, чем бинарный. G>>7) Используя SQL можно получить больше пользователей, чем любой другой язык запросов. Многие нереляционные субд используют sql-подобный язык. G>>8) Выгоды от использования нетекстового языка запросов — никакой. Парсинг запроса даже в 10кб текста занимает бесконечно малое время по сравнением со временем построения плана. А потом все движки этот план кешируют и повторно текст запроса даже не парсят.
_>Вроде про нетекстовый язык тут особо не говорили. Хотя могу тебе тут напомнить про BSON (бинарный JSON), используемый в MongoDB — можешь посмотреть на мотивы его появления.
BSON появился потому что внутри монги хранить в JSON накладно. РСУБД такой чушью не занимаются.
_>Но это отдельная тема для разговора, не имеющая особого отношения к утверждению об убогости SQL (его текстовость явно не входит даже в первую десятку минусов языка).
В целом, кроме некоторых аспектов синтаксиса, sql довольно хороший язык. А протокол взаимодействия программы с базой на основе генерации sql запросов — довольно хороший способ работы.
_>Только после всего этого "не взрослые" nosql движки почему-то не пропали с горизонта, а продолжают вполне себе успешно теснить старые решения. Да, не во всех областях и возможно не такими мощными темпами, как во времена хайпа, но процесс вполне себе продолжается...
Да никто никого не теснил. А количество вакансий с указанием mongodb падает уже не первый год. NoSQL изначально были нишевыми продуктами\технологиями, а теперь их активно теснят РСУБД, которые научились фишкам NoSQL.
Здравствуйте, 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>
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>
В "более функциональном" языке можно было с более простым синтаксисом лямбды сделать...
Только причём тут любой из мейнстримовых языков?
Обсуждаемое давно есть в не-мейнстримовых специализированных языках в достатке.
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-х частей часто разные.
Никакой проверки на правильность "состыковки" схем данных при передаче от уровня к уровню нет.
Все несостыковки вылазят уже в рантайм.
Сие убого донельзя.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
_>>>Ну и если говорить об автоматизации этого (чтобы не писать дважды), то и генерация проекции по типу и генерация типа по проекции делаются элементарно в статических языках с базовыми возможностями метапрограммирования и в любых динамических языках. G>>Про динамические языки речи нет. А "возможности метапрограммирования" в 90% случаев и означает цитирование кода V>В 100% случаев "возможности метапрограммирования" в статических языках используются для другого — для compile-time выбора специфической реализации для специфических типов. Такое "вычисление" порой само является достаточно сложной программой, но её нет в бинарнике.
Это только в одном языке
G>>Есть таблица t а одной колонкой типа a, какой тип будет у проекции таблицы t, состоящей из (a,a,a,a,a,a,a,a,a,a,a,a,a,a,a,a,a...) ? Количество колонок может быть любое и не ограничено сверху разумными пределами. V>Для конкретной компиллируемой программы выводимый тип кортежа всегда известен.
Ага, выпиши его на Java например.
_>>>Задавать в коде деревья выражений, которые потом будут интерпретироваться в рантайме умеют во множестве языков с незапамятных времён. G>>Назови хотя бы три из них. Чтобы статически типизированные что чтобы "деревья выражений" задавались тем же кодом что и сам язык без дополнительных приседаний.
V>Любой МЛ-подобный язык, типа того же Хаскеля. V>И вообще любой язык с реализованными в нём замыканиями. V>Только и это не обязательная фишка, а лишь бонусная к удобству, можно и без замыканий.
Ок, покажи пример.
Нам же не надо генерировать sql на выходе. Достаточно в системе типов языка описать выражения РА или SQL.
Например как на любом предложенном тобой языке будет выглядеть аналог следующего кода:
select t.x, (select sum (tt.x) from t tt where tt.x <> (t.x+1))
from t
_>>>Причём для этого в языке совершенно не требуется наличия той рефлексия-подобной штуки, которую подразумевал тут ты. G>>Рефлексия в каком-то виде все равно будет. V>Разве что в compile-time. V>В бинарнике типы стираются.
А зачем? Чтобы себе же усложнить жизнь при генерации запроса в базу?
Или ты реально думаешь что все запросы в программе будут статичными, а не генерироваться на основе входных параметров?
G>>Ты же не сможешь проверить корректность дерева выражения относительно sql если не имеешь в дереве выражений информацию о типе. V>В рантайм этого и не требуется, если компилятор обеспечивает строгую статическую типизацию.
Ты походу не очень понимаешь о чем пишешь.
Что будет на выходе компилятора? Готовый 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>>
Уверен? Как выражение x.StartDate.Date + x.Duration / 24 превратится в часть запроса? Какие типы будут у t, x и его свойств, возвращаемого значения?
V>Гуглить "named tuple", это довольно популярное игрище. V>https://github.com/duckie/named_types/tree/master/test V>http://vitiy.info/named-tuple-for-cplusplus/ V>В "более функциональном" языке можно было с более простым синтаксисом лямбды сделать...
Это как бы в теории
V>Только причём тут любой из мейнстримовых языков?
Потому что для не-мейнстримного языка это никакого смысла не имеет.
V>Обсуждаемое давно есть в не-мейнстримовых специализированных языках в достатке.
Ага, но к теме разговора не относится. Ты же собрался что-то поменять во взаимодействии программы и базы, а для немейнстримных языков никто ничего подобного делать не будет.
G>>Работа этого кода опирается на возможность цитирования и ad-hoc типы. V>На костыли оно опирается. V>Ср-вами самого языка не реализуемо, поэтому приходится добавлять в язык "специальные конструкции".
Это и есть средства самого языка. Не нужно ни препроцессоров, ни пост-обработки.
G>>Покажи аналог на другом языке без ad-hoc типов или цитирования без потери типизированности или выразительности. V>Можно и без ad-hoc типов, объявив тип результата заранее.
Прости кто должен объявлять? Предлагаешь под каждую возможную проекцию в программе руками выписывать типы? Как раз необходимость этого и мешает делать нормальный код работы с данными.
Именно поэтому и есть ad-hoc типы.
V>Сейчас всё чаще обмениваются сообщениями известного типа и ORM не нужен.
Кто с кем обменивается?
G>>А легковесные orm это не orm, а мапперы рекордсетов на объекты. V>Рекордсеты — это динамическая хрень. V>Любой маппинг из него тоже динамический. V>Смысл это вообще обсуждать в этом топике?
Почему же динамический? Ты же тип знаешь, вот и генерируй маппер в compile-time. Но это маленькая проблема.
_>>>Правда не очень понятно зачем ты вообще об этом заговорил, т.к. все эти решения занимаются грубо говоря трансляцией кода некого языка в sql запрос, в то время как vdimas вроде как говорил о выкидывание самого sql из этой схемы. Правда я не очень вникал что он предложил на замену, но в любом случае все эти ORM и подобные им решения в таком случае будут не у дел. G>>Да, заметно что ты не вникал и мозг не включал. G>>Давай по порядку: G>>1) Чтобы выкинуть sql надо договориться о формате передачи запросов. V>Ты проблему пока не озвучил.
Проблемы как раз нет. Я озвучиваю почему нет смысла менять SQL на какой-либо другой формат взаимодействия с базой.
G>>2) Вряд ли vdimas хочет чтобы он был текстовым, иначе вряд ли бы он этот разговор вообще затеял. V> V>Текстовое представление работает замечательно, оно скармливается компилятору, как скармливаются IDL, protobuf или просто h-файлы. V>Бывают и не текстовые представления, типа typelib.
Ты о чем? Что компилятор языка может сделать с текстовым или любым другим запросом к базе? Даже если ты знаешь структуру, то все равно ты ничего не знаешь об оптимальном плане в compile time.
V>Только какаяя нафик разница — текстовое будет описание или не текстовое? V>Ключевое тут в автоматизации распространения описания типов м/у частями системы. V>А в каком именно виде — дело десятое.
Так ты или трусы надень, или крестик сними. Сам выше писал что это не проблема. А оказывается это ключевое и этого почти нигде нет.
G>>желательно на основе типов и выражений самого языка. V>Это и есть "просто программа", остальное — забота компилятора.
Ты как-то в "остальное" списал очень важные вещи, которые компилятор физически не сможет сделать.
G>>Но эффективность по факту упирается не в текстовый SQL, а в средства языка по формулированию сложных запросов к базе и скорость дисков.
V>Эффективность сегодня упирается в динамическое построение вариантов планов запросов и оценку их эффективности. V>Само представление планов запросов динамическое, оценивающий код сверху плана интерпретирующий, схема слишком тормозная и слишком прожорливая к памяти.
Предположим РСУБ научились генерировать нативный код вместо интерпретируемого плана. Что изменится? Ты все еще веришь, что его можно будет в compile-time сгененировать?
G>>Добавить еще один формат запросов? А зачем? Кому он нужен? Каким образом он добавит эффективности?
V>В типизированной системе "формат" каждого запроса уникален. V>Это просто некое типизированное сообщение, PDU.
Этот "тип" будет эквивалентен бинарному представлению набора реляционных операций. По сути ничем не лучше текстового представления.
G>>Понимаешь что амортизированная стоимость парсинга текстового запроса равна нулю? V>И? На выходе всё равно получается его AST, которое необходимо интерпретировать в рантайм и это всё жутко тормозит.
А ты что предлагаешь? Делать готовый план на стороне программы? Информации для этого мало.
Или передавать AST из программы в базу? Тогда в чем выгода?
G>>А протокол взаимодействия программы с базой на основе генерации sql запросов — довольно хороший способ работы.
V>Часть прикладного кода живёт в самой БД, часть в сервере приложений, часть на клиенте. V>Языки реализации всех 3-х частей часто разные. V>Никакой проверки на правильность "состыковки" схем данных при передаче от уровня к уровню нет. V>Все несостыковки вылазят уже в рантайм. V>Сие убого донельзя.
По такой логике любой специализированный язык убог, а по факту именно за счет убогости (недостаточной выразительности) языков общего назначения существуют типизированные языки.
Никто же не мешал в свое время вместо SQL использовать например фортран. Вот только операций со множествами в нем нет и код работы с данными на фортране был бы крайне убог. Поэтому SQL придумали.
Оказывается что довольно непросто придумать язык, который одинаково хорошо описывает и реляционную алгебру, и UI, и логику взаимодействия множества клиентов.
Возможно мы упираемся в теорему о неполноте.
Re[29]: В России опять напишут новый объектно-ориентированны
Здравствуйте, IB, Вы писали:
V>>Я не сказал, что это «проблема», я просто констатирую факт – с тобой общаются не охотно. IB>То что ты в фактах путаешься уже давно понятно
Пока что понятно лишь, что ты предпочитаешь уходить от темы вопроса одним и тем же способом. ))
IB>но твое трогательное внимание к моей персоне по прежнему забавляет =)
А я здесь при чём?
Кое-кто скатился на обсуждение профессионализма собеседника (даже не скатился, а прямо с этого зашёл), но встречные пассажи его "забавляют".
V>> До тех пор, пока тебя это не беспокоит, это не является для тебя проблемой, разумеется. IB>Но очевидно это беспокоит тебя!
Меня беспокоит инфатильность некоторых коллег, живущих по принципу "а нас-то за что".
В смысле, беспокоит, когда они свою инфатильность на меня вываливают.
V>>Ровно в том же смысле не равнодушен, как и к нескольким сотням других коллег с этого сайта. IB>У тебя накоплено несколько сотен описаний биографии и профессиональной квалификации коллег с этого сайта?! Эту бы энергию да в мирных целях...
Само копится за десятки лет.
А у тебя каждый новый день жизни как всё сначала, что ле?
По работе тоже через некоторое время всё заново учить приходится? ))
V>>Не сочинил, мы с тобой уже общались несколько раз и все разы неудачно. IB>С твоим апломбом это не удивительно..
С твоим хамством, давай называть вещи своими именами.
Дважды я твои странные выбрыки игнорил в прошлые разы.
Просто эта... у меня есть правило "третьего раза", я решил соблюсти.
V>>Но когда чел руинит спор, пресекая малейшие попытки обмена аргументами (причём, чаще не специально, а на твой манер — как слон в посудной лавке, что еще больше бесит, бо чел не видит себя со стороны), да еще если сам оказывается не прав технически (твои "невозможно знать заранее"), плюс еще ошибка детская – это всё составляет эпик фейл, аднака. IB>Вот сейчас ты очень верно себя описал. =)
Все ходы записаны.
Да и как-то странно выглядит, если я должен объяснять взрослому дяде, что его "дружеские советы" пойти "почитать хоть что-нибудь" являются нарушением правил форума, не? Не странно? ))
Оно-то понятно, что ему никогда не приходило в голову, что это и есть запрещённый правилами проход по квалификации коллеги.
И, разумеется, он даже и подумать не мог, что подобные проходы одновременно являются переходом на личность.
Да не, бывает, чо! ))
IB>Вот ты капец смешной. Боюсь, что это не лечится...
И опять много на себя берешь.
"Лечится".
Следующей стадией будут "трава, отсыпь", "наркотики" или что-то в этом роде.
А я просто показываю тебе твою "способность" объктивно себя оценивать — и как человека и как профессионала.
Всё, что ты сам о себе думаешь — недостоверно.
Средний человек считает себя в 6 раз умнее, мудрее, добрее, красивее и т.д. чем он есть на самом деле.
Но это средний. У некоторых это число за десятку переваливает сходу, как я посмотрю.
Вдвойне инфатильность, положа руку на.
Вот ты бы мог сформулировать, чего ты вообще влез в обсуждение, если по технической части тебе нечего было сказать?
Типа, "разогнать всех нафик, чтобы ерунду не обсуждали"? ))
Сам-то хоть свои мотивы осознаешь или как?
А дальше? Зачем ты мне третий раз отвечаешь на откровенно ненужные темы?
Ты, скажем прямо, "тепличное растение", судя по твоим реакциям.
Это типа, специально решил "поупражняться"? )))
Но здесь ваша же территория, модераторская.
Поэтому, даже в этом плане профанация.
В реальной жизни в похожем обсуждении, если брать и по технической части и по твоим манерам насчёт диагнозов коллегам — давно бы раскатали в блин. А своими реакциями ты лишь даёшь понять, будто тебе ПОЗВОЛЕНО в твоей работе ставить коллегам диагнозы.
И вот ты такой передо мной полный недоумения — а почему здесь на форуме-то нельзя?
(ну а какие еще могут быть причины подобной "тепличности", ы?)
V>> Всю эту шелуху тоже можно убрать нафик из таблиц (убрать сами таблицы), тупо инлайня код с их участием. IB>Нельзя. Взгляни на проблему шире — приложение может быть и не одно, а база та же и данные те же. Так что нет, нельзя всосать часть данных в код и сказать, что так и было.
Вот если бы речь шла об этом сначала — мне бы было что подробно ответить.
Например то, в С++ адреса глобальных переменных являются константами времени компиляции.
Эти константы можно даже использовать в виде целочисленных параметров шаблонов.
Т.е. вот такой фокус — само значение константы становится известным уже ПОСЛЕ компиляции, а на момент компиляции достаточно знать, что это "некоторое уникальное значение".
Я мог бы и по подробней по каждому аспекту, бо давно и плотно "в теме", но, сам понимаешь, особого желания обмениваться мнениями именно с тобой уже нет. Мне уже было просто интересно посмотреть — насколько глубоко ты можешь зайти в "штопор"?
Ну что сказать — глубоковато. И при этом сходу.
НизачОт...
(когда кто-то руинит спор, я позволяю себе тупо развлекаться, бо реакции людей мне интересны, ХЗ почему)
Здравствуйте, gandjustas, Вы писали:
V>>В 100% случаев "возможности метапрограммирования" в статических языках используются для другого — для compile-time выбора специфической реализации для специфических типов. Такое "вычисление" порой само является достаточно сложной программой, но её нет в бинарнике. G>Это только в одном языке
Ключевое выделил.
Таких языков в достатке, помимо того языка, о котором ты подумал и про который забыл — D.
Любой функциональный с системой типов не слабее чем у Хаскеля — туда же.
Информация о типах в рантайме стирается, поэтому, в распоряжении лишь система типов времени компиляции.
(информация к размышлению: в С++ и в Хаскеле прямо сейчас вовсю работают над метаинформацией времени компиляции)
V>>Для конкретной компиллируемой программы выводимый тип кортежа всегда известен. G>Ага, выпиши его на Java например.
А почему не Скала с её case-classes?
Тем более, что предлагалось пофантазировать насчёт того, каким этот гипотетический язык мог быть и как повлияли бы его фичи на сценарии вокруг работы с данными.
V>>И вообще любой язык с реализованными в нём замыканиями. V>>Только и это не обязательная фишка, а лишь бонусная к удобству, можно и без замыканий. G>Ок, покажи пример.
G>Нам же не надо генерировать sql на выходе. Достаточно в системе типов языка описать выражения РА или SQL.
Ну вот, уже сам спрашиваешь, сам правильно отвечаешь. ))
G>Например как на любом предложенном тобой языке будет выглядеть аналог следующего кода: G>
G>select t.x, (select sum (tt.x) from t tt where tt.x <> (t.x+1))
G>from t
G>
Да как угодно вплоть до того же, что так же — это в терминах РИ.
Или можно расписать в терминах РА на каком-нить ML-подобном слегка допиленном языке:
Data Result t {X:t.x, Y:t.x};
MyCoolQuery t :: [t -> x] -> [Result]
MyCoolQuery t = do {
tt_row t x = fold sum $ filter (r -> r.x /= x+1) t;
t_row t x = Result t {x, tt_row t x};
return $ map t (x -> t_row t x);
}
Какие-то вещи удобней расписывать в РИ, какие-то в РА.
Ожидаемо, что в случае перекрёстных параметров м/у ровнями вложенности удобней РИ (и то не всегда).
В любом случае для компилятора эти представления выглядят тождественно, он в любом случае внутри оперирует системой уравнений РА при построении планов запроса.
Но!
В случае РА можно говорить о привычном библиотечном подходе, т.е. для своей системы можно определить прикладные "кубики" и собирать запросы из них. В то время как РИ будет прибито гвоздями к конкретным таблицам.
Обрати внимание, что в моём варианте на РА используется параметрический полиморфизм.
Т.е. мало того, что в "библиотечные" запросы можно подавать таблицы, подходящие по типу, но сам тип таблицы и типы её полей могут быть "генериком".
_>>>>Причём для этого в языке совершенно не требуется наличия той рефлексия-подобной штуки, которую подразумевал тут ты. G>>>Рефлексия в каком-то виде все равно будет. V>>Разве что в compile-time. V>>В бинарнике типы стираются. G>А зачем? Чтобы себе же усложнить жизнь при генерации запроса в базу?
Вооот.
Это почему я поставил сплошные руки-лица в ответ на первое твоё сообщение в этой ветке.
Тебе удалось довольно-таки хорошо раскрыть некий вариант устройства подобной системы, как и самостоятельно увидеть отсутствие бенефитов такого варианта. Получилось эдакое самообслуживание — мне даже отвечать не надо было, ты и сам с собой неплохо пообщался. ))
Фишка предлагаемого мною в том, что вот этот компилятор над описанным выражением — это и есть СУБД.
Т.е. этот язык компиллируется там же, где и современный SQL, разве что не в динамике, а в статике.
Т.е. никаких других "запросов" к базе, кроме вот этого исходника типизированного кода, нет.
На выходе бинарь, который работает в процессе СУБД.
Прикладная часть бинаря общается примерно с тем же слоем низлежащего движка СУБД, с которым общается "исполнитель запросов" в нынешнем традиционном варианте.
G>Или ты реально думаешь что все запросы в программе будут статичными, а не генерироваться на основе входных параметров?
Ну, если запретить рекурсию с неизвестной вложенностью при составлении запроса из "кубиков", то компилятор выведет всё мн-во запросов над конкретными таблицами.
В случае же простого комбинирования "кубиков" — тем более.
Т.е. достаточно, чтобы рекурсия/цикл процедуры генерации запроса были с известным на момент компиляции кол-вом повторений — и можно генерить запросы весьма развесисто — пофик. Я гонял современный С++, задавал ему развесистую рекурсию при выведении типа из шаблона с глубиной в несколько тысяч уровней — аппетитно ест и даже причмокивает. "На ноутбуке с батарейкой". (С)
Таблицы базы могут быть представлены некими "ниспосланными свыше" глобальными переменными программы (объявлены как глобальные переменные).
Вот от этих глобальных таблиц и пляшем, подставляя их в свои "запросы" — а на самом деле просто в некий код, где тебе не надо будет сильно отличать обычный код над списками/хеш-таблицами в оперативке или в БД. И одни и те же запросы, разумеется, будут работать как над переменными в памяти, так и над данными на диске, бо параметрический полиморфизм "унутре" почти всегда превращается в ad-hoc в процессе бета-редукции. "Одни и те же" в смысле только лишь исходного кода, разумеется.
Еще соображения.
На стороне СУБД очень мало функциональности.
Т.е. много таблиц, много запросов, много хранимок, но уникальной функциональности кот наплакал. Для обычного современного мейнстримового языка — просто тьфу. Так вот, хороший язык должен позволять быстро убегать от дублирования кода, т.е. должен в разы удешевлять разработку и поддержку.
G>>>Ты же не сможешь проверить корректность дерева выражения относительно sql если не имеешь в дереве выражений информацию о типе. V>>В рантайм этого и не требуется, если компилятор обеспечивает строгую статическую типизацию. G>Ты походу не очень понимаешь о чем пишешь. G>Что будет на выходе компилятора?
На выходе компилятора будет готовое упорядоченное мн-во планов запросов и готовый оптимизированный код оценки каждого плана.
Тут рядом я несколько раз выскзывался в сообщениях, что сами планы запросов можно хранить весьма компактно — это же просто дерево перебора вариантов, где многие перебираемые ветки/листья дерева будут идентичными у многих запросов. Более того, это дерево можно хранить не в виде данных а в виде рекурсивных процедур обхода. Обход там нужен исключительно и только чтобы грубо прикинуть оценку стоимости запроса по каждому из плану и выбрать лучший из них (или достаточно хороший).
Там еще мелочей хватает, я уже рядом расписывал и вообще, тут интересней, ИМХО, вообразить самим. ))
G>Готовый SQL или любой аналог?
Вот то, что мы писали — это и есть наш "новый SQL", т.е. его аналог.
Просто хотелось убежать от динамики и многословности.
Далее.
Для клиента такой СУБД проектируется некий публичный интерфейс (отмечаем нужное извне как public), и после компиляции получается артефакт —
некая библиотека типов. В виде текстового IDL или какого-нить бинарного формата, типа Typelib.
Далее из этой библиотеки типов можно сгенерить готовую для линковку клиентскую библиотеку, которая будет брать транспортные вопросы на себя, т.е. будет брать на себя ф-ии DAL целиком. Итого, простор для ошибок несогласованности клиента и сервера уменьшается.
G>Если у тебя запрос генерируется на основе входных параметров, то что?
... то компилятор "видит" как такой запрос генерируется.
Или ты говоришь о простом параметре-константе в каком-нить предикате (навроде select * from users where id = concrete_id)?
Этот сценарий даже обсуждать облом, тут всё ясно.
А вот первый вариант может даже дать некий комбинаторный взрыв, угу.
Предлагаю его оценить по реальным своим проектам.
Я оценивал — фигня полная.
Ну, т.е. лишнего бинарного кода будет сегерён с гулькин нос по нынешним меркам (5-6 мег на все "взрывы", где самих "врывов" даже в большой системе весьма счётное кол-во — единицы/десятки, остальное всё прекрасно обходится без взрывов, чиста через параметры хранимок).
V>>В современном С++ можно что-то типа такого:
... G>Уверен? Как выражение x.StartDate.Date + x.Duration / 24 превратится в часть запроса?
Превратится на этапе компиляции из некоего своего AST.
Лямбда — это ж полноправная единица языка, что не так?
G>Какие типы будут у t, x и его свойств, возвращаемого значения?
Я переводил твой пример. А у тебя t задаётся "где-то еще".
Остальные типы просто выводятся современным С++.
Почему в теории? В том же Хаскеле синтаксис лямбды весьма лаконичен.
Но даже и этот синтаксис можно упростить до (ты правильно говорил) простого цитирования.
Просто я возражал насчёт прям-таки обязательности наличия цитирования.
В моём примере выше можно заменить лямбды на ф-ии и всё останется работоспособным, просто будет менее удобным.
Честно говоря — и тот код неудобен, можно было поинересней нарисовать.
Просто не хотелось сходу гнать совсем уж отсебятину, лучше двигаться поэтапно — смотреть что уже есть, чего не хватает, что мешает и почему.
В общем, обсуждаемое тут — это в том числе вопросы удобства "нового SQL" в сравнении чем-то нынешним.
А раз так, то нельзя "запрещать" мне желать любые теоретически-возможные вкусняшки.
Здравствуйте, gandjustas, Вы писали: G>>>1) В реляционной алгебре (РА) есть проекция. Из-за нее количество типов, которыми оперирует РА, бесконечно. В статически типизированном языке любая попытка сгенерировать типы для работы с данными обречена на провал. _>>Ой, а где же у нас задаётся проекция? Случаем не внутри того же самого статического языка? А почему мы тогда не забыли задать проекцию, но забыли задать соответствующий ей тип? ))) G>Чего?
У тебя все проекции задаются в том же приложение, в котором требуются типы. И их множество очевидно конечное. Так что ты без проблем можешь завести нужное количество тебе типов, параллельно с введение в приложение соответствующих проекций.
И кстати в простейшем случае для того даже метапрограммирования не требуется — можно просто ручками, так что наверное подойдёт даже какой-нибудь Фортран.
Ну а для реальной удобной работы конечно же требуется какое-то средство автоматизации, чтобы не не указывать одну и ту же информацию дважды. Это могут быть средства внутреннего МП или вообще внешний препроцессор и т.п., конвертирующие описание проекции в соответствующие типы или наоборот. _>>Ну и если говорить об автоматизации этого (чтобы не писать дважды), то и генерация проекции по типу и генерация типа по проекции делаются элементарно в статических языках с базовыми возможностями метапрограммирования и в любых динамических языках. G>Про динамические языки речи нет. А "возможности метапрограммирования" в 90% случаев и означает цитирование кода, о котором я ниже писал.
"Про динамические языки речи нет", а они тем временем только наступают во всех этих прикладных областях... Ну да ладно, сейчас мы не об этом.
Ну и если ты называешь подобные генерации типа по выражению "цитированием", то значит это самое цитирование доступно в очень многих языках... ))) G>>>2) Можно генерировать типы ad-hoc, это делается в небольшом количестве языков на сегодня. _>>Только это вообще не нужно для данной задачи. G>Да ладно? G>Есть таблица t а одной колонкой типа a, какой тип будет у проекции таблицы t, состоящей из (a,a,a,a,a,a,a,a,a,a,a,a,a,a,a,a,a...) ? Количество колонок может быть любое и не ограничено сверху разумными пределами.
Ну такой и будет, в чём проблема? ) Хотя да, вспомнил, в .net же ввели какие-то кастрированные кортежи, которые позволяют максимум 8 элементов. Но я тебя уверяю, что это скорее исключение из правил и во всех остальных языках (если уж там есть кортежи), таких глупостей не наблюдается.
Хотя вообще это дурная практика и лучше иметь нормально именованные столбцы и соответственно представлять строку таблицы нормальной структурой с именованными полями — тогда автодополнение в IDE будет существенно помогать в работе. G>>>3) Нужно уметь в языке представлять операции РА и выражения над элементами кортежей. Если мы работаем с типами языка, то и выражения должны быть выражениями языка, а не dsl. По сути для полноценной реализации нужно цитирование. _>>Задавать в коде деревья выражений, которые потом будут интерпретироваться в рантайме умеют во множестве языков с незапамятных времён. G>Назови хотя бы три из них. Чтобы статически типизированные что чтобы "деревья выражений" задавались тем же кодом что и сам язык без дополнительных приседаний.
Ты похоже вообще не понимаешь о чём речь. Смотри, когда мы говорим о дереве выражений, мы же имеем в такого типа задачу:
auto tree=(a+b+c)*a;
tree.print(); //печатает: (a+b+c)*a
не так ли? Так вот для возможности работы такого кода на C++ достаточно всего лишь вот такой детской реализации:
причём заметь, что тут нет никакой специфической C++ магии, типа метапрограммирования на шаблонах (а вот если бы мы её использовали, то функция print могла бы выводить сформированную на этапе компиляции строку, вместо обхода дерева в рантайме) — подобный элементарный код доступен во множестве языков программирования. _>>Причём для этого в языке совершенно не требуется наличия той рефлексия-подобной штуки, которую подразумевал тут ты. G>Рефлексия в каком-то виде все равно будет. Ты же не сможешь проверить корректность дерева выражения относительно sql если не имеешь в дереве выражений информацию о типе.
Ээээ, что? ) Проверка корректности происходит на этапе компиляции, а не в рантайме. И если синтаксис будет не корректный, то компилятор просто пошлёт тебя. G>>>4) Посчитаем мейнстрим-языки, которые умеют цитирование и ad-hoc типы. Я знаю C# и F# (он мейнстримый с натяжкой), оба умеют Linq. _>>Тут подходят любые статические языки, имеющие элементы метапрограммирования, плюс большинство динамических языков. Т.е. в реальности выбор очень большой. 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>
G>Тут и проекция, и соединение, и выражения над элементами кортежа. И вообще говоря t не обязан быть ссылкой на таблицу, а может быть запросом. G>Работа этого кода опирается на возможность цитирования и ad-hoc типы. G>Покажи аналог на другом языке без ad-hoc типов или цитирования без потери типизированности или выразительности.
Эм, я в этих ваших странных синтаксисах не разбираюсь, так что боюсь что-то не то показать (к примеру мне совершенно не очевидно где там соединение и т.п.). Ты мне покажи sql запись данного запроса и я тебе продемонстрирую её статически типизированный вариант и укажу языки на которых это доступно. _>>Всякие делают. И тяжеловесные, которые при этом удобно задают какие-то часто употребимые шаблоны работы в ущерб производительности. И быстрые (поэффективнее всяких там Linq, т.к. не требуют прогулок рефлексией по дереву), но при этом с близким к SQL синтаксисом (что для реальных задач не всегда удобно). Есть решения на любой вкус. G>Про тяжеловесные не надо расказывать. Они — раковая опухоль всей индустрии последние 20 лет. Я уверен что нет других "паттернов" или "технологий" кроме ORM, которые потратили впуствую столько человеческого времени и машинных ресурсов. Помоему в майнинке крипты больше смысла, чем в использовании тяжеловесных ORM. А легковесные orm это не orm, а мапперы рекордсетов на объекты. Но они решают только одну проблему из многих при работе с данными. Причем не самую важную.
Кстати, сам факт появления разных ORM (и особенно легковесных) как раз говорит о том, что с SQL что-то серьёзно не то. G>Давай по порядку: G>1) Чтобы выкинуть sql надо договориться о формате передачи запросов.
Да. G>2) Вряд ли vdimas хочет чтобы он был текстовым, иначе вряд ли бы он этот разговор вообще затеял.
Что-то не видел упоминаний этого. Хотя бинарный формат в целом конечно же лучше для критических к производительности мест, но насколько я понял в данной дискуссии речь вообще не об этом. G>3) На стороне языка должно быть средство генерации запроса в бинарном виде, желательно на основе типов и выражений самого языка. G>То есть для того кто пользуется orm или linq мало что изменится, но типа как "повысится эффективность". G>Но эффективность по факту упирается не в текстовый SQL, а в средства языка по формулированию сложных запросов к базе и скорость дисков.
Ну во-первых возможно что с новым языком появятся и новые возможности, так что все эти ORM можно будет существенно улучшить. А во-вторых да, всё упирается сейчас в убогость SQL. Только это убогость не в текстовости, а в самом его устройстве. _>>Но это отдельная тема для разговора, не имеющая особого отношения к утверждению об убогости SQL (его текстовость явно не входит даже в первую десятку минусов языка). G>В целом, кроме некоторых аспектов синтаксиса, sql довольно хороший язык. А протокол взаимодействия программы с базой на основе генерации sql запросов — довольно хороший способ работы.
О да, ещё тот шедевр. И средства декомпозиции фееричные. А уж как параметры удобно подставлять в тот же "is not null"... Просто мечта, а не язык для автоматической генерации... А уж как хорошо стандарт охватывает все необходимые возможности и как приятно можно запускать один и тот же SQL запрос на СУБД разных производителей — это вообще песня. Хотя о чём это я, какие запросы, если там даже ТИПЫ ДАННЫХ у каждого свои! _>>Только после всего этого "не взрослые" nosql движки почему-то не пропали с горизонта, а продолжают вполне себе успешно теснить старые решения. Да, не во всех областях и возможно не такими мощными темпами, как во времена хайпа, но процесс вполне себе продолжается... G>Да никто никого не теснил. А количество вакансий с указанием mongodb падает уже не первый год. NoSQL изначально были нишевыми продуктами\технологиями, а теперь их активно теснят РСУБД, которые научились фишкам NoSQL.
Угу, особенно они научились таким "встроенным" в nosql базы фишкам, как автоматический шардинг.
Re[30]: В России опять напишут новый объектно-ориентированны
Печаль, ты опять потратил кучу текста в попытках докопаться до меня, при этом те места где тебя ткнули носом в технические факты ты просто затер... Увы, это похоже диагноз.
V>А я здесь при чём?
Больше никто не уделяет такого внимания моей скромной персоне )
V>Кое-кто скатился на обсуждение профессионализма собеседника (даже не скатился, а прямо с этого зашёл)
Зайчика обидели, в норку написали? =)
V> но встречные пассажи его "забавляют".
Конечно, тем более такие неуклюжие
V>Меня беспокоит инфатильность некоторых коллег, живущих по принципу "а нас-то за что".
А ты не беспокойся, в интернете много кто не прав, дыши глубже ))
V>Да и как-то странно выглядит, если я должен объяснять взрослому дяде, что его "дружеские советы" пойти "почитать хоть что-нибудь" являются нарушением правил форума, не? Не странно? ))
Как в итоге показал наш диалог, тебе таки стоило не обижаться на ровном месте, а пойти и почитать. Совет-то, как выяснилось, к месту был.
V>А я просто показываю тебе твою "способность" объктивно себя оценивать — и как человека и как профессионала.
Ты показываешь только свои комплексы, и жаль что ты этого не понимаешь.
V>Средний человек считает себя в 6 раз умнее, мудрее, добрее, красивее и т.д. чем он есть на самом деле.
Вот ты смешной =) Я вообще не претендую, ни на мудрость, ни на добрость, фиг с ней с красотой, и тем более умом — ты опять копаешь там где не надо.
V>Вот ты бы мог сформулировать, чего ты вообще влез в обсуждение, если по технической части тебе нечего было сказать?
Как выяснилось, это тебе нечего сказать по технической части.
V>А дальше? Зачем ты мне третий раз отвечаешь на откровенно ненужные темы?
Ну, во-первых, подразнить тебя было забавно, а во-вторых — я таки заставил тебя расколоться и продемонстрировать, что ты не знаешь как работают современные оптимизаторы.
Собственно, на этом можно закончить. Спасибо за доставленное удовольствие
V>(когда кто-то руинит спор, я позволяю себе тупо развлекаться, бо реакции людей мне интересны, ХЗ почему)
Мужик, принюхайся, ты не в белом, ты в коричневом =)
Мы уже победили, просто это еще не так заметно...
Re[31]: В России опять напишут новый объектно-ориентированны
Здравствуйте, IB, Вы писали:
V>>А дальше? Зачем ты мне третий раз отвечаешь на откровенно ненужные темы? IB>Ну, во-первых, подразнить тебя было забавно, а во-вторых — я таки заставил тебя расколоться и продемонстрировать, что ты не знаешь как работают современные оптимизаторы.
Где и когда?
Мало ли, что ты там себе придумал. ))
Смирись и забей уже.
Ты всё-равно не понял ни слова и спорил лишь сам с собой.
Если ты про это:
Оптимизаторы современных баз давно умеют схлопывать одинаковые запросы с разными константами,
То мне просто облом было отвечать на эту галиматью.
Потому что мне натурально надоело макать тебя мордой в лужу.
Если настаиваешь, то ОК.
Берём банальное nullable поле.
Есть тип с множеством значений T.
Делаем nullable тип с мн-вом T+1.
Казалось бы, появляется всего лишь еще одно значение, которое тоже может быть значением некоей "константы", но фиг там.
В сам язык SQL зашиты весьма странные операции вокруг NULL, и эту ситуацию, когда NULL является "просто константой", надо обыгрывать по-особенному, в т.ч. в арифетических выражениях предикатов или когда значения параметра запроса (особено даты!!!) является NULL.
И нихера там не "слопывается само" аж до сих пор.
И не будет никогда с текущей семантикой NULL в языке SQL.
Да, именно, проблема не в самом NULL (то бишь идиомы optional), проблема сугубо в его кривой семантике в этом кривом языке.
Или вот:
более того, они давно умеют НЕ схлопывать запросы в тех случаях, когда планы для разных констант отличаются.
Тут тоже натурально стошнило от россыпи детских ошибок.
Смысла продолжать нет.
Ты ведь не понял ни слова про "схлопывать запросы", тем более, что речь шла исключительно о схлопывании внутреннего представления планов у разных запросов. Тут сделать паузу и медитировать до просветления. Потом разбежаться и убиться апстену. От жгучего стыда.
Кароч, дословно тебе была расписана следующая схема:
— есть запросы с параметрами или без (некие "уникальные");
— по каждому запросу с параметром или "уникальному" хранится НАБОР планов;
— говорилось о возможности компактного представления в памяти наборов всех (не выкинутых заведомо) планов всех запросов.
Набо-о-ор. Набор! Это такое множество. Их несколько, обычно, планов на запрос-то.
Много таких планов на каждый такой запрос.
Все хранятся.
Потому что не умеют порождаться в рантайм.
Раз, раз, приём, приём, вы еще с нами?
Их все надо породить в compile time и каким-то хитрым образом сохранить.
А раз их все надо хранить, неужели это не означало, что они могут понадобиться?
Ну Семён Семёныч!
Ну разумеется, конкретный план для запроса будет выбран из НАБОРА их в зависимости от:
— значений параметров;
— текущих значений статистики;
— текущего уровня дефрагментации индексов.
То бишь, какая там в опу "другая константа"?
Даже подавая одну и ту же константу в один и тот же запрос в разные времена жизни базы можно наблюдать выбор разных планов для исполнения.
Вот такой ты "специалист", кароч.
Я в шоке...
Хотя нет, вру.
Привык уже после 3-го твоего поста тут.
V>>Средний человек считает себя в 6 раз умнее, мудрее, добрее, красивее и т.д. чем он есть на самом деле. IB>Вот ты смешной =) Я вообще не претендую, ни на мудрость, ни на добрость, фиг с ней с красотой, и тем более умом — ты опять копаешь там где не надо.
Ты претендуешь на право быть интеллектуально снисходительным к коллегам.
Сама такая претензия означает плакат на лбу "я многократно вас умнее", что есть заведомое нахальство, ты ваапще хтооо, дядя??? ))
Ну и отсутствие внутренних нравственных ориентиров лишь усугубляет дело — эта самостимулируемая снисходительность прямым образом трансформируется в еще более грубую (местами вовсе злую) надменность, которую ты за собой явно не замечаешь.
Ты даже не понимаешь что тебе говорят. Например, при чём тут "доброта". ))
Похоже на то, что ты себе видишься и так достаточно добрым.
Ну тут только поржать, значит.
IB>Собственно, на этом можно закончить. Спасибо за доставленное удовольствие
Стрёмные у тебя удовольствия — так подставляться на весь инет.
V>>(когда кто-то руинит спор, я позволяю себе тупо развлекаться, бо реакции людей мне интересны, ХЗ почему) IB>Мужик, принюхайся, ты не в белом, ты в коричневом =)
Ой, блин, опять как от кислого лимона...
Ты даже не оценил (или не догадался) в прошлый раз, что я не стал опять и снова проходится по твоему раненому ЧСВ и очередным детским ошибкам на фоне суровой недогадливости...
Что вместо этого я постарался уже более-менее нейтрально свернуть тему.
Мог бы и подыграть мне...
Хотя не, с такой "догадливостью" — ни одного шанса, ты же не понял происходящее.
Ты видел это всё как-то наизнанку и тебя несло и несло... ))
==============
Ну вот смотри.
Если ты ДЕЙСТВИТЕЛЬНО так был уверен в своём превосходстве, то продолжать "добивать" меня было бы "не спортивно", верно?
Но ты продолжил с новой силой, о чём это говорит? — правильно, душа-то с душком.
Ну и неспособность обозреть всю беседу с высоты птичьего полёта не позволила тебе обнаружить нежелание "добивать" за мной и ты кинулся в спину тому, кто оставил тебя в покое, да еще с усиленной порцией агрессии.
Ну, блин, в реальной жизни за такие мансы моментально вырубают как бешенную собаку...
А кое-где и пристреливают. ))
Здравствуйте, vdimas, Вы писали:
V>Потому что SQL безбожно устарел и вообще в современной разработке является сущностью второго рода — производной генерируемой хренью/абракадаброй.
Безбожно устарел не язык, а некоторые разработчики. Проблема SQL состоит в том, что люди, не знающие ничего о том, как работает СУБД, не представляют сколько всего для них делает их РСУБД и пишут вот такую вот чушь.
Задача SQL — отвязать логику приложения от логики хранения. Если подумать, то другим он не может быть. Это "генерируемая абракадабора" только с точки зрения логики приложения. Если сделать иначе, то ты притащишь всякое доменное говно в логику хранения/обработки данных, она станет завязана на логику приложения и ты будешь вынужден постоянно менять схему/данные, при каждом малейшем чихе.
Ну и у тебя в любом случае будет mismatch между ОО/императивным языком и декларативным SQL, с точки зрения прикладной императивной логики, данные из СУБД берутся волшебным образом, в ответ на какую-то магическую абракадабру, будет она такой как сейчас или немного другой. Ведь логика выборки/обработки данных живет на стороне СУБД и приложение о ней ничего незнает. Если сделать просто тупое хранилище данных/объектов, то придется притащить в него (приложение) планировщик запросов, твое приложение само будет вытаскивать данные и решать, hash join использовать или merge join.
Здравствуйте, chaotic-kotik, Вы писали:
V>>Потому что SQL безбожно устарел и вообще в современной разработке является сущностью второго рода — производной генерируемой хренью/абракадаброй. CK>Безбожно устарел не язык, а некоторые разработчики. Проблема SQL состоит в том, что люди, не знающие ничего о том, как работает СУБД, не представляют сколько всего для них делает их РСУБД и пишут вот такую вот чушь. CK>Задача SQL — отвязать логику приложения от логики хранения. Если подумать, то другим он не может быть. Это "генерируемая абракадабора" только с точки зрения логики приложения. Если сделать иначе, то ты притащишь всякое доменное говно в логику хранения/обработки данных, она станет завязана на логику приложения и ты будешь вынужден постоянно менять схему/данные, при каждом малейшем чихе. CK>Ну и у тебя в любом случае будет mismatch между ОО/императивным языком и декларативным SQL, с точки зрения прикладной императивной логики, данные из СУБД берутся волшебным образом, в ответ на какую-то магическую абракадабру, будет она такой как сейчас или немного другой. Ведь логика выборки/обработки данных живет на стороне СУБД и приложение о ней ничего незнает. Если сделать просто тупое хранилище данных/объектов, то придется притащить в него (приложение) планировщик запросов, твое приложение само будет вытаскивать данные и решать, hash join использовать или merge join.
Интересно, как весь этот твой текст соотносится с фактом более эффективной работы например MongoDB? )))
Здравствуйте, chaotic-kotik, Вы писали:
CK>Задача SQL — отвязать логику приложения от логики хранения.
Изначальная задача SQL была совсем другая.
CK>Если подумать, то другим он не может быть.
Тут неплохо бы аргументы.
Де-факто, SQL был разработан вовсе не для того сценария, каким его используют в 99.99% случаев сегодня.
CK>Это "генерируемая абракадабора" только с точки зрения логики приложения.
"Логика приложения" тут не при чём, SQL сегодня участвует сугубо в транспортном уровне.
CK>Если сделать иначе, то ты притащишь всякое доменное говно в логику хранения/обработки данных
Данные имеют разный характер и отсюда могут (и должны, ИМХО) иметь как разное представление, так и разный "интерфейс" к себе.
CK>она станет завязана на логику приложения
Приличная часть данных в любой учетной системе неразрывно связана с логикой приложения.
CK>и ты будешь вынужден постоянно менять схему/данные, при каждом малейшем чихе.
Это и так постоянно происходит и является источником несогласованности базы и клиента.
Вернее, несогласованность эта сидит в самой базе современных технологий, просто "каждый чих" проявляет сию несогласованность с особой контрастностью. ))
CK>Ну и у тебя в любом случае будет mismatch между ОО/императивным языком и декларативным SQL
Не будет, а есть прямо сейчас.
CK>с точки зрения прикладной императивной логики, данные из СУБД берутся волшебным образом
А при чём тут конкретно SQL?
Ты же сам предлагал выше "немного подумать", ну и где оно?
CK>в ответ на какую-то магическую абракадабру, будет она такой как сейчас или немного другой.
"Немного другим" должен быть транспортный уровень.
CK>Ведь логика выборки/обработки данных живет на стороне СУБД и приложение о ней ничего незнает.
База данных не разрабатывается отдельно от приложения, обрабатывающего эти данные.
CK>Если сделать просто тупое хранилище данных/объектов
Тупое хранилище можно сделать хоть на основе простых dbase-like файлов.
С точки зрения именно хранения это один из самых эффективных форматов до сих пор. ))
CK>то придется притащить в него (приложение) планировщик запросов
Этот планиовщик и так уже "притащен". Предлагалось перенести значительную нагрузку по планированию алгоритмов обращения к данным из динамики в статику.
CK>твое приложение само будет вытаскивать данные и решать, hash join использовать или merge join.
Это примерно того же уровня "решение", как я решаю раскрутить цикл с известным кол-вом повторов в С++.
Решает компилятор.
Разработчки по-прежнему должен лишь формулировать лишь "что" он хочет, а не "каким образом".
(хотя и спекуляции такого рода тоже весьма зависят от текущего рассматриваемого уровня дизайна системы, т.е. об уровне рассмотрения было бы неплохо договориться предварительно)
Здравствуйте, vdimas, Вы писали:
V>Изначальная задача SQL была совсем другая.
Это какая?
V>Тут неплохо бы аргументы. V>Де-факто, SQL был разработан вовсе не для того сценария, каким его используют в 99.99% случаев сегодня.
А для какого?
V>"Логика приложения" тут не при чём, SQL сегодня участвует сугубо в транспортном уровне.
Ну это кто как приложения разрабатывает. По хорошему, так не должно быть. По хорошему, может быть множество приложений, использующих БД.
V>Приличная часть данных в любой учетной системе неразрывно связана с логикой приложения.
На примере могу показать. Есть аналитическая БД с данными о плейсментах (реклама), есть отдельное приложение, которое собирает аналитику с сайтов (показы, энгейджменты и тд). Оно использует БД одним образом. Есть приложение — биллинг, которое считает рекламные бюджеты и использует ту же БД вторым способом. Есть приложение — веб морда, которое позволяет клиентам проводить рекламные компании, которое использует нашу БД третьим способом. Каждое приложение пишет своя команда долбоящеров. Давай дадим им притащить все то говно, которое у них в приложении сидит в общую БД? Все свои кривые и постоянно меняющиеся доменные знания. Круто будет наверное? Это примерно то что ты предлагаешь.
Так делают всякие наколенные сайты и прочую бухгалтерию, когда один человек пилит и приложение и БД.
V>База данных не разрабатывается отдельно от приложения, обрабатывающего эти данные.
Безапеляционно и неверно.
V>Этот планиовщик и так уже "притащен". Предлагалось перенести значительную нагрузку по планированию алгоритмов обращения к данным из динамики в статику.
Ну это невозможно и вообще глупо. БД собирает статистику, стоит гистаграммы и выбирает наиболее эффективные алгоритмы на основе динамических данных. Скажем если ты делаешь join и одна из таблиц очень маленькая, то БД будет просто значения в цикле перебирать и бежать по другой, если таблицы большие, но cardinality не оч. велико то hash join и тд. Вся эта информация в "статике" отсутствует. Мало того, в процессе работы, один и тот же запрос может по разному выполняться, если условия изменились. Такое в статике сделать нельзя.
V>Это примерно того же уровня "решение", как я решаю раскрутить цикл с известным кол-вом повторов в С++. V>Решает компилятор.
Компилятор не выбирает алгоритм, он просто оптимизирует. Это не то же самое, что и оптимизация запросов. На примере обычного кода — ты можешь написать вручную вложенный цикл несколькими способами, с использованием разных структур данных для хранения промежуточных результатов, при этом каждый вариант будет работать лучше или хуже на тех или иных данных. Оптимизатор может оптимизировать тот или иной вариант цикла, но не перестроить его динамически, во время выполнения приложения. Но ты можешь это обойти, начать собирать информацию о данных (гистограммы, скетчи и тд) и выбирать ту или иную реализацию динамически, во время исполнения. Если так сделать, то получится примитивный планировщик запросов БД.
V>Разработчки по-прежнему должен лишь формулировать лишь "что" он хочет, а не "каким образом".
Здравствуйте, chaotic-kotik, Вы писали:
V>>Изначальная задача SQL была совсем другая. CK>Это какая?
Консольные запросы от человека в интерактивном режиме.
V>>"Логика приложения" тут не при чём, SQL сегодня участвует сугубо в транспортном уровне. CK>Ну это кто как приложения разрабатывает.
Все так разрабатывают.
CK>По хорошему, так не должно быть. По хорошему, может быть множество приложений, использующих БД.
Множество клиентов к базе не отменяет описанный сценарий использования базы каждым из них.
V>>Приличная часть данных в любой учетной системе неразрывно связана с логикой приложения. CK>На примере могу показать. Есть аналитическая БД с данными о плейсментах (реклама), есть отдельное приложение, которое собирает аналитику с сайтов (показы, энгейджменты и тд). Оно использует БД одним образом. Есть приложение — биллинг, которое считает рекламные бюджеты и использует ту же БД вторым способом. Есть приложение — веб морда, которое позволяет клиентам проводить рекламные компании, которое использует нашу БД третьим способом. Каждое приложение пишет своя команда долбоящеров. Давай дадим им притащить все то говно, которое у них в приложении сидит в общую БД?
Оно и так есть — вьюхи и хранимки на стороне базы.
CK>Все свои кривые и постоянно меняющиеся доменные знания. Круто будет наверное? Это примерно то что ты предлагаешь.
В каком из мест?
CK>Так делают всякие наколенные сайты и прочую бухгалтерию, когда один человек пилит и приложение и БД.
Как "так"?
Сформулируй внятнее.
V>>База данных не разрабатывается отдельно от приложения, обрабатывающего эти данные. CK>Безапеляционно и неверно.
Абсолютно верно.
V>>Этот планиовщик и так уже "притащен". Предлагалось перенести значительную нагрузку по планированию алгоритмов обращения к данным из динамики в статику. CK>Ну это невозможно
Возможно.
CK>и вообще глупо.
Степень "глупости" как раз предлагается обсудить. Желательно с аргументами.
CK>БД собирает статистику, стоит гистаграммы и выбирает наиболее эффективные алгоритмы на основе динамических данных.
Практически любое статически-скомпиллированное приложение обрабатывает те самые "динамические данные".
CK>Скажем если ты делаешь join и одна из таблиц очень маленькая, то БД будет просто значения в цикле перебирать и бежать по другой, если таблицы большие, но cardinality не оч. велико то hash join и тд. Вся эта информация в "статике" отсутствует.
И?
Ты ветку читал? ))
Ну вот почитай, а то пошли уже повторения.
CK>Мало того, в процессе работы, один и тот же запрос может по разному выполняться, если условия изменились.
Верно.
CK>Такое в статике сделать нельзя.
Не верно.
V>>Это примерно того же уровня "решение", как я решаю раскрутить цикл с известным кол-вом повторов в С++. V>>Решает компилятор. CK>Компилятор не выбирает алгоритм, он просто оптимизирует.
В чём заключается возможность оптимизации?
CK>Это не то же самое, что и оптимизация запросов.
Ну я пока мест пытаюсь заставить собеседников разобраться, что именно происходит при планировании выполнения запроса.
Потому что на таком уровне как говоришь ты — это беспредметный разговор.
CK>На примере обычного кода — ты можешь написать вручную вложенный цикл несколькими способами, с использованием разных структур данных для хранения промежуточных результатов, при этом каждый вариант будет работать лучше или хуже на тех или иных данных. Оптимизатор может оптимизировать тот или иной вариант цикла, но не перестроить его динамически, во время выполнения приложения.
Может и часто делает именно так.
Не перестраивает динамически, но динамически выбирается одна из уже готовых оптимизированных веток.
Или в один и тот же цикл происходит заход в динамически выбираемую точку входа.
CK>Но ты можешь это обойти, начать собирать информацию о данных (гистограммы, скетчи и тд) и выбирать ту или иную реализацию динамически, во время исполнения. Если так сделать, то получится примитивный планировщик запросов БД.
Сам с собой споришь.
Т.е. споришь с теми тезисами, которые никто не выдвигал. ))
V>>Разработчки по-прежнему должен лишь формулировать лишь "что" он хочет, а не "каким образом". CK>прямо как в SQL
Верно.
Только с сохранением типизации на обеих концах транспорта и с выкидыванием до половины ненужных затрат на обеих концах системы.
Здравствуйте, chaotic-kotik, Вы писали:
_>>Интересно, как весь этот твой текст соотносится с фактом более эффективной работы например MongoDB? ))) CK>У тебя слишком мало скобочек, вот тебе еще, вдруг пригодятся — ))))) )))))))) ))))))))
С тем же успехом можно было бесконечно админить линуха какие-нить. Тем более, что до этого уже довелось поработать ~6 лет именно системщиком, а не прикладником. И если ты сейчас более не занимаешься такой юзверской деятельностью, а сам участвуешь в разработке технологий, то я только за тебя порадуюсь, мне не жалко. Но в этот спор ты влез, увы, с колокольни махрового юзера с раненным ЧСВ.
Мы уже победили, просто это еще не так заметно...
Просто мечта, а не язык для автоматической генерации... А уж как хорошо стандарт охватывает все необходимые возможности и как приятно можно запускать один и тот же SQL запрос на СУБД разных производителей — это вообще песня. Хотя о чём это я, какие запросы, если там даже ТИПЫ ДАННЫХ у каждого свои! 
