Het inbedden van een gegevensstructuur in een veld kan voor eenvoudige gevallen werken, maar het voorkomt dat u profiteert van relationele databases. Relationele databases zijn ontworpen om uw gegevens te vinden, bij te werken, te verwijderen en te beschermen. Met een ingesloten veld met zijn eigen wad-o-data (array, JSON, xml enz.), schrijf je uiteindelijk alle code om dit zelf te doen.
Er zijn gevallen waarin het ingesloten veld misschien meer geschikt is, maar voor deze vraag zal ik als voorbeeld een casus gebruiken die de voordelen van een gerelateerde tabelbenadering benadrukt.
Stel je een gebruiker en post-voorbeeld voor een blog voor.
Voor een embedded post-oplossing zou je een tabel hebben zoals deze (psuedocode - deze zijn waarschijnlijk geen geldige ddl):
create table Users {
id int auto_increment,
name varchar(200)
post text[][],
}
Met gerelateerde tabellen zou je zoiets doen als
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 :Met het ingesloten bericht schrijft u de code handmatig om berichten aan een gebruiker toe te voegen, door bestaande berichten te navigeren, ze te valideren, te verwijderen enz. Met het aparte tabelontwerp kunt u gebruikmaken van ActiveRecord (of welk relationeel object dan ook gebruiken) tools hiervoor die uw code veel eenvoudiger zouden moeten houden.
Flexibiliteit :Stel je voor dat je een datumveld aan het bericht wilt toevoegen. Je kunt het doen met een ingesloten veld, maar je moet code schrijven om je array te ontleden, de velden te valideren, de bestaande ingesloten berichten bij te werken enz. Met de aparte tabel is dit veel eenvoudiger. Bovendien, laten we zeggen dat u een redacteur aan uw systeem wilt toevoegen die alle berichten goedkeurt. Met het relationele voorbeeld is dit eenvoudig. Als voorbeeld om alle berichten te vinden die door 'Bob' zijn bewerkt met ActiveRecord, hebt u het volgende nodig:
Editor.where(name: 'Bob').posts
Voor de ingesloten kant zou je code moeten schrijven om door elke gebruiker in de database te lopen, al hun berichten te ontleden en te zoeken naar 'Bob' in het editorveld.
Prestaties :Stel je voor dat je 10.000 gebruikers hebt met elk gemiddeld 100 berichten. Nu wil je alle berichten vinden die op een bepaalde datum zijn gedaan. Met het ingesloten veld moet u door elke record lopen, de hele reeks van alle berichten ontleden, de datums extraheren en de gewenste controleren. Dit zal zowel cpu als schijf i/0 opvreten. Voor de database kunt u eenvoudig het datumveld indexeren en de exacte records ophalen die u nodig hebt zonder elk bericht van elke gebruiker te ontleden.
Standaarden :Het gebruik van een leverancierspecifieke gegevensstructuur betekent dat het lastig kan zijn om uw toepassing naar een andere database te verplaatsen. Postgres lijkt een uitgebreide reeks gegevenstypen te hebben, maar ze zijn niet hetzelfde als MySQL, Oracle, SQL Server enz. Als u zich houdt aan standaard gegevenstypen, zal het veel gemakkelijker zijn om backends te wisselen.
Dit zijn de belangrijkste problemen die ik van bovenaf zie. Ik heb deze fout gemaakt en de prijs ervoor betaald, dus tenzij er een super dwingende reden is om het anders te doen, zou ik de aparte tabel gebruiken.