Indlejring af en datastruktur i et felt kan fungere i simple tilfælde, men det forhindrer dig i at drage fordel af relationelle databaser. Relationelle databaser er designet til at finde, opdatere, slette og beskytte dine data. Med et indlejret felt, der indeholder dets egne wad-o-data (array, JSON, xml osv.), afslutter du med at skrive al koden for at gøre dette selv.
Der er tilfælde, hvor det indlejrede felt kan være mere egnet, men til dette spørgsmål vil jeg som eksempel bruge en case, der fremhæver fordelene ved en relateret tabelmetode.
Forestil dig et bruger- og indlægseksempel til en blog.
For en indlejret post-løsning ville du have en tabel noget som denne (psuedocode - disse er sandsynligvis ikke gyldige ddl):
create table Users {
id int auto_increment,
name varchar(200)
post text[][],
}
Med relaterede tabeller ville du gøre noget lignende
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)-værktøjer :Med det indlejrede indlæg vil du skrive koden manuelt for at tilføje indlæg til en bruger, navigere gennem eksisterende indlæg, validere dem, slette dem osv. Med det separate tabeldesign kan du udnytte ActiveRecord (eller hvilket som helst objektrelationssystem du bruger) værktøjer til dette, hvilket skulle gøre din kode meget enklere.
Fleksibilitet :Forestil dig, at du vil tilføje et datofelt til indlægget. Du kan gøre det med et indlejret felt, men du bliver nødt til at skrive kode for at parse dit array, validere felterne, opdatere de eksisterende indlejrede indlæg osv. Med den separate tabel er dette meget enklere. Lad os desuden sige, at du vil tilføje en redaktør til dit system, som godkender alle indlæg. Med det relationelle eksempel er dette nemt. Som et eksempel for at finde alle indlæg redigeret af 'Bob' med ActiveRecord, skal du blot bruge:
Editor.where(name: 'Bob').posts
Til den indlejrede side skal du skrive kode for at gå gennem hver bruger i databasen, parse hver enkelt af deres indlæg og se efter 'Bob' i editor-feltet.
Ydeevne :Forestil dig, at du har 10.000 brugere med et gennemsnit på 100 indlæg hver. Nu vil du gerne finde alle indlæg lavet på en bestemt dato. Med det indlejrede felt skal du gå gennem hver post, analysere hele rækken af alle indlæg, udtrække datoerne og kontrollere den, du ønsker. Dette vil tygge både cpu og disk i/0 op. For databasen kan du nemt indeksere datofeltet og trække de nøjagtige poster ud, du har brug for, uden at parse hvert indlæg fra hver bruger.
Standarder :Brug af en leverandørspecifik datastruktur betyder, at det kan være besværligt at flytte din applikation til en anden database. Postgres ser ud til at have et rigt sæt af datatyper, men de er ikke de samme som MySQL, Oracle, SQL Server osv. Hvis du holder dig til standard datatyper, vil du have meget nemmere ved at bytte backends.
Det er de vigtigste problemer, jeg ser fra toppen. Jeg har lavet denne fejl og betalt prisen for den, så medmindre der er en overbevisende grund til at gøre noget andet, ville jeg bruge den separate tabel.