创建支持多个数据库的SQL变量字符列>255个字符

Question

我有一个应用程序，它通过用户选择的ODBC数据源存储数据。到目前为止，它在一系列数据库系统(例如JET、Oracle、Server)上运行良好，因为SQL语法相当简单。

现在我遇到了一个问题，我需要在我的字符串中存储超过255个字符。之前，我使用列类型VARCHAR (255)创建了表。

现在，如果我尝试使用VARCHAR (512)创建一个表，那么它就落在Access数据库上了。我知道我可以使用备忘录类型进行访问，但这是非标准的SQL，因此可能会在其他数据库系统(例如Oracle)上失败。

是否有任何广泛支持的SQL标准用于创建大于255个字符的文本列，还是需要找到其他解决方案？在我看来，替代办法是：

1)对数据库系统进行剖析，并根据数据库系统定制SQL创建表命令。我不喜欢这样做，因为它违背了使用ODBC的目的。

2)根据需要添加255个字符的额外列(例如LONGSTRING1、LONGSTRING2、.)并在阅读后连在一起。我不喜欢这样做，因为这意味着表中的列数可能会有所不同，这会使读/写变得复杂。

除了这两种选择之外，还有其他可行的选择吗？或者，大多数数据库供应商都支持SQL兼容的CREATE命令，支持超过255个字符的字符串？

Answer 1

不是的。例如，在Hibernate中可以看到，它们对每个数据库都有一个配置，该配置自定义如何创建未绑定字符类型(除了许多其他特定于数据库的自定义)。

Answer 2

我可能被证明是错误的，但我认为对于存储任意大小的二进制对象的字段(这是一个大的字符串字段所存储的)，没有一个合适的标准。

Access - memo 
MSSQL - text 
ORACLE - text?

但是，与其根据数据库添加不同的列，不如使用一个单独的表，该表的主键有一个ID键，并将长文本存储在特定于数据库的字段中。这将给你更大的灵活性。

PS。请不要选择方案2。

Answer 3

海事组织，选项1是你最好的选择。我怀疑数据类型语法是否是您将遇到的唯一特定于数据库的异常。例如，许多数据库都有一种不同的方法来创建相当于Server的标识列(例如，在Access中它是一个AutoNumber)，前提是它们完全支持这种思想。正如其他人所指出的，即使在同一产品的不同版本之间，您也可能无法使用相同的语法并使其工作。此外，如果Jet将成为受支持的数据库之一，我保证您将遇到许多语法问题，这些问题在其他数据库产品中是可行的，但在访问过程中没有经过一些调整。不幸的是，ISO标准实际上只意味着数据库之间的语法将是相似的，而不是精确的。