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

Question

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

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

现在，如果我尝试使用例如创建表VARCHAR (512) 然后它落在 Access 数据库上。我知道我可以将 MEMO 类型用于 Access，但这是非标准 SQL，因此可能会在其他数据库系统（例如 Oracle）上失败。

是否有任何广泛支持的 SQL 标准来创建超过 255 个字符的文本列，或者我需要寻找其他解决方案吗？在我看来，替代方案是：

1) 剖析数据库系统，根据数据库系统自定义SQLCREATE TABLE命令。我不喜欢这样，因为它违背了使用 ODBC 的目的。

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

这两个选项还有其他可行的替代方案吗？或者是否有可能有一个大多数数据库供应商都支持的符合 SQL 的 CREATE TABLE 命令，它支持超过 255 个字符的字符串？

Answer 1

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

Answer 2

IMO，选项 #1 是您的最佳选择。我怀疑数据类型语法将是您将遇到的唯一数据库特定异常。例如，许多数据库有不同的方式来创建等效于 SQL Server 的标识列（例如，在 Access 中它是一个自动编号），假设它们完全支持这个想法。正如其他人指出的那样，即使在同一产品的不同版本之间，您也可能无法使用相同的语法并使其正常工作。此外，如果 Jet 将成为受支持的数据库之一，我保证您会遇到很多在其他数据库产品中有效但在 Access 中不作一些调整的语法问题。不幸的是，ISO 标准实际上只意味着数据库之间的语法将相似并不精确。

Answer 3

我可能被证明是错误的，但我认为对于存储任意大小的二进制对象的字段（大型字符串字段将被存储为）没有适当的标准。

Access - memo 
MSSQL - text 
ORACLE - text?

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

PS。请不要选择选项 2。