我不是一个数据库专家，所以我想要一些建议。这些表对于SQL Server或Oracle来说太大了吗
背景
我们当前存储在Sybase IQ中4个表。我们目前没有任何选择，我们基本上坚持别人为我们决定的东西。 Sybase IQ是一个面向列的数据库，非常适合数据仓库。不幸的是，我的项目需要做很多事务性更新（我们更多的是一个可操作的数据库），所以我正在寻找更多的主流替代品。
问题
鉴于这些表的因素，会有人考虑SQL Server或Oracle是一个可行的选择？
鉴于数据的大小，在数据库选择，服务器配置，内存，平台等方面我应该关注哪些事情？
是，两者都应该能够处理你的表（如果你的服务器适合于它）。但是，我会考虑重新设计你的数据库。即使在您将数据非规范化的数据仓库中，具有453列的表格也不正常。
相信与否数据是正常化的！这是人口普查数据，例如人们的表格有很多变数。我们会根据特定主题（在其他表格中）进一步细分数据，但这对我们来说并不总是一干净利落。不过谢谢你的建议！ – 2009-11-26 15:55:49
对于作为Sybase IQ的*列导向*数据库，这不是问题。 – 2009-11-26 19:07:42
这是一个“经验法则”（因此：总是有例外情况，例如Cameron的情况），如果你的表有很多列（例如> 30），那么它可能代表多种类型的实体。例如，在人口普查数据中，我想知道对于每个人来说，所有这些列是否总是非空？也许有些人的某些专栏不适用？如果是这样的话，这些可以移动到单独的表格。我不是说这个必须发生，只是一个建议。 – 2009-11-27 04:00:03
随着大小合适的硬件和I/O子系统，以满足您的需求都是相当充足 - Wihlst你有很多列的行数都是真的很低 - 我们regularily使用在数十亿美元表示的数据集，不是数百万。 （不要尝试在SQL 2000 :)）
如果你知道你的用途和I/O的要求，大多数I/O厂商将它转换成硬件规格为您服务。内存，处理器等又取决于只有您可以建模的工作负载。
谢谢，我认为工作量是主观的，但无论如何都把它抛出去......以防万一！ – 2009-11-26 15:56:57
的Oracle 11g具有与这样的数据和结构没有问题。 http://neworacledba.blogspot.com/2008/05/database-limits.html
问候：在
更多信息。
这真的取决于列中的内容。如果有很多大的VARCHAR列 - 并且它们经常被充满到接近容量 - 那么你可能会遇到一些问题。如果它是全部整数数据，那么你应该没问题。
453 * 4 = 1812 # columns are 4 byte integers, row size is ~1.8k
453 * 255 = 115,515 # columns are VARCHAR(255), theoretical row size is ~112k
经验法则是，行大小不应超过磁盘块大小，其通常为8K。正如你所看到的，如果你的大表完全由4字节整数组成，但如果它由255个字符的VARCHAR列组成，那么你可能会超出极限。这个8k限制曾经是SQL Server中的一个硬限制，但我认为现在这只是一个软限制和性能指南。
请注意，VARCHAR列不一定会消耗与您为其指定的大小相称的内存。这是最大尺寸，但他们只消耗尽可能多的。如果VARCHAR列中的实际数据总是3-4个字符，那么无论您是将它们创建为VARCHAR（4）还是VARCHAR（255），大小将与整数列的大小类似。
一般规则是，您希望行大小很小，以便每个磁盘块有许多行，这样可以减少扫描表所需的磁盘读取次数。一旦你达到8K以上，你就有两行读取。
Oracle有另一个潜在的问题，即ANSI连接对连接中所有表中的列总数有严格的限制。您可以通过避免Oracle ANSI连接语法来避免这种情况。 （有些东西没有受到这个错误的影响。）我不记得这个限制是什么或者它适用于哪个版本（我认为它还没有被修复）。
你说的行数应该没问题，假设你有足够的硬件。
非常有用的答案！谢谢 – 2009-11-26 21:10:47
你可能会关闭SQL Server上，这取决于你在这453列的表的数据类型（注意每行限制的字节，但也可以参考脚注）。我知道你说这是正常化的，但我建议看看你的工作流程并考虑减少列数的方法。
此外，这些表格足够大，以至于硬件方面的考虑是性能的主要问题。您需要一位经验丰富的DBA来帮助您规范并使用RDBMS设置服务器。正确配置您的磁盘子系统至关重要。您可能还需要考虑表分区以帮助提高性能，但这完全取决于数据的使用方式。
所有这些表中的所有列是否都由应用程序更新？
您可以考虑在白天更新数据集市（AKA运营或在线数据存储），然后在晚上将新记录迁移到主仓库？我这样说是因为具有大量列的行插入和更新的速度会更慢，因此您可能需要考虑根据应用程序的更新要求定制特定的联机体系结构。
不，我们一次只更新少数几列。 – 2009-11-26 21:14:19
如果是这样的话，那么一个用于更快更新的在线数据存储/数据集市可能是一条可行的路线，那么在设计决策背后拥有数据仓库理论的优势，以及ETL工具和数据建模的悠久历史你可以阅读并应用到你的体系结构中的技术（并且对于其他人重新查看它会很熟悉）。 我会说，在你对你将要使用的架构有一个粗略的概念之前，不应该决定数据库供应商的选择。 – 2009-11-27 08:50:18
要求一个DB同时充当运营和仓库系统仍然是一个很高的要求。我会考虑使用SQL服务器或Oracle作为操作系统，并且有一个单独的DW用于报告和分析，可能会保留您的系统。
期望在操作端发生一些表重新设计和规范化操作，以适应基于行的存储每页一行的限制。
如果您需要快速更新DW，则可以考虑使用EP for ETL方法，而不是标准（预定）ETL。
考虑到您处于早期阶段，请参阅Microsoft project Madison，这是可自动扩展的DW设备，最高可达100秒TB。他们已经出货了一些装置。
我会仔细考虑从列式数据库切换到关系型数据库。面向列的数据库确实不足以用于运营工作，因为更新速度非常缓慢，但它们足够用于报告和商业智能支持。
往往不得不将操作工作分解到包含操作（帐户，库存等）所需的当前活动的OLTP数据库中，并使用ETL过程来填充数据仓库（历史，趋势）。面向列的DW在几乎任何情况下都会打破关系，所以我不会轻易放弃Sybase IQ。也许你可以设计你的系统使用你选择的关系产品（我会选择SQL Server，但我有偏见）拥有一个可操作的OLTP端，并保持你现在拥有的OLAP部分。
这是一个很好的想法，谢谢。我不认为使用面向列的数据库的速度提高会超过使用更频繁使用的数据库的效率（单独使用工具集，更不用说更新速度更慢！）。 – 2009-11-26 21:13:49
根据在其他答案我想我会建议您的意见是：
1）分离物，它的数据实际上是对更新的数据或多或少只读（或很少） 2）将更新后的数据移动到单独的表上，将表中的ID加入到较大的表中（从大表中删除这些列） 3）针对较小的更多关系表执行OLTP事务 4）使用内部连接回退到大型表格在必要时检索数据。
正如其他人已经注意到，你正试图让数据库同时做OLTP和OLAP，这是很困难的。对于任何一种情况，服务器设置都需要进行不同的调整。
SQL Server或Oracle应该工作。我也使用人口普查数据，我的giganto表格大约有300多列。我使用SQL Server 2005，它抱怨说，如果所有列都被填充到它们的容量，它将超过记录的最大可能大小。我们以OLAP方式使用我们的人口普查数据，因此拥有如此多的专栏并不是什么大不了的事情。
有趣，谢谢！ – 2009-11-26 21:14:56
Sybase有一个名为RAP的产品，它将IQ与内存中的ASE（其关系数据库）实例相结合，旨在帮助解决此类情况。
您的数据不是很广泛，您不能考虑转移到面向行的数据库，但根据数据的结构，最终可能会使用更多的磁盘空间并放慢多种查询。
声明：我为Sybase工作，但目前不在ASE/IQ/RAP方面。
为什么地球上有一张453列的桌子？你的表是否正常化？他们可以进一步正常化吗？ – 2009-11-26 15:38:26
@Dominic - 因为Jeffrey的数据库使用的Sybase IQ是“面向列的数据库”。面向列的数据库的重点在于它们拒绝了“正常化”的整个概念。至少，正如关系数据库中所理解的那样。 – APC 2009-11-26 16:14:00
只是要清楚 - 您是否希望将现有模式移植到新数据库？如果是这样，为什么？如果您在使用OLTP时遇到问题，很可能是表设计问题，而不是DBMS产品问题。如果您给我们更多背景，我们可以更好地为您提供建议。具体来说，你遇到了什么问题？您希望从Oracle或MSSQL迁移中获得什么优势？ – APC 2009-11-26 16:20:03