Как разработать схему базы данных, которая может использоваться как с MySQL, так и с SQL Server?

Google, чтобы узнать о различиях в типах данных.

Но схема - это лишь часть картины.

Диалекты SQL тоже разные. Google, чтобы узнать об этих различиях. Затем либо придерживайтесь подмножества SQL, общего для обоих, либо создайте схему, чтобы использовать несколько разных SQL в каждом из них.

Не ждите до конца, чтобы протестировать "другой" БД. Протестируйте и то, и другое с самого начала, чтобы не вкладывать слишком много средств в тупиковый дизайн.

Вот начальное место:
http://www.microsoft.com/technet/prodtechnol/sql/2000/deploy/mysql.mspx#EZD
и:
http://troels.arvin.dk/db/rdbms/#insert

В этой статье описаны некоторые из основных отличий.

Различия между MSSQL и mySQL

Вероятно, вы захотите устранить различия на уровне доступа к данным.

Вот четыре моих основных правила разработки кросс-баз данных:

1. Не используйте пробелы в именах для что-нибудь
2. Не используйте ключевые слова из любой базы данных в качестве имен столбцов (ORDER, DATE и т. д.)
3. Используйте самые простые возможные типы столбцов (CHAR, INT). Различия в столбцах типа даты и времени, вероятно, в какой-то момент вас сбивают с толку, поэтому по возможности избегайте их (я знаю, что обычно это нереально).
4. Дегормализуйте больше, чем вы думаете. Чем сложнее и сложнее ваш запрос, тем больше вероятность, что вам придется поддерживать парные версии ваших запросов, специфичные для db, чтобы все работало приемлемо в обеих базах данных. Оказавшись там, вы обречены.

1 и 2 на самом деле представляют собой одну и ту же проблему - все базы данных позволяют экранировать имена объектов (так что вы можете иметь имена с пробелами и именами, такими как ORDER и DATE), но обычно они делают это по-разному, поэтому этот запрос для SQL Server:

SELECT [ORDER], [Why This Name] FROM [Table From Hell]

должно быть

SELECT "ORDER", "Why This Name" FROM "Table From Hell"

в Oracle, и тогда у вас есть две версии каждого запроса или какой-то убер-дрянный код замены разделителей. Я обычно придерживаюсь более простого подхода, просто не использую ключевые слова или пробелы.

Один из «забавных» вариантов - вообще не писать SQL. Создайте систему, в которой вы можете абстрагироваться от спецификации того, что вы хотите сделать, а затем сгенерировать схему / запросы и т. д. У меня есть проект, в котором я создаю код SQL через предварительный процессор C.

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

Если вы загружаете и используете VisioModeler для фиксации своего концептуального и / или логического дизайна, он довольно хорошо выплевывает DDL для эквивалентного физического дизайна для нескольких СУБД.

http://www.microsoft.com/downloads/details.aspx?familyId=27fe6786-a439-4286-b8b6-7a9b84cfa709&displaylang=en

Или есть ряд других инструментов типа ERD, которые выполняют примерно то же самое. Вы можете попробовать DBDesigner.

http://www.fabforce.net/downloads.php

В зависимости от того, какой язык вы используете, вы можете вставить промежуточный слой ORM, такой как (например) Doctrine PHP, который должен помочь вам не писать SQL напрямую. В других комментариях есть ряд замечательных предложений относительно исходной схемы.

Есть несколько проблем, с которыми я столкнулся при работе с базами данных, предназначенными для использования нескольких бэкэндов.

Во-первых, типы данных различны и имеют разные способы обработки данных. Это может быть особенно сложно при работе с датами и большими объемами текста.

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

Другой подход - использовать хранимые процедуры и писать по одному для каждой поддерживаемой базы данных, но с одинаковыми именами для разных баз данных. Таким образом, вы можете воспользоваться преимуществами настройки производительности, доступной для каждой базы данных и различных структур баз данных, без необходимости изменять пользовательский интерфейс, но это намного сложнее поддерживать, потому что каждое изменение должно быть записано для каждой базы данных. Однако, вероятно, для ваших пользователей это будет намного быстрее, чем для ваших конкурентов, поэтому вы можете изменить дополнительную цену на продукт. Вам нужно будет взимать надбавку, хотя из-за дополнительных затрат на обслуживание и дополнительных специалистов по базам данных, которые вам понадобятся для настройки производительности для каждого типа базы данных (специалист по mysql, вероятно, не знает, как лучше всего настроить базу данных SQL Server. и наоборот)

Альтернативный вариант - разместить данные, а пользователи получают к ним доступ из Интернета. Тогда вам нужно будет разработать и поддержать только одну выбранную вами базу данных. Для этого вам понадобится целая куча серверов, сетей и специалистов по dba, поскольку вам нужно будет поддерживать в основном 24 часа безотказной работы для каждого клиента, и они могут потребовать, чтобы вы хранили их данные на серверах, которые не содержат данных от конкурентов. Не зная, для какой компании вы разрабатываете программное обеспечение, трудно сказать, является ли это жизнеспособной альтернативой.

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

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

Спецификацию домена будет сложно определить в терминах, которые не отдают предпочтение одному диалекту SQL над другим.

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

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

DeZign от Datanamic для баз данных поддерживает моделирование, не зависящее от базы данных.

Mysql предоставляет функцию экспорта, которая позволяет экспортировать схему в формат, совместимый с SQL Server.

Как было сказано ранее, используйте самый простой из возможных типов и не полагайтесь на стандартный SQL.