我應該如何爲這個問題設計數據庫結構？

Question

我正在重建具有大量流量的網站的後臺系統。

這是應用程序的核心，我構建這部分數據庫的方式對於大量代碼和即將開展的工作至關重要。下面描述的系統每天需要運行數百萬次。我很感謝在這個問題上的任何投入。

背景是用戶可以添加他或她在白天吃的東西。

簡化，該過程或多或少是這樣的：

1. 用戶到達該網站，該網站列出了他/她的選擇爲天（如果進入之前下面介紹的步驟）。
2. 用戶可以添加一頓飯（由1組成的無限量的不同食物及其數量）。餐點通過搜索字段添加，並按不同類型組織（如「早餐」，「午餐」）。
3. 在膳食建設過程中，會顯示最常用的食品列表（主要由該用戶，其次爲所有用戶），以便快速選擇。
4. 膳食將存儲在一個FoodLog表中，其中包含如下內容：id, user_id, date, type, food_data。

我目前擁有的是一個龐大的數據庫與食品項目進行搜索。食物項目儲存有關於常用名稱（如「豬排」）和生產者（如「可口可樂」）的信息以及所需的其他詳細信息。

問題總結：

我的問題是，我不知道存儲數據的最佳方式爲它在我需要的方式，並沒有數據庫走出去的手方便。

考慮一百萬用戶每天增加1至7餐。爲了存儲每餐中的每個食物，每天和每個用戶每天可能創建（1 * avg_num_meals * avg_num_food_items）百萬行。

以某種壓縮方式存儲數據（如food_data是一個json_encoded字符串），會顯着減少行數量，但同時使其難以創建「最常用的食品」列表和其他即時統計。

該表應該分成幾個表嗎？如果是這樣，他們將如何互動？

該網站目前託管在中檔CDN上，並且使用LAMP（Linux，Apache，MySQL，PHP）骨幹網。

Answer 1

粗略地說，你需要一個完全標準化的數據結構。你想有一個用戶表，一個Meals表（每餐一餐，參考用戶;你可能還想在這個表中有一個時間/日期）和一個MealItems表，簡單地說就是Meal和Food Items表中的關聯表。

因此，當用戶進來並創建一個帳戶時，您在用戶表中輸入一個條目。當用戶報告他們吃過的餐食時，您會在膳食表中創建一條記錄，並在MealItems表中爲他們報告的每個條目創建一條記錄。

這種結構使得每餐都有可變數量的物品，而不浪費大量空間。您可以使用相對簡單的查詢來確定正餐中物品的表示形式，以及確定任何一個用戶在任何給定時間段內消費的全部物品集合。

這個規範化的表結構將支持大量的記錄並支持大量的數據庫查詢。

Answer 2

我會把你的餐桌分成兩張桌子，一張桌子爲每頓飯儲存一行，第二張桌子爲每餐中使用的每種食物儲存一行，用於英寸

之後，只要確保您在連接或WHERE子句中使用的任何表列的索引。

Answer 3

除了什麼是been said：

• 在你使用索引的明智。正確地將這些應用於您的數據庫可以顯着加速對錶格的讀取訪問。
• 考慮使用特定於語言的功能來最小化空間。你提到你使用的是mysql;在適當的時候考慮使用ENUM（食物類型，膳食類型）以最小化數據庫大小並簡化管理。

Answer 4

首先，

存儲在某種壓縮方式的數據（如food_data是 json_encoded字符串）

是不推薦的想法。隨着新的要求的增加，這將會導致你在將來無數的頭痛。

你應該在這裏肯定有幾張表。

Users 
id, etc 

Food Items 
id, name, description, etc 

Meals 
id, user_id, category, etc 

Meal Items 
id, food_item_id, meal_id 

膳食項目將使用ID將膳食與食品項目聯繫起來。 Meals將與使用ID的用戶綁定。這使得使用連接變得非常簡單，以便獲得數據彙總，平均值等的詳細列表。如果這些字段被正確編制索引，這應該是支持大量記錄的很好的模型。