我有一个应用程序，它通过用户选择的ODBC数据源存储数据。到目前为止，它在一系列数据库系统（例如JET，Oracle，SQL Server）上运行良好，因为SQL语法相当简单。
现在我遇到了一个问题，我需要在我的字符串中存储超过255个字符。以前我使用列类型 VARCHAR（255）创建了表。
现在，如果我尝试使用例如创建表格， VARCHAR（512）然后它落在Access数据库上。我知道我可以使用 MEMO 类型进行访问，但这是非标准SQL，因此可能在其他数据库系统（例如Oracle）上失败。
是否有广泛支持的SQL标准用于创建超过255个字符的文本列，还是需要找到其他解决方案？在我看来，替代方案是：
1）配置数据库系统并根据数据库系统自定义SQL CREATE TABLE 命令。我不喜欢这个，因为它违背了使用ODBC的目的。
2）根据需要添加255个字符的额外列（例如 LONGSTRING1，LONGSTRING2，... ）并在阅读后连接。我不喜欢这个，因为这意味着列之间的列数可能会有所不同，这会使读/写变得复杂。
这两种选择还有其他可行的替代方案吗？或者是否可以使大多数数据库供应商支持符合SQL的 CREATE TABLE 命令，该命令支持长度超过255个字符串的字符串？
答案 0 :(得分：1)
没有。例如，在Hibernate中可以看到，它们为每个数据库配置了一个配置，用于自定义如何创建未绑定的字符类型（除了许多其他特定于数据库的自定义）。
答案 1 :(得分：1)
我可能被证明是错误的，但我认为在存储任意大小的二进制对象的字段（这是一个大字符串字段将被存储为的字段）中没有适当的标准。
Access - memo
MSSQL - text
ORACLE - text?
但是，不是根据您使用的数据库添加不同的列，而是使用一个单独的表，该表具有主键的ID键，并将长文本存储在特定于数据库的字段中。这将为您提供更大的灵活性。
PS。请不要选择2。
答案 2 :(得分：1)
IMO，选项＃1是您的最佳选择。我怀疑数据类型语法将是您将遇到的唯一数据库特定异常。例如，许多数据库都有不同的方法来创建等效的SQL Server标识列（例如，在Access中它是一个自动编号），假设它们完全支持这个想法。正如其他人所指出的那样，即使在同一产品的版本之间，您也可能无法使用相同的语法并使其工作。此外，如果Jet将成为受支持的数据库之一，我保证您会遇到大量语法问题，这些问题在其他数据库产品中有效，但在Access中没有进行一些调整。不幸的是，ISO标准实际上只意味着数据库之间的语法类似不完全。