Это так, но чтобы выучить SQL нужно научиться на нем обработке данных. А это считается в современном программировании антипаттерном и препятствием к масштабированию.К тому же использование ORM избавляет от необходимости глубокого изучения SQL. Вот поэтому обработка данных средствами СУБД практически не используется, хотя она дает много преимуществ в определенных задачах. Все свои разработки я делаю с использованием именно серверных средств, но у меня не web и не хайлоад. Одна такая система описана мной в статье, которую можно найти в моем профиле.
Для разработанной мной экосистемы программ на базе sql server разработал монитор для локальной сети, показывающий загрузку цп sql сервера , свободное место на диске, загрузку памяти севера, какие приложения и кем запущены и лог действий в приложениях, для себя показываются список история всех изменений на сервере sql, для стендов тестирования показывается какие тесты запущены, какие операции выполняются, данные в онлайн и история. Программа на писана на Delphi с firedac, показывает все дашборды,серверная часть в хранимых процедурах с полной оптимизацией по скорости работы. Интервал обновления 2 сек. Сервер практически не загружает, в профайлере показывает время выполнения обновления не более 5 мс.
С клиента если делать то да, много тупого кода,но если делать в хранимой процедуре то никакой тонны кода не возникает. Единственная сложность что мало кто знает хорошо sql и как правильно это делать на сервере ну и использование хранимых процедур считается антипаттерном. Я в одном своем приложении спешно это делаю, копирую один объект из дерева и вставляю в другое дерево объектов в самой хранимой процедуре без использования кода на клиенте. Только id объектов передаю. Архитектура приложения полностью на хранимках. Не web и высоконагруженные системы.
Завод заводу рознь. В городе миллионнике есть разные заводы. С военных молодежь бежит, так как хочется жить а не пахать 12 часов в сутки. Есть еще средние производственные компании. Как правило весь бизнес там основан на 1С и ехсеl. У тех кто выпускает высокотехнологичную продукцию как правило есть некоторое проприетарное ПО для производства и пара тройка разрабов под 1C и это ПО. И все. И там не красные директора, а люди со степенью мба или даже научными степенями. Все.
Я пришел в производственную компанию как инженер-электронщик 8 лет назад в новое направление которое было нулевое. Мне тогда было 57. Но по хорошему команду себе на техническую часть прибора я подобрал сам, компания просто их наняла. Команда небольшая, программист на встроеноое ПО и программист на ПО верхнего уровня плюс я как разработчик электроники и программист SQL. За два года мы с нуля сделали сложный интеллектуальный датчик, сертифицировали его по АТЕX и главное - создали базовое ПО для его производства. Я работал как электронщик, паралельно создавая архитектуру и SQL код ( краткий обзор в статье в моем профиле на хабр). В общем поневоле пришлось тогда вернуться в программирование, которое я бросил в 44 года. Хочешь сделать хорошо - сделай сам. Сейчас электроника отошла на второй план, в паре с коллегой мы провели реинжиниринг внутреннего и клиентского ПО работы с интеллектуальными приборами компании и перевели базу данных с xml и на SQL Server и SQLite и разработали новое клиентское приложение, которое я потом успешно применил при создании программы тестирования электронных плат. Коллега мой - молодой человек 30 с небольшим лет и без моего опыта и подхода в создании систем он бы наверно не справился с сложной задачей создания производственной системы ПО, так как я давно был в этой теме и знал что нужно и что не нужно делать и как. Вообще мне кажется возраст не имеет значение, важен творческий склад ума , полное погружение в тему. Наверно с компанией мне повезло, но везет тому кто может везти. Хоть по должности я не был начальников своей команды, но по факту я был лидером в технической части, так как коллеги в требуемой теме не были. Главное знать куда идти.
Если нужны перекладыватели json то молодой вполне подойдет, а если нужно строить бизнес и производство практически с нуля, то тут нужен человек, который уже делал подобные вещи, с опытом архитектора систем и программистом способным работать как в SQL базах данных так и в ЯП. К томуже не web'oм единым живо программирование и ИТ.
Вы яркий пример человека, который не понимает что есть человек и как устроена его психика, что есть сознание и т п. Большинство думает что они сознательны. На самом деле ваше сознание это стереотипы, вложенные в вас с детства и не более того. Вот минусить вы научились, даже по сути не понимая зачем.
Любую сложную задачу можно решить разными путями. Сначала в голову приходят наиболее сложные способы. Но если начать думать, то задача неожиданно решается относительно просто и минимальными ресурсами. Весь вопрос в том что надо размышлять. Я тоже не умею кодить и в сложной задаче ( описана в публикации в моем профиле на хабре) я избрал путь без кода на клиенте, но с кодом на сервере при команде в 2 человека. Избавление от высокоуровневых ЯП потребовало больших затрат мыслительной энергии и в результате получилась система, которая уже несколько лет живет и практически не напрягает в поддержке. Без всяких абстракций и современных "подходов".
Человек познает новое не благодаря вычислительным алгоритмам в голове, а только через эмоции . Какие эмоции могут быть у трасформеров с перемножением матриц и прочей алгеброй? Никаких не может быть. Конечно, могут сделать имитацию и назвать это эмоциональным блоком, но это все бесполезно. Пока нет понимания что такое сознание все эти потуги с AGI лишь возможность заработать на волне хайпа ИИ, которое не ИИ а просто вычислительные системы и алгоритмы, основанные на обучающих материалах от человеков. Других нет и не будет.
Нет и не будет никакого AGI. Дело не вычислительных мощностях. Дело в непонимании что такое человек и его сознание и искуственным путем это создать нельзя ни сейчас, ни в обозримом будущем. Муравей не может создать человека. А человеческая цивилизация в основной своей массе пока не очень далеко ушла от муравьев по интеллекту.
Я не математик, но как программист, неплохо владеющий SQL стал бы решать эту задачу средствами SQL. И если эта задача действительно насущно необходима, то внес бы изменения в архитектуру этой системы с целью эффективной отработки SQL запросов по этой задаче на этапе логина и выхода из него. В общем все просто , если не ставить целью разработку сложных алгоритмов , когда можно эту задачу решить проще и быстрее. Это тоже разработка алгоритма, но в отличие от ЯП алгоритм в SQL это другой тип мышления, это работа со множествами, их пересечениями и отношениями. Просто глядя на диаграмму, мне почемуто вспомнился способ умножения чисел с помощью вертикальных линий, и здесь то же самое, если провести вертикальную черту то количество пересечений с отрезком или просто суммирование на интервале это и есть количество одновременных логинов. От этого можно и отталкиваться.
Хороший подход. Но у меня не знтерпрайз -приложения и в общем широкое использование хранимых процедур, где сконцентрирована обработка данных и возврат результатов. Насчет использования tvp пока не задумывался, возможно надо тему лучше изучить. Пока хватает оптимизации в sql server планов запросов, приемов создания sql кода и использования cte,
Да, именно так. Если логи закинуть в БД то без всяких математических алгоритмов можно эту задачу решить элементарными SQL запросами c оконными функциями. При наличии индексов по датам все будет летать.
Многие вещи можно делать намного проще через таблицы и хранимые процедуры. Но это типа антипаттерн сегодня, и логику размазывают по клиенту со всеми левыми билиотеками и фреймворками и прочими прелестями в дальнейшем. Впрочем в серверной логике нужен стиль и принцип тоже, иначе будет больно.
Когда deepseek ответил мне неправильно по поводу использования одного оператора в sqlite, на мои повторные указания что это не работает он зациклился. Я очень быстро нашел ответ почему не работает оператор в stack overflow, кстати. Но есть и удачные ответы, вполне рабочие.
Нейронки не научат вас что-то делать руками и головой. Играть на музыкальном инструменте, варить металл, строгать доски, рисовать картины, писать стихи, водить автомобиль, самолет, поезд и т д и т п. Там, где требуются навыки и знания, ИИ не поможет. Знать как делать и и уметь так делать - разные вещи, разные функции обучения мозга. Так что в этом плане все остается по прежнему.
Есть такое с СУБД. В Delphi в примере подключения АТTACH DATABASE в SQLite с использованием Firedac deepseek предлагает использовать exec все место правильного execsql. Исправляет только после указания на ошибку. С insert и on conflict без where то же самое, зацикливается и не указывает на ошибку в SQLite , где обязательно должен быть в запросе where. Нужно добавлять where true. Глаз да глаз нужен за этим deepseek. Хотя в stackoverflow эта проблема описана давно.
Это так, но чтобы выучить SQL нужно научиться на нем обработке данных. А это считается в современном программировании антипаттерном и препятствием к масштабированию.К тому же использование ORM избавляет от необходимости глубокого изучения SQL. Вот поэтому обработка данных средствами СУБД практически не используется, хотя она дает много преимуществ в определенных задачах. Все свои разработки я делаю с использованием именно серверных средств, но у меня не web и не хайлоад. Одна такая система описана мной в статье, которую можно найти в моем профиле.
Старый советский мультик про Вовку в тридевятом царстве- двое из ларца это и есть современный ИИ
Для разработанной мной экосистемы программ на базе sql server разработал монитор для локальной сети, показывающий загрузку цп sql сервера , свободное место на диске, загрузку памяти севера, какие приложения и кем запущены и лог действий в приложениях, для себя показываются список история всех изменений на сервере sql, для стендов тестирования показывается какие тесты запущены, какие операции выполняются, данные в онлайн и история. Программа на писана на Delphi с firedac, показывает все дашборды,серверная часть в хранимых процедурах с полной оптимизацией по скорости работы. Интервал обновления 2 сек. Сервер практически не загружает, в профайлере показывает время выполнения обновления не более 5 мс.
С клиента если делать то да, много тупого кода,но если делать в хранимой процедуре то никакой тонны кода не возникает. Единственная сложность что мало кто знает хорошо sql и как правильно это делать на сервере ну и использование хранимых процедур считается антипаттерном. Я в одном своем приложении спешно это делаю, копирую один объект из дерева и вставляю в другое дерево объектов в самой хранимой процедуре без использования кода на клиенте. Только id объектов передаю. Архитектура приложения полностью на хранимках. Не web и высоконагруженные системы.
Завод заводу рознь. В городе миллионнике есть разные заводы. С военных молодежь бежит, так как хочется жить а не пахать 12 часов в сутки. Есть еще средние производственные компании. Как правило весь бизнес там основан на 1С и ехсеl. У тех кто выпускает высокотехнологичную продукцию как правило есть некоторое проприетарное ПО для производства и пара тройка разрабов под 1C и это ПО. И все. И там не красные директора, а люди со степенью мба или даже научными степенями. Все.
Я пришел в производственную компанию как инженер-электронщик 8 лет назад в новое направление которое было нулевое. Мне тогда было 57. Но по хорошему команду себе на техническую часть прибора я подобрал сам, компания просто их наняла. Команда небольшая, программист на встроеноое ПО и программист на ПО верхнего уровня плюс я как разработчик электроники и программист SQL. За два года мы с нуля сделали сложный интеллектуальный датчик, сертифицировали его по АТЕX и главное - создали базовое ПО для его производства. Я работал как электронщик, паралельно создавая архитектуру и SQL код ( краткий обзор в статье в моем профиле на хабр). В общем поневоле пришлось тогда вернуться в программирование, которое я бросил в 44 года. Хочешь сделать хорошо - сделай сам. Сейчас электроника отошла на второй план, в паре с коллегой мы провели реинжиниринг внутреннего и клиентского ПО работы с интеллектуальными приборами компании и перевели базу данных с xml и на SQL Server и SQLite и разработали новое клиентское приложение, которое я потом успешно применил при создании программы тестирования электронных плат. Коллега мой - молодой человек 30 с небольшим лет и без моего опыта и подхода в создании систем он бы наверно не справился с сложной задачей создания производственной системы ПО, так как я давно был в этой теме и знал что нужно и что не нужно делать и как. Вообще мне кажется возраст не имеет значение, важен творческий склад ума , полное погружение в тему. Наверно с компанией мне повезло, но везет тому кто может везти. Хоть по должности я не был начальников своей команды, но по факту я был лидером в технической части, так как коллеги в требуемой теме не были. Главное знать куда идти.
Если нужны перекладыватели json то молодой вполне подойдет, а если нужно строить бизнес и производство практически с нуля, то тут нужен человек, который уже делал подобные вещи, с опытом архитектора систем и программистом способным работать как в SQL базах данных так и в ЯП. К томуже не web'oм единым живо программирование и ИТ.
Вы яркий пример человека, который не понимает что есть человек и как устроена его психика, что есть сознание и т п. Большинство думает что они сознательны. На самом деле ваше сознание это стереотипы, вложенные в вас с детства и не более того. Вот минусить вы научились, даже по сути не понимая зачем.
Любую сложную задачу можно решить разными путями. Сначала в голову приходят наиболее сложные способы. Но если начать думать, то задача неожиданно решается относительно просто и минимальными ресурсами. Весь вопрос в том что надо размышлять. Я тоже не умею кодить и в сложной задаче ( описана в публикации в моем профиле на хабре) я избрал путь без кода на клиенте, но с кодом на сервере при команде в 2 человека. Избавление от высокоуровневых ЯП потребовало больших затрат мыслительной энергии и в результате получилась система, которая уже несколько лет живет и практически не напрягает в поддержке. Без всяких абстракций и современных "подходов".
Человек познает новое не благодаря вычислительным алгоритмам в голове, а только через эмоции . Какие эмоции могут быть у трасформеров с перемножением матриц и прочей алгеброй? Никаких не может быть. Конечно, могут сделать имитацию и назвать это эмоциональным блоком, но это все бесполезно. Пока нет понимания что такое сознание все эти потуги с AGI лишь возможность заработать на волне хайпа ИИ, которое не ИИ а просто вычислительные системы и алгоритмы, основанные на обучающих материалах от человеков. Других нет и не будет.
Нет и не будет никакого AGI. Дело не вычислительных мощностях. Дело в непонимании что такое человек и его сознание и искуственным путем это создать нельзя ни сейчас, ни в обозримом будущем. Муравей не может создать человека. А человеческая цивилизация в основной своей массе пока не очень далеко ушла от муравьев по интеллекту.
Я не математик, но как программист, неплохо владеющий SQL стал бы решать эту задачу средствами SQL. И если эта задача действительно насущно необходима, то внес бы изменения в архитектуру этой системы с целью эффективной отработки SQL запросов по этой задаче на этапе логина и выхода из него. В общем все просто , если не ставить целью разработку сложных алгоритмов , когда можно эту задачу решить проще и быстрее. Это тоже разработка алгоритма, но в отличие от ЯП алгоритм в SQL это другой тип мышления, это работа со множествами, их пересечениями и отношениями. Просто глядя на диаграмму, мне почемуто вспомнился способ умножения чисел с помощью вертикальных линий, и здесь то же самое, если провести вертикальную черту то количество пересечений с отрезком или просто суммирование на интервале это и есть количество одновременных логинов. От этого можно и отталкиваться.
Хороший подход. Но у меня не знтерпрайз -приложения и в общем широкое использование хранимых процедур, где сконцентрирована обработка данных и возврат результатов. Насчет использования tvp пока не задумывался, возможно надо тему лучше изучить. Пока хватает оптимизации в sql server планов запросов, приемов создания sql кода и использования cte,
Да, именно так. Если логи закинуть в БД то без всяких математических алгоритмов можно эту задачу решить элементарными SQL запросами c оконными функциями. При наличии индексов по датам все будет летать.
Многие вещи можно делать намного проще через таблицы и хранимые процедуры. Но это типа антипаттерн сегодня, и логику размазывают по клиенту со всеми левыми билиотеками и фреймворками и прочими прелестями в дальнейшем. Впрочем в серверной логике нужен стиль и принцип тоже, иначе будет больно.
В sql server также как в статье ситуация. Сегодня подобной оптимизацией занимался.
Когда deepseek ответил мне неправильно по поводу использования одного оператора в sqlite, на мои повторные указания что это не работает он зациклился. Я очень быстро нашел ответ почему не работает оператор в stack overflow, кстати. Но есть и удачные ответы, вполне рабочие.
Нейронки не научат вас что-то делать руками и головой. Играть на музыкальном инструменте, варить металл, строгать доски, рисовать картины, писать стихи, водить автомобиль, самолет, поезд и т д и т п. Там, где требуются навыки и знания, ИИ не поможет. Знать как делать и и уметь так делать - разные вещи, разные функции обучения мозга. Так что в этом плане все остается по прежнему.
Есть такое с СУБД. В Delphi в примере подключения АТTACH DATABASE в SQLite с использованием Firedac deepseek предлагает использовать exec все место правильного execsql. Исправляет только после указания на ошибку. С insert и on conflict без where то же самое, зацикливается и не указывает на ошибку в SQLite , где обязательно должен быть в запросе where. Нужно добавлять where true. Глаз да глаз нужен за этим deepseek. Хотя в stackoverflow эта проблема описана давно.
Вопрос: исправлена ли работа INSERT c ON CONFLICT и отсутствием WHERE? Надо было добавлять WHERE TRUE