我正在使用 Laravel 8 嘗試創建一個資料庫設計，結果證明是一對一的多型關系（以前從未使用過）。但是在這里看到 Laravel 的檔案，我不禁想知道為什么不制作具有一對一多型關系的表，如下所示：
images
id - integer
url - string
imageable_type - string
posts
image_id - integer
name - string
users
image_id - integer
name - string
與image_idinposts并users設定為外主鍵，指的是images's id。這種方法背后的想法是因為這些表之間的關系是一對一的，因此posts并不users需要它們自己的 id。
image_id此外，這種方法將允許我添加約束
$table->foreignId('image_id')->constrained();
$table->unique(['image_id']);
我相信這是可行的。但是，您對此有何見解？使用這種方法有什么我想念的嗎？你認為這是未來的證明嗎，比如將來添加一個新的子模型？在這種方法和 Laravel 在其檔案中所寫的方法之間，你會選擇哪一種？
編輯
閱讀@AlexMax 的評論，我現在意識到我的概念被顛覆了！Laravel 的示例將images視為孩子；在我的范式中，posts并被users視為孩子。也許我應該將示例案例更改為：
documents
id - integer
type- string
document_type - string
document_type_a
document_id - integer
name - string
document_type_b
document_id - integer
name - string
附帶說明：每次documents創建新記錄時，它都會為其其中一個孩子創建一個新記錄（由應用程式處理）。在這種情況下，孩子是document_type_a和document_type_b。將根據 的 確定使用哪type一個documents。
那么，回到這個問題：你怎么看？
另外：這仍然被認為是多型關系嗎？
uj5u.com熱心網友回復：
您可以采用這種方法，但我相信未來的證明。通過創建主 uuid 可能會在未來為您提供靈活性。您還創建了一個反向依賴關系，即如果用戶存在，它必須有一個 image_id。無論這是否是意圖，它很可能會被設計成那樣閱讀。我所說的未來證明的意思是，您希望在您的資料庫中關閉以進行修改并打開以進行擴展。例如，如果您只有一個多型表和創建主鍵，您不必修改預先存在的代碼，而是創建一個新類、表（針對該類）和關系，而無需更改影像中的一行代碼上課他們的方式你目前正在做的形象需要注意。因此，您將被迫為每個具有與之關聯的影像的類具有特征。您還會丟失影像的歷史記錄。例如，用戶更改了他們的個人資料圖片，您只能參考最后一張圖片與圖片歷史記錄。
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/452481.html