Vložení datové struktury do pole může fungovat v jednoduchých případech, ale brání vám ve využívání výhod relačních databází. Relační databáze jsou navrženy tak, aby nacházely, aktualizovaly, odstraňovaly a chránily vaše data. S vloženým polem obsahujícím vlastní wad-o-data (pole, JSON, xml atd.) si celý kód zapíšete sami.
Existují případy, kdy by vložené pole mohlo být vhodnější, ale pro tuto otázku jako příklad použiji případ, který zdůrazňuje výhody souvisejícího přístupu k tabulce.
Představte si příklad uživatele a příspěvku pro blog.
Pro řešení vloženého příspěvku byste měli tabulku podobnou tomuto (psuedocode - pravděpodobně to nejsou platné ddl):
create table Users {
id int auto_increment,
name varchar(200)
post text[][],
}
Se souvisejícími tabulkami byste udělali něco jako
create table Users {
id int auto_increment,
name varchar(200)
}
create table Posts {
id auto_increment,
user_id int,
content text
}
Nástroje pro relační mapování objektů (ORM) :S vloženým příspěvkem budete ručně psát kód pro přidávání příspěvků uživateli, procházení existujících příspěvků, jejich ověřování, mazání atd. Se samostatným návrhem tabulky můžete využít ActiveRecord (nebo jakýkoli objektový relační systém, který k tomu používají) nástroje, díky kterým by měl být váš kód mnohem jednodušší.
Flexibilita :Představte si, že chcete k příspěvku přidat pole s datem. Můžete to udělat s vloženým polem, ale budete muset napsat kód pro analýzu vašeho pole, ověření polí, aktualizaci existujících vložených příspěvků atd. Se samostatnou tabulkou je to mnohem jednodušší. Kromě toho řekněme, že chcete do svého systému přidat editora, který schvaluje všechny příspěvky. Se vztahovým příkladem je to snadné. Jako příklad k nalezení všech příspěvků upravených 'Bobem' pomocí ActiveRecord byste potřebovali:
Editor.where(name: 'Bob').posts
Pro embedded stránku byste museli napsat kód, abyste procházeli každým uživatelem v databázi, analyzovali každý jeho příspěvek a hledali 'Bob' v poli editoru.
Výkon :Představte si, že máte 10 000 uživatelů, každý má průměrně 100 příspěvků. Nyní chcete najít všechny příspěvky hotové k určitému datu. S vloženým polem musíte procházet každý záznam, analyzovat celé pole všech příspěvků, extrahovat data a zkontrolovat ten, který chcete. To rozžvýká i/0 procesor i disk. V databázi můžete snadno indexovat pole data a vytáhnout přesné záznamy, které potřebujete, aniž byste museli analyzovat každý příspěvek od každého uživatele.
Standardy :Použití datové struktury specifické pro dodavatele znamená, že přesunutí aplikace do jiné databáze může být nepříjemné. Zdá se, že Postgres má bohatou sadu datových typů, ale nejsou stejné jako MySQL, Oracle, SQL Server atd. Pokud se budete držet standardních datových typů, budete mít mnohem jednodušší výměnu backendů.
To jsou hlavní problémy, které vidím shora. Udělal jsem tuto chybu a zaplatil jsem za ni cenu, takže pokud neexistuje velmi pádný důvod, udělejte jinak, použil bych samostatnou tabulku.