我正在阅读Sybase ASE 15.7 文档中对datetime数据类型的描述：
datetime 列包含 1753 年 1 月 1 日和 9999 年 12 月 31 日之间的日期。在支持此粒度级别的平台上，日期时间值精确到 1/300 秒。
我觉得上面的内容很混乱。首先，这是唯一添加了“在支持这种粒度级别的平台上”警告的数据类型。这究竟是什么意思，我如何确定我的平台是否是“支持这种粒度级别”的平台之一？
此外，我不清楚能够有效地准确存储 1/300 秒意味着什么。我正在使用 JDBC 访问数据库，其中唯一合理的类型是java.sql.Timestamp。这种类型允许我检索到纳秒的精度。但考虑到在一般情况下，除以 300 需要十进制系统中的无限位数，实际上需要小数纳秒（具有无限十进制数字）来保持表示为 1/300 秒的值。所以，这意味着我无法在不损失一些精度的情况下获取存储在服务器中的值，但可以忽略不计。
最后，当我执行以下查询时：
SELECT convert(char(32), submission_date, 139) FROM some..table
我看到如下值：
Jan 6 2014 12:36:12.420000
Sep 12 2013 13:44:57.100000
Sep 10 2014 13:47:02.240000
Sep 10 2014 13:47:07.850000
Sep 10 2014 13:47:13.346000
Sep 10 2014 13:47:19.033000
Sep 10 2014 13:47:24.533000
Sep 10 2014 13:47:30.030000
Sep 10 2014 13:47:35.636000 …PostgeSQL 有一些非常丰富的字段和行大小限制（分别为 1GB 和 1.6TB）。
另一方面，Sybase ASE 的行大小限制在 4 或 8KB 左右。
例如，在 Sybase ASE 15.7 上我看到：
sqldev.mydatabase.1> create table foo2(a VARCHAR(7000));
Warning: Row size (7034 bytes) could exceed row size limit, which is 1962 bytes
这不仅仅是关于性能的警告，因为当我尝试插入大于 1962 字节的内容时，它实际上是强制执行的：
Attempt to update or insert row failed because resultant row of size 4462 bytes is larger than the maximum size (1962 bytes) allowed for this table.
Command has been aborted.
我猜由于共同的传统，类似的限制适用于 SQL Server，谷歌似乎同意（但我没有在 SQL Server 上尝试过）。
我假设这种巨大的差异一定是一些截然不同的架构决策或一些基本权衡的结果，这些权衡是由每个 RDBMS 以不同方式决定的。如果这是正确的，那将是什么权衡或架构决策？