多個大型列表的數據庫設計模式

Question

考慮一個旅程行程。遊覽中有20個可能的站點。標準遊覽包括1至20站。但是，每個用戶可以按任意順序創建包含5個或更多站點的自己的導覽，並可能重複播放。在數據庫中對此進行建模的最有效方法是什麼？

如果我們使用一個連接表
user_id, stop_id, order
我們將有百萬條記錄得很快，但我們可以很容易地拉即停上查詢&用戶屬性。

如果我們存儲解數爲數組，
user_id, stop_id_array_in_order
我們有一個更小的，非標準化的表，我們不能輕易訪問停止屬性。

是否有其他選項允許在最小化表大小的情況下訪問父屬性？

Answer 1

你在想，節省一些空間會幫助你。它不會。這也是可以爭論的，你實際上可以節省多少空間。

您還將使用無序數據結構 - 這是你不想要的東西。你想要訂購結構（表），它可以與其他記錄相關 - 這正是我們對錶進行歸一化的原因 - 所以我們可以推斷所有類型的數據而不會改變物理位置。另一個好處是可以對有序結構進行索引，並且可以減少查找記錄的時間。權衡是花費空間來保持指數記錄。

然而，數以百萬計，數十億甚至數萬億行都可以。試想一下，查詢一個數組在列（或多列）中作爲逗號分隔列表保存的結構是多麼困難。編寫查詢將是一場噩夢，隨着記錄數量的增加，性能會呈線性下降。

TL; DR：保持標準化。

Answer 2

數據庫大小約爲無優先的時間。易於訪問的數據是優先約每百分之的時間。

Answer 3

我會定義實體，當你在第一個例子描述爲他們創建的表在不同的表之間的關係：

users table 
tours table 
stops table 
tours_users table (a User can go to a Tour more than once) 
stops_order table: stop_id, order, tours_users_id 

用於查詢的表中，要檢查他們的任何用戶您可以通過tours_users表實現此目的，如果需要檢索站點，則可以通過tours_users_id輕鬆加入tours_users表格與stops_order表格。

如果表格索引正確，應該沒有性能問題，您將按照您的設想使用關係數據庫引擎。