如何设计一个可以同时用于MySQL和SQLServer的数据库模式?

谷歌搜索数据类型的差异。

但模式只是画面的一部分。

SQL方言也不同。谷歌搜索这些差异。然后,要么坚持两者通用的SQL子集,要么构建一个方案,在每个方案中使用不同的SQL。

不要等到最后才在“其他”数据库上进行测试。从一开始就对两者进行测试,这样您就不会在死胡同的设计方向上投入太多。

http://www.microsoft.com/technet/prodtechnol/sql/2000/deploy/mysql.mspx#EZD

http://troels.arvin.dk/db/rdbms/#insert

我的跨数据库开发的四个主要指导原则如下:

1. 不要在名称中使用空格来表示 任何东西
2. 不要将数据库中的关键字用作列名(顺序、日期等)
3. 尽可能使用最简单的列类型(CHAR、INT)。日期和时间戳类型的列差异可能会在某个时候绊倒您,所以尽可能避免它们(我知道这通常是不现实的)。
4. 去正常化的程度超出了您可能认为合适的程度。您的查询越复杂,越有可能需要维护特定于数据库的查询配对版本,以便在两个数据库上都能正常工作。一旦你到了那里,你就注定了。

1和2实际上是同一个问题-所有数据库都允许转义对象名称(因此可以使用带有空格的名称以及顺序和日期之类的名称),但它们的做法通常不同,因此SQL Server的此查询:

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

一定是

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

本文描述了一些主要的区别。

Differences Between MSSQL and mySQL

您可能希望处理数据访问层中的差异。

Mysql提供了一个导出功能,允许您将模式导出为与SQL Server兼容的格式。

如前所述,使用尽可能简单的类型,不要依赖标准SQL。

我不会推荐以上任何一种,除非你 喜欢 玩高度抽象的代码。它倾向于充当一个长杠杆,你用力推短端,移动它一点点,巨大的事情就会发生。

如果您下载并使用VisioModeler捕获概念和/或逻辑设计,它非常擅长为几个RDBMS的等效物理设计提供DDL。

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

或者有许多其他ERD类型的工具可以完成大致相同的任务。你可以试试DBDesigner。

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

在使用设计为使用多个后端的数据库时,我遇到了几个问题。

首先,数据类型不同,处理数据的方式也不同。在处理日期和大量文本时,这往往特别棘手。

我注意到的下一件事是,由于他们试图使用ANSII标准SQL,当数据库不完全支持该标准时,就会出现问题。更大的问题是,标准通常不是从特定数据库获取数据的最有效方法。我使用过的每一个提供多个后端的商业数据库在表中获得大量记录时都非常慢。ANSII标准也并没有提供解决更复杂问题的好方法,所以您最终会遇到复杂的解决方法。

另一种方法是使用存储过程,为您支持的每个数据库后端编写一个存储过程,但在数据库中使用相同的名称。通过这种方式,您可以利用每个数据库和不同数据库结构的性能调优,而无需更改用户界面,但维护起来要困难得多,因为每个数据库都必须编写每个更改。然而,对于您的用户来说,它可能比您的竞争对手快得多,因此您可以更改产品的溢价。但是,由于额外的维护成本和为每种类型的数据库进行性能调整所需的额外数据库专家,您需要收取额外的费用(mysql专家可能不知道如何最好地调整SQL Server数据库,反之亦然)

另一个需要考虑的是,您托管数据,用户从Web访问数据。然后,您只需要设计和支持您选择的一个数据库。您需要一大堆服务器、网络和dba人员来完成这项工作,因为您需要为每个客户机保持24小时的正常运行时间,而且他们可能要求您将其数据存储在不包含任何竞争对手数据的服务器上。由于不了解您开发软件的业务,很难说这是否是一个可行的替代方案。

最便宜的方法是需要一个特定的后端。但是,您可能会失去不想购买不同后端的潜在客户。如果你这样做的话,我会调查潜在客户以找到他们现在使用的数据库,可能其中一个是事实上的行业标准,如果你要求它作为后端,你将失去很少的潜在客户。此外,如果你能使产品的卖点明显快于竞争对手,因为你有一个标准的后端,你可能会说服他们无论如何。但如果你走这条路,你最好设计一个速度极快的数据库。

设计一个特定于SQL但与SQL方言无关的逻辑数据库。设计应包括表、列、域和约束。约束包括但不限于主键约束和外键约束。

域规范将很难用不支持一种SQL方言而不支持另一种SQL方言的术语来定义。

在应用程序中,尽可能使用最小公分母SQL,而不会对性能或代码灵活性造成太大的损失。必要时,使用后端特定的方法编写代码。将这些后端依赖项隐藏在几个对象中。使大多数应用程序DBMS不可知。

Datanamic的Dezing for Databases支持独立于数据库的建模。