А у меня на эту тему простой тезис есть, без подробностей, но зато краткий: каков вопрос - таков ответ. Это значит, да - с промптами беда. Промпт это не вопрос и не запрос, это предоставление входной информации, данных, и задание произвести логические операции над ними. Если на входе - слабый контекст, то ответ конечно будет пальцем в небо. И это надо понимать, это приходит с опытом, все через это проходят. С ЛЛМ надо учиться работать. Это венец человеческого творения и технического прогресса. Кто пытался построить хоть раз реально приближенную к разумной экспертную систему, может представить насколько это сложнейшая задача и на фоне этого ЛЛМ - это просто чудо и гениально. Ну а пользоваться -- это конечно отдельная задача и навык. Мухи и котлеты отдельно.
Суток - не знаю. Такой цели нет. Но для тех, что интересуется GEO - в качестве общей вводной информации, надеюсь за несколько месяцев наберет своих читателей.
Все что делает ИИ - он сначала делает хуже чем человек, но человеко-подобно. Потом сносно, потом как человек. А потом превосходит человека на порядок и выше. В итоге - это полная автоматизация рутины, снижение стоимости рутинных работ, увеличение скорости работы, увеличение качества работы ... --> Прямая экономическая выгода.
Всё. Я еще раз внимательнее проанализировал ваше решение и осознал, что говорю о другой задаче. Вы решаете задачу только для некоторых таблиц, а не о всех.
если речь о данных за большие периоды, я бы конечно глубоко подумал о дифференциальном копировании данных между бд. через репликацию или копировании только транзакционных логов...
можно даже на уровне виртуальных дисков. скопировать vhd целиком и подменить на целевом. предварительно конечно остановив его. возможно, я конечно, не совсем понял правильно задачу, но по моему это минимум головной боли.
Очень интересный опыт применения ИИ в очень узкоспециализированной области. Просто рождается масса мыслей и идей, как это может быть полезно, со временем, когда механизмы будут значительно улучшены, а это произойдет достаточно быстро.
Кроме вышеописанного примера, наверное одно из основных преимуществ SQL в том, что на нем проще писать код с мгновенной проверкой на соответствие со сложными структурами данных, по ходу разработки. Что просто позволяет намного быстрее находить нужные решения. Когда все процедуры и их параметры определены, их легко инкапсулировать и вызывать через SQL, LINQ, EF из C# приложений. На мой взгляд это также на порядки быстрее и проще, т.к. существенно меньше накладных расходов и посредников в виде ненужной разработки промежуточной системы классов, методов и т.д...
В этом суть ориентации на подход Data-Driven Design. На T-SQL, в принципе, можно сделать всё.
Важное замечание. В ряде случаев, при этом, работа с данными необходима через ООП и ORM, обычно для пользовательских интерфейсов и обработки единичных экземпляров агрегатов. Хотя ORM может быть очень легковесным при этом, т.к. любая логика может быть на SQL.
Вы верно выбрали пример агрегата. Да, бизнес логику можно сделать на T-SQL. Да, это другой образ мышления и парадигма, прямого аналога юнит-тестированию я не подскажу. Но мой личный опыт показывает, что да, тестирование кода конечно производится по ходу разработки. В итоге, если все сделано грамотно, работает очень надежно годами, если не десятилетиями. В SQL существует достаточно развитая типизация данных. Есть TRY..CATCH... Обычно решения получаются железобетонные. Да могут появиться в работе какие-то сбои, но все это внутри сервера довольно хорошо диагностируется, находится и исправляется, если на первоначальном этапе закралась ошибка. Конечно все зависит от квалификации разработчика и степени его осознания, что он творит и в какой предметной области.
Заканчивая ответ на Ваш вопрос, главное преимущество и наиболее заметная разница наступает в случае массовой обработки агрегатов (как одно действие). Например несколько тысяч. Решение на C# и EF будет работать точно медленнее и возможно на пару порядков раз.
Еще раз подчеркиваю, сравнивать надо между C# LINQ и T-SQL при достаточно квалифицированном подходе в каждой области. T-SQL предоставляет множество возможностей, о которых не глубокие специалисты не имеют представления.
Радикальный подход. Хотя, конечно, имеет право на существование. А как Вы сочетаете с ORM (EF в частности)? На мой взгляд для простых атомарных операций и небольших выборок CRUD все же довольно удобно использовать LINQ.
С людьми то же самое, только знают они еще меньше.
А у меня на эту тему простой тезис есть, без подробностей, но зато краткий: каков вопрос - таков ответ. Это значит, да - с промптами беда. Промпт это не вопрос и не запрос, это предоставление входной информации, данных, и задание произвести логические операции над ними. Если на входе - слабый контекст, то ответ конечно будет пальцем в небо. И это надо понимать, это приходит с опытом, все через это проходят. С ЛЛМ надо учиться работать. Это венец человеческого творения и технического прогресса. Кто пытался построить хоть раз реально приближенную к разумной экспертную систему, может представить насколько это сложнейшая задача и на фоне этого ЛЛМ - это просто чудо и гениально. Ну а пользоваться -- это конечно отдельная задача и навык. Мухи и котлеты отдельно.
Суток - не знаю. Такой цели нет. Но для тех, что интересуется GEO - в качестве общей вводной информации, надеюсь за несколько месяцев наберет своих читателей.
Сразу вопрос: что LLM делал в продакшн? Если это не инкапсулированная программная АПИ функция?
Продакн на то и продакш чтобы получать только проверенные экземпляры приложений. и защищенный от любого непредусмотренного вмешательства.
Надеюсь вплотную используете ИИ?
Круто, продолжайте R&D. Впереди много достижений вас ждет.
Все что делает ИИ - он сначала делает хуже чем человек, но человеко-подобно. Потом сносно, потом как человек. А потом превосходит человека на порядок и выше. В итоге - это полная автоматизация рутины, снижение стоимости рутинных работ, увеличение скорости работы, увеличение качества работы ... --> Прямая экономическая выгода.
Всё. Я еще раз внимательнее проанализировал ваше решение и осознал, что говорю о другой задаче. Вы решаете задачу только для некоторых таблиц, а не о всех.
если речь о данных за большие периоды, я бы конечно глубоко подумал о дифференциальном копировании данных между бд. через репликацию или копировании только транзакционных логов...
можно даже на уровне виртуальных дисков. скопировать vhd целиком и подменить на целевом. предварительно конечно остановив его. возможно, я конечно, не совсем понял правильно задачу, но по моему это минимум головной боли.
А как насчет простого копирования файлов бд на целевой сервер и там аттач? перед этим лучше оптимизировать файлы.
Сразу видно здоровое зрелое видение и мнение. Согласен.
Очень интересная тема. Пока мало что про нее известно. Спасибо за компетентную экспертизу!
Как же круто
Очень интересный опыт применения ИИ в очень узкоспециализированной области. Просто рождается масса мыслей и идей, как это может быть полезно, со временем, когда механизмы будут значительно улучшены, а это произойдет достаточно быстро.
Извините, я не до конца понял, Вы за код SQL внутри БД или против?
Тема только для тех у кого MSSQL уже является неотъемлемой частью корпоративной ИТ-инфраструктуры. Или не корпоративной.
Кроме вышеописанного примера, наверное одно из основных преимуществ SQL в том, что на нем проще писать код с мгновенной проверкой на соответствие со сложными структурами данных, по ходу разработки. Что просто позволяет намного быстрее находить нужные решения. Когда все процедуры и их параметры определены, их легко инкапсулировать и вызывать через SQL, LINQ, EF из C# приложений. На мой взгляд это также на порядки быстрее и проще, т.к. существенно меньше накладных расходов и посредников в виде ненужной разработки промежуточной системы классов, методов и т.д...
В этом суть ориентации на подход Data-Driven Design. На T-SQL, в принципе, можно сделать всё.
Важное замечание. В ряде случаев, при этом, работа с данными необходима через ООП и ORM, обычно для пользовательских интерфейсов и обработки единичных экземпляров агрегатов. Хотя ORM может быть очень легковесным при этом, т.к. любая логика может быть на SQL.
Спасибо за Ваш комментарий.
Вы верно выбрали пример агрегата. Да, бизнес логику можно сделать на T-SQL. Да, это другой образ мышления и парадигма, прямого аналога юнит-тестированию я не подскажу. Но мой личный опыт показывает, что да, тестирование кода конечно производится по ходу разработки. В итоге, если все сделано грамотно, работает очень надежно годами, если не десятилетиями. В SQL существует достаточно развитая типизация данных. Есть TRY..CATCH... Обычно решения получаются железобетонные. Да могут появиться в работе какие-то сбои, но все это внутри сервера довольно хорошо диагностируется, находится и исправляется, если на первоначальном этапе закралась ошибка. Конечно все зависит от квалификации разработчика и степени его осознания, что он творит и в какой предметной области.
Заканчивая ответ на Ваш вопрос, главное преимущество и наиболее заметная разница наступает в случае массовой обработки агрегатов (как одно действие). Например несколько тысяч. Решение на C# и EF будет работать точно медленнее и возможно на пару порядков раз.
Еще раз подчеркиваю, сравнивать надо между C# LINQ и T-SQL при достаточно квалифицированном подходе в каждой области. T-SQL предоставляет множество возможностей, о которых не глубокие специалисты не имеют представления.
Радикальный подход. Хотя, конечно, имеет право на существование. А как Вы сочетаете с ORM (EF в частности)? На мой взгляд для простых атомарных операций и небольших выборок CRUD все же довольно удобно использовать LINQ.