Здравствуйте!
Возникла задача разработать приложение (.Net, C#), которое могло бы для хранения данных использовать разные СУБД. Например, один пользователь использует MS SQL Server, другой — MySQL, третий — Firebird.
Первой мыслью было сделать интерфейс, описывающий требуемые методы для получения, добавления, удаления, модификации, поиска разных объектов (например, пользователи, документы, заявки и т.п) из БД. А затем для каждой СУБД сделать специализированный класс, реализующий данный интерфейс с учетом особенностей конкретной СУБД. Но при таком подходе в случае изменения интерфейса потребуется вносить изменения в классах, реализующих интерфейс. А это мне кажется не совсем правильно. К тому же реализация методов интерфейса в разных классах будет очень схожей, ведь структура таблиц будет одинаковой.
Подскажите, как правильно реализовать возможность работы приложения с разными СУБД?
Здравствуйте, PetrSergeev, Вы писали:
V_S>>Подскажите, как правильно реализовать возможность работы приложения с разными СУБД? PS>Трёхзвенка
На счет трех звенки хз, не будет ли это оверхедом? сервер в трех звенке Rest или Rpc? Если rpc то это добавит еще гемора, а если rest который является адаптером до БД, то нужен ли он вообще, странное решение по мне исходя из требований.
Если вот так то я бы сделал интерфейсный модуль на POСO дата объектах, сделал бы интерфейс до базы и реализовал бы его. Но это вообще тупой вариант, можно подумать в сторону ORM или самописных объектных запросов. То что проще.
var query1 = IQueryFactory.Select(/*parameters*/);
var query2 = IQueryFactory.SelectWithJoin(/*parameters*/);
// and the next
DbConnection.ExecuteSql();
DbConnection.ExecuteSql();
Для увеличения гибкости можно сделать объектными Select, Where, OrderBy, Top, Having и т.д. под нужную базу подсоывать просто нужную фактори.
Здравствуйте, Vladimir_S, Вы писали:
V_S>Подскажите, как правильно реализовать возможность работы приложения с разными СУБД?
ORM используй, типа NHibernate — в них есть кое-какая абстракция от субд.
При соблюдении ряда правил (которые вы найдете эмпирическим путем ) все будет работать.
Здравствуйте, Vladimir_S, Вы писали:
V_S>Подскажите, как правильно реализовать возможность работы приложения с разными СУБД?
Сильно зависит от того через какую технологию будет реализована работа с БД.
1) Можно всегда завести иерархию SQLServerSpecificDAO extends CommonDAO и тогда не будет дублирования одинакового SQL кода.
2) Можно использовать фреймверки/API доступа к БД, которые уже реализуют прослойку в виде "Диалекта SQL".
Здравствуйте, rm822, Вы писали:
V_S>>Подскажите, как правильно реализовать возможность работы приложения с разными СУБД?
R>Правильно — не делать так
Я дважды в своей работе встречался с такими решениями.
В первом случае архитекторы завели такой уровень абстракции но программисты умудрились найти лазейки и стали писать only MS SQL код. В результате на Oracle это не работало а лишний уровень абстракции остался и очень сильно мешал работе.
Во втором случае это скорее всего должно было работать и с MS SQL хоть я и наблюдал это только в приложении к Oracle. Но правильнее все-таки это назвать "не работать" потому что такого дерьма я в жизни больше не встречал. Я имел с этим дело уже на излете "популярности" системы а начиналось все вот так:
F>...В результате на Oracle это не работало а лишний уровень абстракции остался и очень сильно мешал работе.... F>...Но правильнее все-таки это назвать "не работать" потому что такого дерьма я в жизни больше не встречал....
А вы ожидали чего-то другого?
Объективно нету у бизнеса потребности работать с нескольким разными вендорами БД практически никогда.
А с тех 0.1% случаях когда все-таки есть — доступ к базе закрывается слоем абстракции из хранимок и вьюх
Здравствуйте, rm822, Вы писали:
R>А вы ожидали чего-то другого? R>Объективно нету у бизнеса потребности работать с нескольким разными вендорами БД практически никогда. R>А с тех 0.1% случаях когда все-таки есть — доступ к базе закрывается слоем абстракции из хранимок и вьюх
Это наверное в .net мире так — дешевле убедить бизнес, что это не нужно.
У нас было так: сервер — psql, а на клиенте кеш данных с h2db... некоторые развесистые запросы надо было выполнять и там, и там, jquery+hibernate вполне справлялись. Там где возникали трудности, можно было и специфировать, но таких мест очень мало.
Многие коробочные продукты jira, youtrack, gerrit, и т.п. работают с разными субд, ибо обычно ставят их на ту субд, какая уже есть у заказчика, сложнее продать продукт, если он за собой ещё и субд тянет, а в случае с mssql, ещё и операционку.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
.>Это наверное в .net мире так — дешевле убедить бизнес, что это не нужно.
Во первых я не из этих
Во вторых произошло ровно обратное. Мы сделали поддержку нескольких БД и никто этим не пользовался вообще
_>Для увеличения гибкости можно сделать объектными Select, Where, OrderBy, Top, Having и т.д. под нужную базу подсоывать просто нужную фактори.
Всё это наивные теории, не более.
В жизни проекты, которые такое делают хоть с каким-то успехом, натыкаются на простое:
1. Сначала мы обнаруживаем, что понравившейся нам фичи вовсе нет в СУБД ХХ или она там сделана так, что лучше бы её не было. Переписываем весь код так, чтобы он работал исключительно на "safe subset".
2. Затем мы обнаруживаем, что одинаковые запросы в разных серверах ведут себя катастрофически по разному — потому, что стратегии обеспечения изоляции транзакций в Oracle, Postgres, MS SQL и Interbase различаются от слова совсем. То, что работало на одной машинке, внезапно приводит к дедлокам и неожиданностям под нагрузкой.
3. Затем мы обнаруживаем, что некоторые запросы выполняются неприемлемо долго под промышленной нагрузкой, и начинаем оптимизировать. Внезапно оказывается, что оптимизации специфичны для СУБД, и написать универсальный код, приемлемо работающий на всех движках, невозможно
4. В итоге мы обнаруживаем, что 99% пользователей таки ставят одну и ту же СУБД, т.к. в ней приложение работает лучше всего, а номинальная поддержка остальных движков просто проедает деньги.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Vladimir_S, Вы писали:
V_S>Подскажите, как правильно реализовать возможность работы приложения с разными СУБД?
Подключаться через ODBC, что бы не делать разные интерфейсы. Если в разных СУБД есть отличия в SQL, то для отличающихся случаев писать хранимые процедуры.
Здравствуйте, rm822, Вы писали:
.>>Это наверное в .net мире так — дешевле убедить бизнес, что это не нужно. R>Во первых я не из этих R>Во вторых произошло ровно обратное. Мы сделали поддержку нескольких БД и никто этим не пользовался вообще
Интересно, и какая же самая правильная субд, которая нравится всем?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
.>Интересно, и какая же самая правильная субд, которая нравится всем?
Уверен, что если нашим пользователям задать такой вопрос, то первая половина скажет что им пофиг, а вторая не поймет почему к ним лезут со всякими глупостями
А вообще в поставке идет Express LocalDB
Здравствуйте, rm822, Вы писали:
.>>Интересно, и какая же самая правильная субд, которая нравится всем? R>Уверен, что если нашим пользователям задать такой вопрос, то первая половина скажет что им пофиг, а вторая не поймет почему к ним лезут со всякими глупостями R>А вообще в поставке идет Express LocalDB
Так она практически однопользовательская, и вообще "targeted to program developers", просто вашему приложению настоящая субд не нужна. Обычно в таких случаях делают #include "embedded субд", и поставлять ничего не надо.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
.>Так она практически однопользовательская, и вообще "targeted to program developers", просто вашему приложению настоящая субд не нужна. Обычно в таких случаях делают #include "embedded субд", и поставлять ничего не надо.
Ох какой вы умный, все про нас знаете
ЛокалДБ — это для демо и чтобы пользователям удобно экспериментировать было.
А в продакшне базы от гигабайтов до терабайтов
Здравствуйте, rm822, Вы писали:
.>>Так она практически однопользовательская, и вообще "targeted to program developers", просто вашему приложению настоящая субд не нужна. Обычно в таких случаях делают #include "embedded субд", и поставлять ничего не надо. R>Ох какой вы умный, все про нас знаете R>ЛокалДБ — это для демо и чтобы пользователям удобно экспериментировать было. R>А в продакшне базы от гигабайтов до терабайтов
А после экспериментов они должны купить за 4/5-значное число долларов полноценный сервер плюс ещё операционку? И не желают воспользоваться бесплатным psql или уже купленным ora? Видимо очень специфичные клиенты.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
.>А после экспериментов они должны купить за 4/5-значное число долларов полноценный сервер плюс ещё операционку?
Вообще-то вариантов масса
а) они могут купить у нас SaaS подписку
б) они могут купить софт и захоститься по подписке в Амазоне, Азуре, или любом другом облаке, их сейчас полно
в) у большинства компаний уже есть и MSSQL и Oracle, просто используют существующее
г) могут использовать SQL Express, до стандарта еще дорасти надо
д) и наконец, да — могут купить сервер, лицензии и все такое
е) через пол годика будет еще вариант — прикрутим поддержку sql-азуры и бакапы в облака
Здравствуйте, ., Вы писали: .>А после экспериментов они должны купить за 4/5-значное число долларов полноценный сервер плюс ещё операционку? И не желают воспользоваться бесплатным psql или уже купленным ora? Видимо очень специфичные клиенты.
Не очень понятно, каким образом им поможет "уже купленный ора", если у него лицензия per-CPU.
Или они сразу купили его с десятикратным запасом, и теперь подыскивают приложения, чтобы всё это нагрузить?
Если нагрузка плёвая, то можно обойтись любым embedded движком (который будет несущественной для покупателя подробностью реализации). Если нагрузка серъёзная, то стоимость лицензии на выбранный девелоперами движок будет составлять не самую существенную часть сделки. Грубо говоря, стоимость железа уже снижает разницу между "навязанным" и "добровольно выбранным" в процентах полной стоимости. Вторым фактором является снижение себестоимости самого приложения. Это далеко не всегда отражается на розничной цене лицензии, но влияет на размер потенциальной скидки партнёру. Ну и на факторы третьего порядка — например, скорость выхода апдейтов и патчей. Если приложение должно уметь работать на пяти движках, то любой чих должен быть проверен на всех пяти движках, а это время и/или стоимость тестового железа. Постепенно это вызывает бешенство у клиента: он запросил мелкое изменение, а ему предлагают подождать 6-8 недель.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
) все будет работать.
