Выглядит так, что в данной статье поднимается вопрос о логике мышления в большей степени, чем о сохранении данных документов в БД. Получается, что для разных систем может быть различная постановка задачи, поэтому единственно верный вариант ответа без контекста бизнес-требований просто нет возможности выбрать. В общем случае так и есть - всегда существуют альтернативные пути решения.
Вот она - та самая священная война в комментариях. ИИ это же инструмент, где-то он хорош, где-то не очень. Если какие-то задачи помогает решить быстрее с приемлемым результатом, то почему бы не использовать. И наоборот, если использование не приводит к приемлимому результату, либо достижение результата занимает сопоставимое время или даже дольше, то для такой задачи ИИ просто не подходит.
Из текста выглядит так, что в теории можно, а на практике - универсального готового решения нет и каждый желающий должен либо переписать свое приложение, либо переписать какую-нибудь СУБД с открытым кодом.
Для производителя приложения более логичным выбором тут выглядит переписать свое приложение, т.к. специалисты уже в наличии
Для производителей импортзамещенных СУБД выглядит логичнее просто сертифицировать немного модифицированную СУБД с открытым кодом и зарабатывать деньги не углубляясь в сложные вопросы миграции
Поверхностный обзор найти не сложно. Хотелось статей с конкретикой. Например, сейчас в небольшой компании (где в данный момент работаю) много проектов переходит с Windows+MS SQL на ASTRA+PostgreSQL (либо отечественное решение). Хотелось бы почитать как подружить авторизацию на базе Active Directory в Астре с вашим решением. Либо, как настроить автоматическое переключение между мастером и репликой туда-обратно при отказе мастера. Много же интересных тем можно раскрыть.
Выглядит так, что в данной статье поднимается вопрос о логике мышления в большей степени, чем о сохранении данных документов в БД. Получается, что для разных систем может быть различная постановка задачи, поэтому единственно верный вариант ответа без контекста бизнес-требований просто нет возможности выбрать. В общем случае так и есть - всегда существуют альтернативные пути решения.
Вот она - та самая священная война в комментариях. ИИ это же инструмент, где-то он хорош, где-то не очень. Если какие-то задачи помогает решить быстрее с приемлемым результатом, то почему бы не использовать. И наоборот, если использование не приводит к приемлимому результату, либо достижение результата занимает сопоставимое время или даже дольше, то для такой задачи ИИ просто не подходит.
Из текста выглядит так, что в теории можно, а на практике - универсального готового решения нет и каждый желающий должен либо переписать свое приложение, либо переписать какую-нибудь СУБД с открытым кодом.
Для производителя приложения более логичным выбором тут выглядит переписать свое приложение, т.к. специалисты уже в наличии
Для производителей импортзамещенных СУБД выглядит логичнее просто сертифицировать немного модифицированную СУБД с открытым кодом и зарабатывать деньги не углубляясь в сложные вопросы миграции
Поверхностный обзор найти не сложно. Хотелось статей с конкретикой. Например, сейчас в небольшой компании (где в данный момент работаю) много проектов переходит с Windows+MS SQL на ASTRA+PostgreSQL (либо отечественное решение). Хотелось бы почитать как подружить авторизацию на базе Active Directory в Астре с вашим решением. Либо, как настроить автоматическое переключение между мастером и репликой туда-обратно при отказе мастера. Много же интересных тем можно раскрыть.