Калькулятор жёстко запрограммирован на выполнение указанных команд. Не думаю что ваша голова (не дай бог) работает по запрограммированной кем-то программе. На счёт "понимать" добро пожаловать в толковый словарь русского языка.
Можно масштабировать и на уровень ЭВМ, которая тоже оперирует битами и успешно делает вычисления. Но калькулятор не понимает структуру чисел: сколько в них десятков, сотен, тысяч и тд., что значит дробная часть, смысл отрицательного или простого числа и тд. Поэтому об интеллекте калькулятора и говорить как-то не приходится.
Правильнее говорить не об обучении и до обучении (в корректном понимании этих терминов для человека) языковой модели LLM, а об ее настройке и до настройке по предлагаемому тексту. Ибо такая модель оперирует только отдельными элементами составляющими текст (токенами), устанавливает и фиксирует между ними многочисленные связи, используя их в дальнейшей генерации ей своего текста. Она НЕ оперирует в целом понятиями и объектами, их свойствами и связанными отношениями как это делает человек. В этом принципиальное отличие машинного интеллекта на генеративной модели LLM от интеллекта человека.
Для думающих, конечно же, будет интересно. Модели построенные на LLM (нейронный сети) не ведут понятийные логические рассуждения как это делает человек. Они не оперируют в целом объектами и понятиями, их свойствами и связями, а настроены на генерацию контента используя зафиксированные при обучении связи, корреляции и ссылки только между отдельными элементами текста (его словами и фрагментами) - что должно быть следующим за предыдущим. Внешне результат и его объяснение от такой модели абсолютно ничем не отличается от человеческого, но получен он совершенно другим способом. Поэтому, я в своих комментах на эту тему (которые очень гневно воспринимаются оппонентами) пытаюсь донести, что такие модели, в отличие от человека, не понимают смысла в оперируемой ими информации. А от сюда можно уже делать и другие выводы.
Рано или поздно в законодательном порядке придется принимать уже сейчас назревшее решение: вся публичная информация (включая нормативную) в разных форматах полученная и/или сформированная с помощью технологий "машинного интеллекта" должна автором (авторами) помечаться уже в самом заголовке (преамбуле).
"Запрос, написанный таким образом, что планировщик вынужден строить оптимальный план запроса."
У вас в голове рекурсия уже на полную катушку работает.
Если бы хорошо учили теорию по реляционными базами данных, то должны знать, что прежде всего надо говорить об оптимальной структуре таблиц и связей между ними (модели данных), уровне нормализации, исходя из будущей выборки данных правильного определения индексов для полей. ЭТО является основой оптимальности и быстродействия для работы с базой данных, а НЕ запросы. С помощью запросов (процедур на сервере) и ПО на клиенте, их правильного баланса, реализуется алгоритм обработки и выборки данных для решения конкретной задачи. Сам алгоритм также может быть оптимальным и не оптимальным. Но если у вас не оптимальная структура БД, не оптимальный алгоритм решения задачи, то никакие оптимальные запросы пользы не принесут.
Короче, уважаемый, вам нужно садиться за матчасть, а не напрягаться учить других.
Каюсь, в SQL-1999 возможность рекурсивных вопросов действительно появилась. Ведущие компании разработчики СУБД ее добавили.
Сам начал работать с реляционными СУБД (SyBase, MS Access, MS SQL) с середины 90'х, тогда был стандарт SQL-92.
Реляционная модель изначально НЕ предназначалась для обработки иерархических (древовидных) структур данных. Поэтому, например, задачу хранения в РБД состава (спецификации) изделия пришлось описывать в 2-ух таблицах: главной и подчинённой в отношении "один ко многим". В главной весь перечень состава изделия (агрегаты, узлы, детали), а в подчинённой списки входящих (по ключам в главной) в них элементов согласно структуре изделия. Полное разузлование изделия с корня, состоящего из нескольких сотен деталей, в БД MS-SQL вер.7 на стороне клиента (программа с рекурсией на VB) с запросами через ODBC к серверу за recordset'ами к хранимым процедурам (store procedure), состоящими только из операторов select, занимало ~ 10-15 секунд на выч.мощностях того времени.
Такого рода задачи, как правило, разбивается на отдельные мелкие шаги, которые, кстати, можно реализовать совершенно разными способами, а не пытаться заморачиваться на написание такого совершенно НЕ воспринимаемого и читабельного текста сверхсложного запроса.
Значит "ваньку валял" и включил режим забалтывания.
SQL это язык выборки и манипулирования данными который лежит в основе реляционной БД. Разработан Э.Коддом в 1972г. В классическом стандарте SQL нет никаких рекурсией. Это уже индивидуальные прибамбасы и наворотки в конкретной СУБД, ее SQL-диалекте и попытки на нем построить свой внутренний язык программирования.
Отрадно. Если, уважаемый, вам не приходилось использовать, например, Designer Queries MS SQL, SQL Query for Oracle, мастера запросов MS Access, Power Query в Excel или что-то подобное, а на веру принимать только разноцветную "капусту" с форумов, тогда и давать такие оценки тому с чем не имел дело как-то не гоже.
Как бы в тему то входил ещё 30 лет назад на SyBase, MS Access, MS SQL 6.5, 7, 2000, ... .
Что вы понимаете под "оптимальным запросом" ? Если можно, то пример, только НЕ самого запроса на SQL, а под-схемы отношений таблиц с полями данных и задачи которую собираетесь решить. А там и потолкуем.
Для работы с реляционными базами данных давно уже имеются свои конструкторы запросов - графические интерактивные инструменты, которые генерируют уже готовый текст запроса на языке SQL. Как правило, такие инструменты поставляются вместе с самой СУБД или сторонними разработчиками. Поэтому необходимость писать текст сложных запроса с вложенными операторами select, join, группированием данных и тому подобное, просто отпадает. Это как писать код программы на ассемблере вместо использования языка программирования высокого уровня.
Об экспертных системах заговорили в начале 70'х когда появились диалоговые средства общения человека с компьютером в текстовом виде. Первые программы с текстовым диалогом считались в то время интеллектуальными, что по нынешним меркам выглядит наивно. Экспертные системы, рекламный бум которых был в 80'х годах, так и НЕ нашли широкого применения по одной причине: отсутствием специализированных инструментальных средств для их разработки. Языки программирования, ориентированные на создания ЭС такие как Clips, Prolog, Refal и др, "зашивали" базу знаний и логику рассуждений непосредственно в код программы и работали сугубо автономно без возможности встраивания как компонента в информационную систему.
Язык SQL для работы с данными неотделим от теории реляционной базы данных. Это как две части одного целого. Поэтому логично, и здравый смысл подсказывает, что описание языка должно быть в одной книге по теории РБД. То есть как отдельным разделом или 2-ой частью книги. Для работы с реляционными базами данных имеются свои конструкторы запросов - графические интерактивные инструменты, которые генерируют уже готовый текст запроса на языке SQL. Как правило, такие инструменты поставляются вместе с СУБД или сторонними разработчиками. Поэтому необходимость писать текст сложных запроса с вложенными операторами select, join, группированием данных и тому подобное, просто отпадает. Это как писать код программы на ассемблере вместо использования языка программирования высокого уровня. Работая с реляционными базами данных вот уже более 30 лет (MS Access, MS SQL), я никогда не пытался использовать SQL вручную. Знать этот язык конечно же необходимо, но использовать лучше высокоуровневые средства построения запросов генерирующих их в SQL. Также это необходимо и потому, что отдельные переменные части запроса приходится формировать программно при обращении к базе данных из приложения. Основа запроса строится конструктором, текст копируется в программу с последующей заменой переменных частей условий конкретными данными в процессе ее выполнения.
rPman забалтываешь без внятных контраргументов.
Калькулятор жёстко запрограммирован на выполнение указанных команд. Не думаю что ваша голова (не дай бог) работает по запрограммированной кем-то программе. На счёт "понимать" добро пожаловать в толковый словарь русского языка.
Можно масштабировать и на уровень ЭВМ, которая тоже оперирует битами и успешно делает вычисления. Но калькулятор не понимает структуру чисел: сколько в них десятков, сотен, тысяч и тд., что значит дробная часть, смысл отрицательного или простого числа и тд. Поэтому об интеллекте калькулятора и говорить как-то не приходится.
Правильнее говорить не об обучении и до обучении (в корректном понимании этих терминов для человека) языковой модели LLM, а об ее настройке и до настройке по предлагаемому тексту. Ибо такая модель оперирует только отдельными элементами составляющими текст (токенами), устанавливает и фиксирует между ними многочисленные связи, используя их в дальнейшей генерации ей своего текста. Она НЕ оперирует в целом понятиями и объектами, их свойствами и связанными отношениями как это делает человек. В этом принципиальное отличие машинного интеллекта на генеративной модели LLM от интеллекта человека.
Для думающих, конечно же, будет интересно. Модели построенные на LLM (нейронный сети) не ведут понятийные логические рассуждения как это делает человек. Они не оперируют в целом объектами и понятиями, их свойствами и связями, а настроены на генерацию контента используя зафиксированные при обучении связи, корреляции и ссылки только между отдельными элементами текста (его словами и фрагментами) - что должно быть следующим за предыдущим. Внешне результат и его объяснение от такой модели абсолютно ничем не отличается от человеческого, но получен он совершенно другим способом. Поэтому, я в своих комментах на эту тему (которые очень гневно воспринимаются оппонентами) пытаюсь донести, что такие модели, в отличие от человека, не понимают смысла в оперируемой ими информации. А от сюда можно уже делать и другие выводы.
Рано или поздно в законодательном порядке придется принимать уже сейчас назревшее решение: вся публичная информация (включая нормативную) в разных форматах полученная и/или сформированная с помощью технологий "машинного интеллекта" должна автором (авторами) помечаться уже в самом заголовке (преамбуле).
"Запрос, написанный таким образом, что планировщик вынужден строить оптимальный план запроса."
У вас в голове рекурсия уже на полную катушку работает.
Если бы хорошо учили теорию по реляционными базами данных, то должны знать, что прежде всего надо говорить об оптимальной структуре таблиц и связей между ними (модели данных), уровне нормализации, исходя из будущей выборки данных правильного определения индексов для полей. ЭТО является основой оптимальности и быстродействия для работы с базой данных, а НЕ запросы. С помощью запросов (процедур на сервере) и ПО на клиенте, их правильного баланса, реализуется алгоритм обработки и выборки данных для решения конкретной задачи. Сам алгоритм также может быть оптимальным и не оптимальным. Но если у вас не оптимальная структура БД, не оптимальный алгоритм решения задачи, то никакие оптимальные запросы пользы не принесут.
Короче, уважаемый, вам нужно садиться за матчасть, а не напрягаться учить других.
Тут с вами ставлю жирную точку.
Каюсь, в SQL-1999 возможность рекурсивных вопросов действительно появилась. Ведущие компании разработчики СУБД ее добавили.
Сам начал работать с реляционными СУБД (SyBase, MS Access, MS SQL) с середины 90'х, тогда был стандарт SQL-92.
Реляционная модель изначально НЕ предназначалась для обработки иерархических (древовидных) структур данных. Поэтому, например, задачу хранения в РБД состава (спецификации) изделия пришлось описывать в 2-ух таблицах: главной и подчинённой в отношении "один ко многим". В главной весь перечень состава изделия (агрегаты, узлы, детали), а в подчинённой списки входящих (по ключам в главной) в них элементов согласно структуре изделия. Полное разузлование изделия с корня, состоящего из нескольких сотен деталей, в БД MS-SQL вер.7 на стороне клиента (программа с рекурсией на VB) с запросами через ODBC к серверу за recordset'ами к хранимым процедурам (store procedure), состоящими только из операторов select, занимало ~ 10-15 секунд на выч.мощностях того времени.
Вранье. Если делать все правильно в сочетании клиент - сервер, то будет не хуже, а главное проще для поддержки и с возможностью работы на разных СУБД.
Ответ для Akina.
Такого рода задачи, как правило, разбивается на отдельные мелкие шаги, которые, кстати, можно реализовать совершенно разными способами, а не пытаться заморачиваться на написание такого совершенно НЕ воспринимаемого и читабельного текста сверхсложного запроса.
Значит "ваньку валял" и включил режим забалтывания.
SQL это язык выборки и манипулирования данными который лежит в основе реляционной БД. Разработан Э.Коддом в 1972г. В классическом стандарте SQL нет никаких рекурсией. Это уже индивидуальные прибамбасы и наворотки в конкретной СУБД, ее SQL-диалекте и попытки на нем построить свой внутренний язык программирования.
Тут ставлю с вами точку.
Отрадно. Если, уважаемый, вам не приходилось использовать, например, Designer Queries MS SQL, SQL Query for Oracle, мастера запросов MS Access, Power Query в Excel или что-то подобное, а на веру принимать только разноцветную "капусту" с форумов, тогда и давать такие оценки тому с чем не имел дело как-то не гоже.
Вполне вероятно, но только у тех кто такими инструментами никогда не пользовался.
Как бы в тему то входил ещё 30 лет назад на SyBase, MS Access, MS SQL 6.5, 7, 2000, ... .
Что вы понимаете под "оптимальным запросом" ? Если можно, то пример, только НЕ самого запроса на SQL, а под-схемы отношений таблиц с полями данных и задачи которую собираетесь решить. А там и потолкуем.
Чего мелочиться, сразу уж 512, а ещё лучше 1 Тб. (шутка)
Для работы с реляционными базами данных давно уже имеются свои конструкторы запросов - графические интерактивные инструменты, которые генерируют уже готовый текст запроса на языке SQL. Как правило, такие инструменты поставляются вместе с самой СУБД или сторонними разработчиками. Поэтому необходимость писать текст сложных запроса с вложенными операторами select, join, группированием данных и тому подобное, просто отпадает. Это как писать код программы на ассемблере вместо использования языка программирования высокого уровня.
Об экспертных системах заговорили в начале 70'х когда появились диалоговые средства общения человека с компьютером в текстовом виде. Первые программы с текстовым диалогом считались в то время интеллектуальными, что по нынешним меркам выглядит наивно. Экспертные системы, рекламный бум которых был в 80'х годах, так и НЕ нашли широкого применения по одной причине: отсутствием специализированных инструментальных средств для их разработки. Языки программирования, ориентированные на создания ЭС такие как Clips, Prolog, Refal и др, "зашивали" базу знаний и логику рассуждений непосредственно в код программы и работали сугубо автономно без возможности встраивания как компонента в информационную систему.
Язык SQL для работы с данными неотделим от теории реляционной базы данных. Это как две части одного целого. Поэтому логично, и здравый смысл подсказывает, что описание языка должно быть в одной книге по теории РБД. То есть как отдельным разделом или 2-ой частью книги. Для работы с реляционными базами данных имеются свои конструкторы запросов - графические интерактивные инструменты, которые генерируют уже готовый текст запроса на языке SQL. Как правило, такие инструменты поставляются вместе с СУБД или сторонними разработчиками. Поэтому необходимость писать текст сложных запроса с вложенными операторами select, join, группированием данных и тому подобное, просто отпадает. Это как писать код программы на ассемблере вместо использования языка программирования высокого уровня. Работая с реляционными базами данных вот уже более 30 лет (MS Access, MS SQL), я никогда не пытался использовать SQL вручную. Знать этот язык конечно же необходимо, но использовать лучше высокоуровневые средства построения запросов генерирующих их в SQL. Также это необходимо и потому, что отдельные переменные части запроса приходится формировать программно при обращении к базе данных из приложения. Основа запроса строится конструктором, текст копируется в программу с последующей заменой переменных частей условий конкретными данными в процессе ее выполнения.
Сегодня нахваливают Python, а завтра с уже удвоенной энергией Alligator.