Pull to refresh

Comments 16

Спасибо за статейку. Скажите пожалуйтса а зачем Вам понадобилось мигрировать?
осмелюсь предположить, что цена лицензии на MsSQL… гляньте спортивного интереса ради MsSQL enterprise. изначлаьно, возможно, велась разработка использую express или bizspark лицензию для стартапов… а потом халява закончилась и встал вопрос платить или переезжать
Я не конца понимаю что было в головах продакт менеджеров, но основная идея мне кажется на поверхности. SQL Server стоит денег и если мы можем предложить продукт тем для кого эти деньги существенные, но им не столь важны фичи SQL Server почему бы это не сделать.
Дада, mssql хорошо, пока вы не делаете продукты на продажу, так же как и с ораклом. Коллега на работе рассказывал про систему расчета вероятности отказа, которую продают за бешеные деньги, и в бонус к этому требуют обязательным 9 оракл установленным. То есть цена, и так не маленькая увеличивается еще в н-раз, а это еще администрировать надо. Брр.
А в хранимках курсоры использовались?
Да, использовались. В MariaDb / MySQL тоже есть поддержка курсоров: mariadb.com/kb/en/mariadb/cursor-overview/ правда только non-scrollable но нам такие и требовались. Хотя разумеется часто код написанный с курсорами можно переписать без них.
	DECLARE vHost VARCHAR(512);

	DROP TEMPORARY TABLE IF EXISTS __HostsToProcess__;
	CREATE TEMPORARY TABLE __HostsToProcess__ ENGINE=MEMORY 
               AS SELECT Host FROM User;
	WHILE EXISTS (SELECT 1 FROM __HostsToProcess__ LIMIT 1) DO
	    SET vHost = (
                   SELECT Host FROM __HostsToProcess__ LIMIT 1);
	    SELECT CONCAT("Process host: ", vHost);
	    DELETE FROM __HostsToProcess__ 
                   WHERE Host = vHost;
	END WHILE;
	DROP TEMPORARY TABLE IF EXISTS __HostsToProcess__;
Дурацкий вопрос. Если переходили с SQL Server, то почему не на PostgreSQL? Мускуль же даже MS SQL по фичам/производительности несколько проигрывает, не то что Postgres.
В последнем предложении у Вас точно правильный порядок упоминания баз?
Были разные причины, в том числе и нетехнического характера. Из технических я бы упомянул еще раз ричину которую я указал в статье: ситаксис T-SQL и MariaDb меньше отличается чем синтаксис T-SQL и PL/PgSQL. Хотя и на PostgreSQL наверное можно было мигрировать просто проблемы были бы другие, не те что с MariaDb.
Правильный. Или в MS SQL уже закончились пляски с я-не-знаю-что-такое-этот-ваш-enum-храните-всё-как-int и прочими странными ограничениями и там, и тут?
Расскажите как вы 900 процедур перенесли и их вызов? Как автоматически? Вызов помоему сильно отличается.
Наверное это достойно отдельной статьи. Но если совсем кратко то полуавтоматически )
Что касается конвертации процедур то подход был такой:
Был powershell скрипт для предварительной подготовки текста, с теми заменами которые можно сделать с помощью regexp, например типы данных XML->LONGTEXT,UNIQUEIDENTIFIER->BINARY(16), и т.д., эквивалентные функции GETDATE()->UTC_TIMESTAMP(3), переименование переменных и параметров (тут было немного магии).
И после переписывались места для которых не было эквивалентной функциональности. Например где используются CTE, аналитические функции, конструкции IF THEN ELSE END IF (в T-SQL отличаются), и т.п.
Но в простых случаях после конвертации оставалось только расставить точки с запятой в конце statement-ов. Поначалу было медленно но потом разогнались и в итоге в день на человека выходило до 20 процедур. Причем большую часть времени занимало написание тестовых скриптов. В MariaDB / MySQL есть такая же проблема как в T-SQL пока вы не вызовете хранимую процедуру вы можете даже не узнать что у вас нет каких то таблиц или полей, поэтому без тестовых скриптов нельзя. Особенно пока не хватает функциональности для запуска интеграционных тестов на уровне бизнес слоя.
Что касается конвертиации DAC была предпринята попытка сделать код универсальным, в конце концов ведь нам нужно передать в хранимые процедуры одни и те же параметры и прочитать из резалт сета одни и те же поля. Типы на уровне БД отличаются но не отличаются на уровне приложения, таким образом фактически нужно только применять разные правила для data mapping и по другому обработать ошибки и исключения из БД.
dynamic SQL;

При прочтении этой строчки у меня сработал нервный тик. Нам к сожалению миграция такого рода не светит, поскольку чикотила, предыдущий разработчик уровня БД умудрился написать динамический SQL который лежит в ячейках, которые по возможности можно комбинировать и который запускается так же из динамического SQL. Своего рода inception, второй уровень SQL-динамики, лисп макросы отдыхают.
Трудно залезть в чужую голову, но возможно у предидущего разработчика были на это причины совершенно невредоносного характера. Например — требования к производительности или функциональности. Например пользователи могут сохранить свои фильтры которые нужно применять автоматически в background-е, и он не смог придумать решения лучше…

Но так или иначе если вы видите сейчас более правильное / красивое / эффективное решение скорее всего это можно исправить.
T-SQL хранящийся в таблицах в БД, если я правильно понял суть проблемы, не отличается от хранимых процедур, его тоже можно переписать изменив подход, разве нет?

Если вернутся к dynamic SQL — то его главный недостаток в SQL Server в том что он забивает квери кэш который становится большим и теряет эффективность. (В MariaDb такой проблемы нет по той причине, что query cache там лучше даже не включать :)
Only those users with full accounts are able to leave comments. Log in, please.