Предложить альтернативный способ организации / построения базы данных решения

Question

Мы используем 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, а также необходимость замены имени базы данных в зависимости от типа базы данных: config, main или gateway.Я думаю, что конфигурация должна быть уменьшена до Debug, Release и SQL_APPLY.Кроме того, использование 0, 1 и 2 кажется 80-м ... Наконец, я думаю, что мое намерение создавать или не создавать 3 типа баз данных для 3 типов поставщиков должно быть сконфигурировано только с такой платой, как:

XOX
OOX
XXX

В этом случае это будет означать сборку MSFT + CONFIG, все SYBASE и все GATEWAY.

Тем не менее, кажется, что в целом используется текстовый файл, препроцессор и множество конфигураций.невероятно неуклюжийСейчас 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)

Answer 1

Вам когда-нибудь приходилось писать SQL, который работал бы для нескольких поставщиков? Как ты это сделал?

Я использовал ORM's . Проверьте NHibernate . Поскольку вы используете VS2010, вы также можете проверить MS ADO.Net Entity Framework .
ORM позволяет вам абстрагировать базу данных в высокой степени. Будут все еще запросы, которые должны быть сделаны вручную для каждой СУБД отдельно, но, по моему опыту, это меньше, чем 10%.

Для других коммерческих и открытых источников проверки ORM Статья в Википедии: Список программного обеспечения объектно-реляционного отображения .

Редактировать: Комментарий к торговой платформе:

Я никогда не работал над таким проектом, поэтому я действительно не могу дать сколько-нибудь значимого совета. В качестве общего предложения ORM может помочь вам консолидировать уровень доступа к данным и минимизировать потребность в специальном коде СУБД. Большинство ORM также могут автоматически генерировать базу данных.

Мне было бы сложно сказать, что это скажется на производительности. Вам следует провести несколько тестов с лучшими ORM, как коммерческими, так и с открытым исходным кодом, а затем принять решение (Microsoft, вероятно, было бы интересно работать с компанией, которая использует Entity Framework на вашем рынке).

Кроме того, не стоит забывать, что внедрение ORM в существующий продукт сложно, так что это еще одна проблема, которую вам нужно учитывать.

Answer 2

Вам когда-нибудь приходилось писать SQL, будет работать для нескольких поставщиков? Как ты это сделал?

По сути, вы делаете это, добавляя слой абстракции между уровнем данных и любым другим уровнем. Тогда у вас есть пара вариантов:

1. Использование интеллектуального ORM для создания уровня данных и учета особенностей базы данных
2. Создайте уровень данных, используя модель провайдера, где вы создаете библиотеку для каждой поддерживаемой системы баз данных и используете код, который считывает что-то из файла конфигурации, чтобы определить, какого провайдера загрузить.

Похоже, что фундаментальная проблема в вашей ситуации состоит в том, что уровень данных не инкапсулирован в одну библиотеку и полностью экранирован от любого другого уровня. Если это правда, слабая сплоченность и жесткая связь являются одними из источников ваших проблем.

Вы должны рассмотреть возможность рефакторинга текущих библиотек, чтобы все взаимодействие с базой данных осуществлялось в пределах одной библиотеки и полностью абстрагировалось от любого уровня выше ее через интерфейсы. Это можно делать постепенно в течение нескольких циклов выпуска, пока в конечном итоге все вызовы не пройдут через интерфейс или абстрактный класс, который не зависит от базы данных, где у вас есть фабричные методы, которые загружают соответствующий конкретный класс для рассматриваемой базы данных.

Для получения дополнительной информации:

• ProviderBase
• Введение в модель поставщика