如何建構主要記錄很大的數據庫
我想知道我是否可以要求一些快速的意見。
我正在設計一個看起來很簡單的應用程序原型，但我不能輕易得出一個感覺正確的架構。
我們擁有簡單且非常適合標準 sql 格式的數據，例如使用者、組織、項目、報告。
然而，“報告”是問題所在。它們通常介於 1000 到 100,000 個“訂單項”之間。每個項目大約有 10 個欄位。有點像一個大的電子表格，實際上這就是它們通常的來源。
一個使用者（假設其中 100 個）每年生成 10 個項目，每個項目有 10 個報告，每個報告有 10000 個項目（或行）.. 那麼如果有一個巨大的表快速增長到數百萬行，每一行都“屬於”報告等..這感覺不對。
為了使這更棘手，報告本身幾乎可以被視為“迷你數據庫”，因為儘管數據的核心是數千個“行項目”（具有統一的列要求），但它們被結構化為“區域” , ‘sections’, ‘subsections’, 還有一個 ‘overview/meta’ 部分。
從理論上講，我可以將這個權利從“使用者”規範化為“項目”，比如 users->projects->reports->zones->sections->subsections->items ……但這又感覺不對我; 數據庫必須做的只是去獲取報告似乎有點矯枉過正。此外，所有這些報告資訊都將針對所有不同的使用者帳戶混合在一起。
每個報告查詢都必須從數百萬行中收集數千行，並從不同的表中組裝客戶端 json，並且能夠以這種方式查詢表並沒有其他真正的好處。所有的報告都是獨立的。
因此，我想知道這是否是 nosql 路由的情況，例如 mongo 或 documentDB，我可以在報告集合或類似物中拋出數千行 json。不過，這會產生進一步的影響，因為我喜歡使用的後端框架在 nosql 上表現不佳，而且我們失去了一些標準的簡單關係模式，這些模式似乎仍然適合應用程序的其他表（例如使用者帳戶、RBAC、屬於組織的使用者等）。
..但是對於json儲存也會有類似的問題..保持“樹”結構，並將所有行項目保留在其部分內，並將部分保留在其區域內等，或者標準化以便有一個更好嗎？大量的項目，其中引用了它們的部分，等等。
我已經搞砸了對所有事情都使用 MySQL，並使用 json 欄位類型將報告儲存為一個大 json，但我不知道這是否有點推動了欄位類型的意圖，而且很難查詢進去。
這裡需要考慮的是，在前端，使用者一次會更新一行（或幾行），我需要能夠處理這個問題。通過這種方式，我想與 google sheet 或 airTables 或其他東西有相似之處。這些大應用程序是否傾向於使用rdbms？
我注意到現在似乎有越來越多的數據庫選項出現，例如動物 supabase 等 .. 使得選擇正確的解決方案變得更加棘手。
提前感謝您的任何提示
NoSQL不是針對大量數據問題的直接解決方案，而是主要針對無模式或高度可變的模式問題的解決方案（正如您在說“我們失去了一些標準的簡單關係模式”時所經歷的那樣）關於使用NoSQL）。因為您承認您的數據是高度相關的，適合標準模式，所以您可能希望繼續使用像 MySQL 這樣的RDBMS 。
話雖這麼說，一個表中的數百萬行是很小的一面，當適當地建構和索引時，關係數據庫當然不用擔心。如果我用上面的範例數字進行計算，看起來我們實際上是在談論每年 1億條記錄，現在我主觀地認為這是一個中等大小的表。表格的寬度只有 10 列，這一事實也有助於保持緊湊。對於任何現代RDBMS來說，這仍然沒有問題。我親自使用過數十億的大型表格記錄，大約 50 列寬，即使在這種規模下，正常 B-Tree 索引仍然工作得非常好。在非常普通的硬體上，我可以在一秒鐘或更短的時間內從該表中查詢數千行，並在大約 10 秒內從該表中查詢數百萬行。
除了對數據庫進行適當的索引和架構之外，您還可以使用Partitioning之類的東西，並定期將不經常查詢的舊數據歸檔到單獨的表中。長話短說，聽起來你的架構是正確的，我不會過分強調你計劃支持的數據量，直到它變得有問題（我認為不會有問題）。
對於幾乎所有 rdms，10 列和數十億行都不是問題。
您可以保留結構，但您應該檢查是否可以規範化您的表格。
此外，您必須注意索引，它反映了您執行的查詢，以便性能不會因大小而受到太大影響。
僅當您不希望所有使用者都可以訪問數據時才需要劃分結構。
分區不會提高性能，但可以劃分數據。從此您應該查看手冊以獲取更多資訊