Seonglae ChoCompared to normalization, it's convenient to have just one table, but many databases don't support it. DB-level automation is possible with triggers, but it's difficult with ORMs and debugging is complex
Vector Database
For production, when using pgVector in an RDBMS rather than a vector database, simply adding an embedding column to an existing table is a bad practice. This is because if you finetune or change the model, you have to regenerate embeddings in all tables, which is very unstable and difficult to manage during migration. Therefore, it's better practice to have a separate embedding table that references the original id table like a junction table. While you can have separate tables per entity, sharing the same table doesn't pose a Polymorphic FK problem in this case. When the embedding version changes, you can simply populate new rows and migrations can flow continuously. Additionally, you can delete stale entries after migration, making it much more stable. This solution also doesn't require column expansion even when multiple embedding types are added per table, and embeddings from multiple tables can be shared like ReBAC, which is an advantage.