不同角色的數據建模
這是我在這裡的第一篇文章，所以我希望它足夠清楚。我想為銷售、購買、出租和修理某種產品的人申請。
我需要創建一個數據庫來保存產品和帳戶的數據（帶有登錄名和個人資訊）。我的問題在這裡，一個“賬戶”可以是賣家、買家、租客、修理者，可以是全部、沒有或部分。賣家、買家、租客和修復者會有不同的欄位，就像賣家可以發布產品，並保存一些只有賣家才能擁有的資訊，修復者只能發布他的列表，但賣家，也可以是固定器。買家也可以銷售產品並喜歡其他人。賣家和買家的區別在於賣家必須是公司，等等……
我對數據庫的想法是這樣的：
產品
product_id product_name owner_id (account_id)賬戶
account_id email password賣方
seller_id account_id business_name address [some fields that only sellers would have...]買方
buyer_id account_id first_name last_name address [some fields that only buyer would have...]承租人
renter_id account_id business_name address [some fields that only renter would have...]凝視
fixer_id account_id business_name address years_experience [some fields that only fixers would have...]然後是 account_favorite 等其他表格（保存有關哪些產品被選為收藏的資訊）。
現在，我覺得我這樣做的方式不是正確的方式。還認為，如果將來，我會考慮其他東西，例如“收藏家”，我將不得不創建一個新表。因為這是一個將被很多人使用的應用程序，所以我必須關心速度，但我也必須關心維護和分析數據的人。我希望這個文章很清楚，如果不是，請問我。
我不是 ERD 和數據庫設計方面的專家，但這是我對您的案例的看法：
如果需要，您可能希望有一個名為 role 的表，其中包含 id、角色名稱和更多列來描述角色。然後是一個通用“使用者”的表。該使用者可以是修復者、買家、賣家……現在有些列將適用於某個角色，有些列可能不像您在問題中描述的那樣。我認為這可以使用可為空的列進行建模，並通過強制執行您可能希望放入業務邏輯模型中的規則在您的應用程序中處理。我認為這可能是一個簡單的解決方案。
一種先進的技術是使用子類型/超類型對 ERD 進行建模。本文件對您了解/實踐如何建模“可選”數據非常有用：
http://sd271.k12.id.us/lchs/faculty/bkeylon/Oracle/database_design/section12/dd_s12_l04.pdf
如果使用者可以扮演的角色非常不同，那麼是的，你在正確的軌道上。他們有共同的領域，然後把它們放在共享
Accounts表中。如果這在各種角色表中只剩下幾個欄位，您可能應該放棄它們，只使用一個Accounts帶有一些備用列的表。權衡是更多表的複雜性更高，但（可能）一些窄表比單個寬和長表具有更好的性能。我通常傾向於從更簡單的模型開始，然後僅在必要時優化性能，但考慮到重構數據庫的痛苦，使用您從一開始就描述的更靈活的模型可能是值得的。