Das Einbetten einer Datenstruktur in ein Feld kann in einfachen Fällen funktionieren, hindert Sie jedoch daran, relationale Datenbanken zu nutzen. Relationale Datenbanken wurden entwickelt, um Ihre Daten zu finden, zu aktualisieren, zu löschen und zu schützen. Mit einem eingebetteten Feld, das seine eigenen Wad-o-Daten (Array, JSON, XML usw.) enthält, schreiben Sie am Ende den gesamten Code, um dies selbst zu tun.
Es gibt Fälle, in denen das eingebettete Feld besser geeignet sein könnte, aber für diese Frage werde ich als Beispiel einen Fall verwenden, der die Vorteile eines verwandten Tabellenansatzes hervorhebt.
Stellen Sie sich ein Benutzer- und Beitragsbeispiel für einen Blog vor.
Für eine eingebettete Post-Lösung hätten Sie eine Tabelle wie diese (Pseudocode - dies sind wahrscheinlich keine gültigen ddl):
create table Users {
id int auto_increment,
name varchar(200)
post text[][],
}
Bei verwandten Tabellen würden Sie so etwas tun wie
create table Users {
id int auto_increment,
name varchar(200)
}
create table Posts {
id auto_increment,
user_id int,
content text
}
Object Relational Mapping (ORM)-Tools :Mit dem eingebetteten Beitrag schreiben Sie den Code manuell, um einem Benutzer Beiträge hinzuzufügen, durch vorhandene Beiträge zu navigieren, sie zu validieren, sie zu löschen usw. Mit dem separaten Tabellendesign können Sie ActiveRecord (oder ein beliebiges objektrelationales System) nutzen verwenden) Tools dafür, die Ihren Code viel einfacher halten sollten.
Flexibilität :Stellen Sie sich vor, Sie möchten dem Beitrag ein Datumsfeld hinzufügen. Sie können dies mit einem eingebetteten Feld tun, aber Sie müssen Code schreiben, um Ihr Array zu analysieren, die Felder zu validieren, die vorhandenen eingebetteten Posts zu aktualisieren usw. Mit der separaten Tabelle ist dies viel einfacher. Nehmen wir außerdem an, Sie möchten Ihrem System einen Redakteur hinzufügen, der alle Beiträge genehmigt. Mit dem relationalen Beispiel ist das einfach. Um beispielsweise alle Posts zu finden, die von „Bob“ mit ActiveRecord bearbeitet wurden, brauchen Sie nur:
Editor.where(name: 'Bob').posts
Für die eingebettete Seite müssten Sie Code schreiben, um jeden Benutzer in der Datenbank zu durchlaufen, jeden ihrer Posts zu parsen und im Editor-Feld nach „Bob“ zu suchen.
Leistung :Stellen Sie sich vor, Sie haben 10.000 Benutzer mit jeweils durchschnittlich 100 Beiträgen. Jetzt möchten Sie alle Beiträge finden, die an einem bestimmten Datum erstellt wurden. Mit dem eingebetteten Feld müssen Sie jeden Datensatz durchlaufen, das gesamte Array aller Posts parsen, die Daten extrahieren und mit dem gewünschten überprüfen. Dies wird sowohl die CPU als auch die Festplatten-I / 0 verbrauchen. Für die Datenbank können Sie das Datumsfeld einfach indizieren und genau die Datensätze abrufen, die Sie benötigen, ohne jeden Beitrag von jedem Benutzer zu analysieren.
Normen :Die Verwendung einer herstellerspezifischen Datenstruktur bedeutet, dass das Verschieben Ihrer Anwendung in eine andere Datenbank mühsam sein kann. Postgres scheint eine Vielzahl von Datentypen zu haben, aber sie sind nicht mit MySQL, Oracle, SQL Server usw. identisch. Wenn Sie sich an Standarddatentypen halten, wird es Ihnen viel leichter fallen, Backends auszutauschen.
Das sind die Hauptprobleme, die ich von oben sehe. Ich habe diesen Fehler gemacht und den Preis dafür bezahlt, also würde ich die separate Tabelle verwenden, es sei denn, es gibt einen zwingenden Grund, etwas anderes zu tun.
