Странная статья и не понятна конечная цель автора. Формально оставаясь ещё до 31.08.26 сотрудником такой компании в заявленной должности и публично в негативе обнародовать о ней свое личное мнение ? Как-то не вяжется и больше походит на сказку.
Принцип "что работает, надёжно и просто, то пусть и работает" относится не только к обычному колесу, но и ко всему остальному, включая программное обеспечение. В данном случае к Excel - гениальной программе табличной обработки данных и их анализу. Спасибо автору статьи за напоминание об этом.
Основное назначение базы знаний (knowledge base) - это фиксация и сохранение знаний в конкретной предметной области для использования их в поддержке принятия решений и сохранения интеллектуального потенциала компании. Об этом ещё было сказано 40 лет назад, когда стали говорить об экспертных системах, использующих базы знаний. Пользовательские инструменты для работы с БЗ должны обладать интеллектуальными способностями, копирующих действия специалистов-экспертов. С развитием современных технологий ИИ открываются новые возможности для создания баз знаний и экспертных систем. Главной проблемой останется широкая и разумная доступность к инструментальным средствам для их создания и их гарантированная поддержка, отсутствие которых в 80'х привело к забытию экспертных систем и баз знаний на долгие годы.
Вариантов на "что делать ?" может быть несколько. В том числе и как в данной статье. Нужно детально знать конкретику: какие в таблице данные, как часто поступают новые, как и какие по времени запрашиваются через select, есть ли в них агрегирование. Завязана ли таблица в запросах с другими таблицами, где они формируются: в разных местах (процедурах) непосредственно в самой СУБД или на клиентах тоже. Вопросов много, но без радикального физического разделения данных не обойтись. Что ж поделаешь, такова цена не качественного начального проектирования структуры БД.
Лечение заболевшего гриппом примочками. Источник проблемы в проектировании структуры БД (не только для postgresql). Физической концентрации в одной таблице терабайтовых данных допускать нельзя в принципе. Часть данных, и/или по времени их возникновения, должны распределяться по нескольким таблицам. Также, в зависимости от задачи, в отдельные таблицы могут выноситься исторические данные агрегированные по дате/времени с удалением начальных данных из рабочих таблиц, но с сохранением их в отдельной архивной БД.
Описанная ситуация типичная, когда в одну БД (не только postgresql) пытаются "запихнуть" все вместе. Это лишний раз подтверждает известную истину: правильно проектировать структуру БД, физически разделять ПО для бизнес-логики от ПО для обработки и доставки данных клиентам. Причем уже на этапе проектирования самой ИС необходимо рассматривать варианты возможного будущего расширение ее функционала и, соответственно, БД. Конечно, можно сказать, что на "берегу" все сразу не предусмотреть. Но надо донести до заказчика, что не продуманные до конца его потребности могут в дальнейшем привести к проблемам. Тип инструментов (выбор ЯП, СУБД) тоже очень важен, но вторичен. Это классика и в этом заключается квалификация разработчика.
Калькулятор жёстко запрограммирован на выполнение указанных команд. Не думаю что ваша голова (не дай бог) работает по запрограммированной кем-то программе. На счёт "понимать" добро пожаловать в толковый словарь русского языка.
Можно масштабировать и на уровень ЭВМ, которая тоже оперирует битами и успешно делает вычисления. Но калькулятор не понимает структуру чисел: сколько в них десятков, сотен, тысяч и тд., что значит дробная часть, смысл отрицательного или простого числа и тд. Поэтому об интеллекте калькулятора и говорить как-то не приходится.
Правильнее говорить не об обучении и до обучении (в корректном понимании этих терминов для человека) языковой модели 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 или что-то подобное, а на веру принимать только разноцветную "капусту" с форумов, тогда и давать такие оценки тому с чем не имел дело как-то не гоже.
Странная статья и не понятна конечная цель автора. Формально оставаясь ещё до 31.08.26 сотрудником такой компании в заявленной должности и публично в негативе обнародовать о ней свое личное мнение ? Как-то не вяжется и больше походит на сказку.
Принцип "что работает, надёжно и просто, то пусть и работает" относится не только к обычному колесу, но и ко всему остальному, включая программное обеспечение. В данном случае к Excel - гениальной программе табличной обработки данных и их анализу. Спасибо автору статьи за напоминание об этом.
Основное назначение базы знаний (knowledge base) - это фиксация и сохранение знаний в конкретной предметной области для использования их в поддержке принятия решений и сохранения интеллектуального потенциала компании. Об этом ещё было сказано 40 лет назад, когда стали говорить об экспертных системах, использующих базы знаний. Пользовательские инструменты для работы с БЗ должны обладать интеллектуальными способностями, копирующих действия специалистов-экспертов. С развитием современных технологий ИИ открываются новые возможности для создания баз знаний и экспертных систем. Главной проблемой останется широкая и разумная доступность к инструментальным средствам для их создания и их гарантированная поддержка, отсутствие которых в 80'х привело к забытию экспертных систем и баз знаний на долгие годы.
Вариантов на "что делать ?" может быть несколько. В том числе и как в данной статье. Нужно детально знать конкретику: какие в таблице данные, как часто поступают новые, как и какие по времени запрашиваются через select, есть ли в них агрегирование. Завязана ли таблица в запросах с другими таблицами, где они формируются: в разных местах (процедурах) непосредственно в самой СУБД или на клиентах тоже. Вопросов много, но без радикального физического разделения данных не обойтись. Что ж поделаешь, такова цена не качественного начального проектирования структуры БД.
Лечение заболевшего гриппом примочками. Источник проблемы в проектировании структуры БД (не только для postgresql). Физической концентрации в одной таблице терабайтовых данных допускать нельзя в принципе. Часть данных, и/или по времени их возникновения, должны распределяться по нескольким таблицам. Также, в зависимости от задачи, в отдельные таблицы могут выноситься исторические данные агрегированные по дате/времени с удалением начальных данных из рабочих таблиц, но с сохранением их в отдельной архивной БД.
Описанная ситуация типичная, когда в одну БД (не только postgresql) пытаются "запихнуть" все вместе. Это лишний раз подтверждает известную истину: правильно проектировать структуру БД, физически разделять ПО для бизнес-логики от ПО для обработки и доставки данных клиентам. Причем уже на этапе проектирования самой ИС необходимо рассматривать варианты возможного будущего расширение ее функционала и, соответственно, БД. Конечно, можно сказать, что на "берегу" все сразу не предусмотреть. Но надо донести до заказчика, что не продуманные до конца его потребности могут в дальнейшем привести к проблемам. Тип инструментов (выбор ЯП, СУБД) тоже очень важен, но вторичен. Это классика и в этом заключается квалификация разработчика.
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 или что-то подобное, а на веру принимать только разноцветную "капусту" с форумов, тогда и давать такие оценки тому с чем не имел дело как-то не гоже.
Вполне вероятно, но только у тех кто такими инструментами никогда не пользовался.