SQL 兼容性图表（特别是数据类型）
所以......碰巧我正在编写一些代码......最终将同时在不同的sql服务器上使用。
虽然 SQL 代码根据服务器不同而不同，但数据类型和列却不同。
因此，我需要知道（至少是大多数）sql server 类型共有哪些数据类型。
作为起点，我有以下类型：
byte, char, float, int, text, varchar, blob
请注意，拼写非常重要，因为数据类型名称将按原样以查询结尾（例如：虽然支持 int 和 integer，但我需要通用的）。
那么，问题是，有谁知道比较sql服务器之间兼容性的图表吗？或者也许有人在该领域做过一些研究？
就偏见而言，我显然对特定的 RDBMS 有偏见，因此不需要回答哪个 RDBMS 恰好更好。让我们保持焦点和主题，好吗？
So...happens I'm working on some code which...will end up being used on different sql servers at the same time.
Although the SQL code is different depending on the server, the data types and columns are not.
Therefor, I need to know which are the data types common to (at least most) sql server types.
As a starting point, I have the following types:
byte, char, float, int, text, varchar, blob
Please note that spelling is quite important, since the data type name will end in the query as is (eg: although both int and integer are supported, I need the common one).
So, the question is, does anyone know of a chart comparing compatibility between sql servers? Or perhaps someone which did some research in the field?
As far as bias goes, I'm obviously biased to a particular RDBMS, so no need for answers on which RDBMS happens to be better. Let's keep this focused and on topic, ok?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我认为您最终将为每种类型的数据库服务器编写特定的、逐个案例的 SQL 语句。我当然做到了。
我曾经遇到过你的情况，包括有意编写与数据库无关的代码，但从长远来看它是行不通的。例如，一个数据库不会处理多字节字符串，而另一个数据库则需要它们（即 SQL Server CE），这将迫使您在列上使用 Varchar 或 NVarchar。有些数据库支持多字节字符串，但性能很差。其中一个将使用 VARCHAR2 (Oracle)，其他人将使用 VARCHAR。一种方法会以一种方式处理 BLOB，而另一种方法会采用不同的方式。也不要让我开始了解日期数据类型。
与其寻找适用于所有数据库的 SQL 语言和数据类型的神奇子集，不如寻找一种可以为您隐藏差异的数据访问方法/库（也许是一些允许您创建 DB 对象的 ORM 库）。以及访问它们？）就像
我说的，我一直（并且仍然）处于必须支持多个数据库的情况，对我来说最好的解决方案是为每个数据库编写最佳代码，而不是尝试查找 SQL 数据适用于所有这些的类型和代码（我无法做到，没有达到令人满意的水平）。
此外，如果为每个数据库创建单独的 SQL 文本（即，您在创建 Oracle 表时可以指定的与性能相关的参数，而这些参数在创建 Oracle 表时根本不适用），那么您将能够从每个数据库中获得更多性能。任何其他数据库）。
我说，不要对抗不同数据库中的语法差异，你不会赢。最好的办法是忍受这些差异，并尽可能地利用这些差异来为自己谋利。
I think you will end up writing specific, casy by case SQL statements for each type of database server. Certainly I did.
I've been in your situation, including having the intention to write database agnostic code, but in the long run it just does not work. One database will not, for example, handle multi-byte strings while another will demand them (ie, SQL Server CE), this will force you to use either Varchar vs NVarchar on columns, for example. Some databses will support multi byte strings, but with awful performance. One will use VARCHAR2 (Oracle), and everyone else will use VARCHAR. One will handle BLOBs one way while another will do so differently. Don't get me started on date data types, either.
Rather than find the magic subset of the SQL language and data types that works in all databases, you would be wiser to look for a data access method/library that can hide the differences for you (maybe some ORM library that lets you create DB objects as well as access them?)
Like I said, I have been (and still am) in your situation of having to support multiple databases and the best solution for me is to write optimal code for each database, rather that trying to find SQL data types and code that works in all of them (I wasn't able to, not to a satisfactory level).
Also, you will be able to squeeze more performance out of each DB if you create separate SQL text for each database (ie, the performance-related parameters you can specify while creating an Oracle table that do not apply at all when creating a table in any other database).
I say, do not fight the syntax differences in the different databases, you will not win. It's a better idea to put up with and use those differences to your advantage as much as possible.
我会研究 SQL ANSI 标准规范并使用其中指定的数据类型。 这样的书可能会对您有所帮助。
它们都有很好的文档，所以我只会阅读它们的数据类型。可能会有您需要的所有信息。我之前能找到的唯一的其他信息是相当旧。
希望有帮助。
编辑：只是另一个想法...您可以使用 SQL 的策略模式，这样即使不同也没关系，您可以使用更高级的功能。虽然这样你会有更多的工作要做和更多的维护：/
I'd look into the SQL ANSI standard specification and use the data types specified there. A book like this may help you.
They all have good documentation, so I would just read up on their data types. Would probably have all the info you need. The only other information I could find before is pretty old.
Hope that helps.
Edit: Just another thought... you could use the strategy pattern for your SQL, that way it wouldn't matter if it was different, you could use the more advanced features. Though this way you'd have more work to do and more to maintain :/