Предложите альтернативный способ организовать/создать решение для базы данных
Мы используем Visual Studio 2010, но это было сначала задумано с VS2003.
Я передам лучшие предложения своей команде. Текущая установка почти заставляет меня вырвать. Это - решение C# с большинством проектов, содержащих .sql файлы. Поскольку мы поддерживаем Microsoft, Oracle, и Sybase и так варивший домом препроцессор, во многом как препроцессор C, за исключением того, что замены выполняются варившей домом программой C# без использования yacc и инструменты как этот. #ifdefs используются для условных макроопределений, и да - макросы являются способом, которым это сделано. Макрос может расшириться до другого макроса или два, но это должно в конечном счете завершиться. Только макросы имеют #ifdef в них - остальная часть подобного коду SQL просто использует их макросы.
Теперь, различные конфигурации: Debug, MNDebug, MNRelease, Release, SQL_APPLY_ALL, SQL_APPLY_MSFT, SQL_APPLY_ORACLE, SQL_APPLY_SYBASE, SQL_BUILD_OUTPUT_ALL, SQL_COMPILE, а также еще 2.
Также: Any CPU, Mixed Platforms, Win32.
То, что сводит меня с ума, должно настроить его правильно, а также выбор правильного из 12 x 3 = 36 конфигурации, а также имеющий необходимость заменить именем базы данных в зависимости от типа базы данных: конфигурация, основная, или шлюз. Я думаю, что конфигурация должна быть уменьшена до просто Отладки, Выпуска и SQL_APPLY. Кроме того, использование 0, 1, и 2 кажется так 80-е... Наконец, я думаю, что мое намерение создать или не создать 3 типа баз данных для 3 типов поставщиков должно быть настроено только с тиком tac плата пальца ноги как:
XOX
OOX
XXX
В этом случае это означало бы сборку MSFT+CONFIG, весь SYBASE и весь ШЛЮЗ.
Однако, полная вещь, которая использует текстовый файл и препроцессор и много конфигураций, кажется невероятно неуклюжей. Это - 2010 год теперь, и кто-то там обязан иметь очень чистый и/или творческий инструмент/решение. Единственное про было бы то, что существующий набор макросов был хорошо протестирован.
Необходимо ли было когда-либо писать SQL, который работал бы на несколько поставщиков? Как Вы делали это?
SqlVars.txt (Каждые из 30 пользователей делает копию шаблона и изменяет это для удовлетворения их потребностям):
// This is the default parameters file and should not be changed.
// You can overwrite any of these parameters by copying the appropriate
// section to override into SqlVars.txt and providing your own information.
//Build types are 0-Config, 1-Main, 2-Gateway
BUILD_TYPE=1
REMOVE_COMMENTS=1
// Login information used when applying to a Microsoft SQL server database
SQL_APPLY_MSFT_version=SQL2005
SQL_APPLY_MSFT_database=msftdb
SQL_APPLY_MSFT_server=ABC
SQL_APPLY_MSFT_user=msftusr
SQL_APPLY_MSFT_password=msftpwd
// Login information used when applying to an Oracle database
SQL_APPLY_ORACLE_version=ORACLE10g
SQL_APPLY_ORACLE_server=oradb
SQL_APPLY_ORACLE_user=orausr
SQL_APPLY_ORACLE_password=orapwd
// Login information used when applying to a Sybase database
SQL_APPLY_SYBASE_version=SYBASE125
SQL_APPLY_SYBASE_database=sybdb
SQL_APPLY_SYBASE_server=sybdb
SQL_APPLY_SYBASE_user=sybusr
SQL_APPLY_SYBASE_password=sybpwd
... (THIS GOES ON)
2 ответа
Приходилось ли вам писать SQL, который работал бы для нескольких поставщиков? Как вы это делали?
Я использовал ORM'ы. Check NHibernate. Поскольку вы используете VS2010, вы также можете проверить MS ADO.Net Entity Framework.
ORM позволяет абстрагировать базу данных в высокой степени. Все равно останутся запросы, которые необходимо составлять вручную для каждой СУБД отдельно, но, по моему опыту, это менее 10%.
О других коммерческих ORM и ORM с открытым исходным кодом читайте в статье Википедии: Список программ объектно-реляционного отображения.
Edit: Re trading platform comment:
Я никогда не работал над подобным проектом, поэтому не могу дать никакого значимого совета. В качестве общего совета, ORM может помочь вам консолидировать уровень доступа к данным и минимизировать необходимость в коде, специфичном для РСУБД. Большинство ORM также могут автоматически генерировать базу данных.
Каковы будут потери производительности при этом, я сказать не могу. Вам следует провести несколько тестов с лучшими ORM, как коммерческими, так и с открытым исходным кодом, а затем принять решение (Microsoft, вероятно, будет заинтересована в работе с компанией, использующей Entity Framework на вашем рынке).
Также не стоит забывать, что внедрить ORM в существующий продукт очень сложно, так что это еще одна проблема, которую вам нужно принять во внимание.
Приходилось ли вам когда-нибудь писать SQL, который подойдет для нескольких производителей? Как вы это сделали?
По сути, вы делаете это, добавляя уровень абстракции между уровнем данных и любым другим уровнем. Тогда у вас есть несколько вариантов:
- Используйте интеллектуальную ORM для создания уровня данных и учета особенностей базы данных
- Создайте уровень данных, используя модель поставщика, где вы создаете библиотеку для каждой системы баз данных, которая будет поддерживаться и используйте код, который считывает что-то из файла конфигурации, чтобы определить, какой провайдер загружать.
Похоже, основная проблема в вашей ситуации заключается в том, что уровень данных не инкапсулирован в одну библиотеку и полностью защищен от любого другого уровня. Если это правда, то слабая сплоченность и тесная связь - одни из источников ваших бед.
Вам следует подумать о рефакторинге текущих библиотек, чтобы все взаимодействие с базой данных осуществлялось в рамках одной библиотеки и было полностью абстрагировано от любого уровня, находящегося над ней, через интерфейсы. Это можно делать постепенно, через несколько циклов выпуска, пока в конечном итоге все вызовы не пройдут через интерфейс или абстрактный класс, который не зависит от базы данных, где у вас есть фабричные методы, загружающие соответствующий конкретный класс для рассматриваемой базы данных.
Для получения дополнительной информации: