重新設計一個有很多列的表（並不總是相關的）
我是數據庫的新手，所以如果我說任何荒謬的話，我深表歉意..
我在一家為某個行業運營網站的公司工作。目前我們的規模不是很大，但我們的母公司希望將我們的產品推向更多地方。我對此很擔心，因為我們的數據庫在設計時從未考慮到任何計劃（例如，不存在規範化，大約 400 個表中可能有 70 個未使用的表 - 我們使用的表上有更多未使用的列，等等.,) 並且我們在一個非常糟糕的數據庫程序（普遍的 SQL）上執行。
該公司至少已經認識到需要擺脫普遍存在的問題。我們打算去mariadb。為此，有一個難得的機會可能重新設計數據庫的某些部分（或全部），但沒有人真正關心它 - 這就是我最終來到這裡的原因。
所以，說了這麼多，我只是想知道到目前為止我的重新設計是否走在正確的軌道上。
假設我們有一個表格，其中包含我們系統上公司的基本設置。其中一些設置與通知相關（即哪些事件將為他們觸發電子郵件），一些與計費有關，一些與他們如何創建訂單/他們在訂單上看到什麼資訊等有關，此表有 334 列並且其中很大一部分只儲存一個可以是 Y/N 的 CHAR(1)。（旁注：我是否正確假設 BIT 會佔用更少的空間？）
我一直在做的是分離部分（即，訂單設置進入他們自己的 company_order_settings 表中，其中包含公司的 id）。唯一的問題是，此時我已經為這些不同的設置準備了大約 8 個表……這正常嗎？一般來說，這些東西（通常）會被單獨訪問，所以我不關心大型連接。當我重構使用者表時，也會出現大量與設置相關的表（這些表保存了上述公司使用者的資訊——在相似數量的列中）。
如果有人想了解更多資訊，請告訴我。
不是一個真正的答案 - 但對於評論來說太大了。只是一些想法/討論。
“我們的數據庫在設計時從未考慮過任何計劃” - 我聽到了，姐姐！
去過也做過。曾經使用過 Btrieve（Pervasive 的前身）系統，該系統在一個表中包含 35,000 個（不是拼寫錯誤，即 35,000 個）欄位。同意@timpone - 對超過 30 個欄位的表格猶豫不決。桌子應該像女人一樣——又高又瘦，而不是又矮又胖:-)。
重新設計的工作量很大。從核心功能開始——最少需要多少張表？如果我是你，我會考慮使用 PostgreSQL，但就像 @Austin 一樣，這只是我的看法。
閱讀不同的 RDBMS - 檢查它們的功能。Btrieve 有什麼他們做/不做的事情嗎？據我所知，Btrieve 帶給聚會的主要東西是數組——它們違反了關係模型，在 RDBMS 中應該不惜一切代價避免。
你說“它們中的大量只儲存一個可以是 Y/N 的 CHAR(1)。（旁注：我假設 BIT 佔用更少的空間是正確的嗎？）”。如今，由於空間如此便宜，這並不是一個真正的問題。