Добрый день!

Имеется проект с БД MS SQL ~1500 таблиц. DAL построен на Entity Framework.
Количество хранимок и UDF в БД незначительно. Продукт коробочный, БД стоит на стороне заказчика, квалифицированного DBA у заказчика, как правило, не имеется.
Стоит задача поддержки бесплатной СУБД (дополнительно к MS SQL). Рассматриваются варианты MySQL и PostgreSQL.

Если кто-то имел опыт поддержки в одном проекте нескольких СУБД, прошу поделиться.

MySQL видится более распространенной и простой в установке и обслуживании, но имеются следующие опасения (если я в чем-то не прав, прошу поправить):
1. 1С не поддерживает MySQL, но поддерживает PostgreSQL. Это технически обоснованно или сложилось исторически?
2. У MySQL нет аналога конструкции Apply (Lateral Join). Значит ли это, что запрос с выборкой головной записи и первой по дате из подчиненной коллекции в Entity Framework будет неэффективным?
3. MySql не поддерживает оконные функции (ROW_NUMBER). Значит ли это, что запрос с Paging [LINQ Select(...).Skip(X).Take(Y)] будет неэффективным?
4. Отсутствие поддержки GUID в MySql (у нас в БД почти во всех таблицах (кроме неизменяемых справочников) это - первичный ключ). В качестве альтернативы предлагается CHAR(36). Но это увеличит длину ключа (а, следовательно, и всех индексов) более, чем вдвое.

Спасибо!

softwarerНасколько я помню, у MSSQL имеется бесплатная редакция Express. Это наиболее простой и безболезненный вариант предложить клиентам бесплатную СУБД с возможным последующим переходом на взрослую.

Дело в том, что у клиентов уже "взрослые" данные, не помещающие в 10 GB SQL Express (либо близко к тому). А ограничение памяти в 1GB сводит на нет эффективность кэширования. Кроме того, в свете последних событий, цена клиентской лицензии "взрослой" СУБД стала "кусаться" на фоне клиентской лицензии нашего ПО.

pkarklinGluck_13,

Всегда полагал, что такие веши, как EF, изначально и создавались, как слой абстракции от конкретной СУБД для "разработчиков не баз данных".

Само по себе использование EF ставит под вопрос эффективность решения в целом.

Это понятно, 95% приложения и живет за этим слоем абстракции. А использование определенных подходов к построению LINQ-запросов, а также собственный механизм, обеспечивающий в LINQ2EF обращение к временным таблицам и динамическому SQL, позволяет достичь производительности, сопоставимой с "голым" T-SQL. Остальные 5% вполне возможно также спрятать за слоем абстракции от конкретной СУБД.

Речь идет о выборе СУБД, в которой те же подходы не вызовут существенного (в разы) понижения производительности относительно MS SQL. Чтобы LINQ запросы (а они бывают весьма замысловатыми), транслируемые EF посредством провайдера этой СУБД, приводили к тем же результатам, что и для MS SQL. Ну и чтобы набор возможностей был аналогичен, либо имелись адекватные замены (типы данных, уровни изоляции - часто используем SNAPSHOT, MARS и т.п.).

skyANAА что вы уже попробовали?

Заточили слой доступа данных конкретно под MS SQL, глядишь с другой СУБД тупо не заведётся.
Ставьте PostgreSQL и тестируйте основные сценарии.

Чтобы что-то попробовать, надо определиться с выбором. В простеньких тестовых приложениях все работает нормально с любым сервером. Чтобы добраться до тех деталей, в которых кроется дьявол, надо будет затратить, как минимум, 2-3 чел.мес, и было бы обидно после таких затрат столкнуться с непреодолимыми трудностями. Поэтому и хотелось бы услышать мнение тех, кто уже проходил такой путь.

Кстати, уже второй человек предлагает PostgreSQL. Значит ли это, что MySQL и рассматривать не стоит?