В этом посте я бы хотел кратко рассказать, чем же отличаются Digital Q.DataBase и RuDB ...
В этом посте я бы хотел кратко рассказать, чем же отличаются Digital Q.DataBase и RuDB и какие задачи решает каждый из этих продуктов. Digital Q.DataBase — коммерческая СУБД для корпоративных заказчиков. Одна из ключевых задач, которую она решает: как перейти с Oracle и Microsoft SQL Server, сохранив прикладную логику и минимизировав переписывание кода? У Ассоциации разработчиков СУБД, которая развивает RuDB, другой исходный вопрос: зачем каждому российскому разработчику СУБД на базе PostgreSQL самостоятельно реализовывать одни и те же технологии? У таких разработчиков много общих задач: безопасность, перенос данных, повышение производительности, совместимость с российскими приложениями. Если каждую из них все решают отдельно, значительная часть усилий уходит на повторение одной и той же работы. Идея ассоциации — объединить усилия в этой общей части. Совместно развивать технологическую основу, на которой участники смогут создавать собственные продукты и конкурентные преимущества. Здесь важно различать саму ассоциацию и RuDB. Ассоциация объединяет разработчиков, а RuDB — технологический результат их совместной работы. Подробнее о возможностях RuDB можно прочитать на сайте database.ru. А сейчас давайте разберём один конкретный пример — совместимость с функциональностью пакетов Oracle. Представим корпоративное приложение, которое много лет работало на Oracle. Внутри него есть такой фрагмент PL/SQL-кода, как на слайде (2). Здесь используется пакет DBMS_AQ — механизм Oracle Advanced Queuing. Приложение формирует сообщение и вызовом DBMS_AQ.ENQUEUE помещает его в очередь. Теперь мы хотим перенести это приложение на обычный PostgreSQL. В стандартной поставке PostgreSQL такого пакета нет. И задача не сводится к тому, чтобы заменить название процедуры или поправить синтаксис. За этим вызовом стоит определённое поведение: постановка сообщения в очередь, его последующая обработка, связь с транзакцией. Разработчику нужно подобрать замену и проверить, что она обеспечивает необходимое приложению поведение. Это может потребовать изменений в коде, а иногда — и в архитектуре. Например, если принято решение использовать внешнюю систему обмена сообщениями. Именно здесь становится понятна ценность таких наработок в RuDB. В RuDB реализована функциональность работы с очередями, соответствующая этому примеру. Вместо пакетного вызова DBMS_AQ.ENQUEUE используется функция dbms_aq_enqueue. Но это не означает, что исходный PL/SQL-код можно перенести без изменений. Код потребуется адаптировать, а работу с параметрами, типами данных и транзакциями — проверить. При этом разработчику уже не нужно с нуля создавать сам механизм очереди. Он может использовать готовую реализацию и сосредоточиться на адаптации приложения. RuDB сокращает объём работы по воспроизведению необходимой функциональности при миграции. Digital Q.DataBase идёт дальше в части совместимости с исходным приложением: задача продукта — сохранить не только нужную функциональность, но и исходный код там, где поддерживается соответствующая совместимость. В примере на слайде (2) это означает сохранение привычного пакетного вызова из PL/SQL. Таким образом, различие можно сформулировать так: В RuDB мы используем готовую функциональность и адаптируем под неё код. В Digital Q.DataBase мы стремимся сохранить и функциональность, и исходный код приложения. Поэтому RuDB нельзя рассматривать просто как бесплатную версию Digital Q.DataBase. У них разные задачи: RuDB даёт разработчикам общую технологическую основу, а Digital Q.DataBase помогает корпоративным заказчикам переносить существующие приложения с минимальными изменениями. #RuDB #QDB #СУБД #НовостиСУБД #Oracle #PLSQL #Импортозамещение