我不是一個數據庫專家，所以我想要一些建議。這些表對於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