Varför i hela friden skulle jag ha_många relationer?

Att bädda in en datastruktur i ett fält kan fungera för enkla fall men det hindrar dig från att dra nytta av relationsdatabaser. Relationsdatabaser är utformade för att hitta, uppdatera, ta bort och skydda dina data. Med ett inbäddat fält som innehåller sina egna wad-o-data (array, JSON, xml etc), avslutar du med att skriva all kod för att göra detta själv.

Det finns fall där det inbäddade fältet kan vara mer lämpligt, men för den här frågan som ett exempel kommer jag att använda ett fall som belyser fördelarna med en relaterad tabellmetod.

Föreställ dig ett exempel på användare och inlägg för en blogg.

För en inbäddad postlösning skulle du ha en tabell ungefär så här (psuedocode - dessa är förmodligen inte giltiga ddl):

create table Users {
id int auto_increment,
name varchar(200)
post text[][],
}

Med relaterade tabeller skulle du göra något liknande

create table Users {
id int auto_increment,
name varchar(200)
}
create table Posts {
id auto_increment,
user_id int,
content text
}

Verktyg för objektrelationell kartläggning (ORM) :Med det inbäddade inlägget kommer du att skriva koden manuellt för att lägga till inlägg till en användare, navigera genom befintliga inlägg, validera dem, ta bort dem etc. Med den separata tabelldesignen kan du utnyttja ActiveRecord (eller vilket objektrelationssystem du än använder) verktyg för detta som borde göra din kod mycket enklare.

Flexibilitet :Föreställ dig att du vill lägga till ett datumfält i inlägget. Du kan göra det med ett inbäddat fält, men du måste skriva kod för att analysera din array, validera fälten, uppdatera befintliga inbäddade inlägg etc. Med den separata tabellen är detta mycket enklare. Låt oss dessutom säga att du vill lägga till en redigerare till ditt system som godkänner alla inlägg. Med det relationella exemplet är detta enkelt. Som ett exempel för att hitta alla inlägg som redigerats av 'Bob' med ActiveRecord, behöver du bara:

Editor.where(name: 'Bob').posts

För den inbäddade sidan måste du skriva kod för att gå igenom alla användare i databasen, analysera vart och ett av deras inlägg och leta efter 'Bob' i redigeringsfältet.

Prestanda :Föreställ dig att du har 10 000 användare med i genomsnitt 100 inlägg var. Nu vill du hitta alla inlägg gjorda på ett visst datum. Med det inbäddade fältet måste du gå igenom varje post, analysera hela arrayen av alla inlägg, extrahera datumen och kontrollera den du vill ha. Detta kommer att tugga upp både cpu och disk i/0. För databasen kan du enkelt indexera datumfältet och ta fram de exakta poster du behöver utan att analysera varje inlägg från varje användare.

Standarder :Att använda en leverantörsspecifik datastruktur innebär att det kan vara jobbigt att flytta din applikation till en annan databas. Postgres verkar ha en rik uppsättning datatyper, men de är inte samma som MySQL, Oracle, SQL Server etc. Om du håller dig till standarddatatyper kommer du att ha mycket lättare att byta backends.

Det här är huvudproblemen jag ser utanför toppen. Jag har gjort det här misstaget och betalat priset för det, så om det inte finns en övertygande anledning till att göra något annat, skulle jag använda den separata tabellen.