Все что делает ИИ - он сначала делает хуже чем человек, но человеко-подобно. Потом сносно, потом как человек. А потом превосходит человека на порядок и выше. В итоге - это полная автоматизация рутины, снижение стоимости рутинных работ, увеличение скорости работы, увеличение качества работы ... --> Прямая экономическая выгода.
Всё. Я еще раз внимательнее проанализировал ваше решение и осознал, что говорю о другой задаче. Вы решаете задачу только для некоторых таблиц, а не о всех.
если речь о данных за большие периоды, я бы конечно глубоко подумал о дифференциальном копировании данных между бд. через репликацию или копировании только транзакционных логов...
можно даже на уровне виртуальных дисков. скопировать 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.
Просто это не Ваша тема. Либо ваша, но Вы в этом абсолютный новичок. Как часто вы так вовлекаетесь в разные неинтересные Вам темы по жизни? Советую обратиться к психологу. Очень помогают.
В принципе, я не настаиваю на ее обязательном изучении и даже ознакомлении. Это был Ваш свободный личный выбор. Но при этом, Вы бросаете мне упреки, что я вообще тут существую.
Хинт для дальнейшей эволюции. Берите под контроль бизнес-процессы. Их сложно и почти невозможно вырвать из цепких рук архаичного руководства, по своему опыту знаю. Но если пойти через доверие с его стороны, то можно очень круто подняться в своем профессионализме.
300 отчетов у вас потому что их запрашивает руководство, которое путаясь пытается разобраться в многомерных массивах данных (реляционных). Если проектировать систему от бизнеса и от бизнес-процессов, ее можно чрезвычайно упростить и сделать столь же существенно мощнее. Бизнес вполне может перейти на новый порядковый уровень финансовых показателей за счет этого. Все должно быть просто. Это должно привести к глубокой реорганизации и замене человеков-функций на автоматическую работу, просто исключить людей из множества процедур обработки информации. А всё - есть обработка информации.
Поздравляю автора с правильным начинанием. Из каменного в цифровой век. Ваша история очень похожа на множество подобных. Переход от электронных таблиц к базам данных с SQL - революционный шаг. Успехов!
Спасибо за интересный опыт. Если будет настроение напишите еще. Любые подробности.
Кстати сегодня я опубликовал новую версию этой статьи с учетом результатов довольно интересной дискуссии здесь в комментариях. Ссылка: https://habr.com/ru/articles/914378/
Взаимно, и Вам спасибо за конструктивный вдумчивый ответ на непраздный вопрос.
Многое зависит от контекста. Писать туториал - довольно рутинная задача. Но поставить задачу его написать - как в данном случае, есть свободный человеческий творческий процесс. Думаю, многие просто не привыкли, не осознали и не смирились еще с тем фактом, что в будущем синергия человека с ИИ будет только нарастать. И огульные обвинения в синтетичности скорее всего есть следствие незрелости, но и несовершенства как человека берущего в руки ИИ, так и самого ИИ.
Насчет темы постав о гибридном подходе к реализации бизнес-логики разделенной между Domain Driven Desing и Data Driven Design, безусловно это зависит от контекста, как Вы верное заметили. И мой ключевой посыл был сместить ситуацию в сторону более здорового баланса, поскольку из современного инфопространства в основном сквозит чрезмерная приверженность к одному только варианту. Это упускает массу великолепных возможностей в плане экстремальной производительности и простоты кода.
Все что делает ИИ - он сначала делает хуже чем человек, но человеко-подобно. Потом сносно, потом как человек. А потом превосходит человека на порядок и выше. В итоге - это полная автоматизация рутины, снижение стоимости рутинных работ, увеличение скорости работы, увеличение качества работы ... --> Прямая экономическая выгода.
Всё. Я еще раз внимательнее проанализировал ваше решение и осознал, что говорю о другой задаче. Вы решаете задачу только для некоторых таблиц, а не о всех.
если речь о данных за большие периоды, я бы конечно глубоко подумал о дифференциальном копировании данных между бд. через репликацию или копировании только транзакционных логов...
можно даже на уровне виртуальных дисков. скопировать 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.
Просто это не Ваша тема. Либо ваша, но Вы в этом абсолютный новичок. Как часто вы так вовлекаетесь в разные неинтересные Вам темы по жизни? Советую обратиться к психологу. Очень помогают.
В принципе, я не настаиваю на ее обязательном изучении и даже ознакомлении. Это был Ваш свободный личный выбор. Но при этом, Вы бросаете мне упреки, что я вообще тут существую.
Извините, что помешал Вам счастливо жить. )))
Хинт для дальнейшей эволюции.
Берите под контроль бизнес-процессы. Их сложно и почти невозможно вырвать из цепких рук архаичного руководства, по своему опыту знаю. Но если пойти через доверие с его стороны, то можно очень круто подняться в своем профессионализме.
300 отчетов у вас потому что их запрашивает руководство, которое путаясь пытается разобраться в многомерных массивах данных (реляционных). Если проектировать систему от бизнеса и от бизнес-процессов, ее можно чрезвычайно упростить и сделать столь же существенно мощнее. Бизнес вполне может перейти на новый порядковый уровень финансовых показателей за счет этого. Все должно быть просто. Это должно привести к глубокой реорганизации и замене человеков-функций на автоматическую работу, просто исключить людей из множества процедур обработки информации. А всё - есть обработка информации.
Поздравляю автора с правильным начинанием. Из каменного в цифровой век.
Ваша история очень похожа на множество подобных. Переход от электронных таблиц к базам данных с SQL - революционный шаг. Успехов!
Я созрел и переписал статью заново в виде второй версии с учетом комментариев: https://habr.com/ru/articles/914378/
Спасибо за интересный опыт. Если будет настроение напишите еще. Любые подробности.
Кстати сегодня я опубликовал новую версию этой статьи с учетом результатов довольно интересной дискуссии здесь в комментариях. Ссылка: https://habr.com/ru/articles/914378/
Взаимно, и Вам спасибо за конструктивный вдумчивый ответ на непраздный вопрос.
Многое зависит от контекста. Писать туториал - довольно рутинная задача. Но поставить задачу его написать - как в данном случае, есть свободный человеческий творческий процесс. Думаю, многие просто не привыкли, не осознали и не смирились еще с тем фактом, что в будущем синергия человека с ИИ будет только нарастать. И огульные обвинения в синтетичности скорее всего есть следствие незрелости, но и несовершенства как человека берущего в руки ИИ, так и самого ИИ.
Насчет темы постав о гибридном подходе к реализации бизнес-логики разделенной между Domain Driven Desing и Data Driven Design, безусловно это зависит от контекста, как Вы верное заметили. И мой ключевой посыл был сместить ситуацию в сторону более здорового баланса, поскольку из современного инфопространства в основном сквозит чрезмерная приверженность к одному только варианту. Это упускает массу великолепных возможностей в плане экстремальной производительности и простоты кода.