L'incorporamento di una struttura dati in un campo può funzionare per casi semplici, ma impedisce di sfruttare i database relazionali. I database relazionali sono progettati per trovare, aggiornare, eliminare e proteggere i tuoi dati. Con un campo incorporato contenente i propri dati wad-o (array, JSON, xml ecc.), finisci per scrivere tutto il codice per farlo da solo.
Ci sono casi in cui il campo incorporato potrebbe essere più adatto, ma per questa domanda come esempio userò un caso che mette in evidenza i vantaggi di un approccio tabellare correlato.
Immagina un esempio utente e post per un blog.
Per una soluzione di post incorporata, avresti una tabella simile a questa (psuedocode - probabilmente non sono ddl validi):
create table Users {
id int auto_increment,
name varchar(200)
post text[][],
}
Con le tabelle correlate, faresti qualcosa del tipo
create table Users {
id int auto_increment,
name varchar(200)
}
create table Posts {
id auto_increment,
user_id int,
content text
}
Strumenti di mappatura relazionale degli oggetti (ORM) :Con il post incorporato, scriverai il codice manualmente per aggiungere post a un utente, navigare tra i post esistenti, convalidarli, eliminarli ecc. Con il design separato della tabella, puoi sfruttare ActiveRecord (o qualsiasi sistema relazionale a oggetti tu stanno usando) strumenti per questo che dovrebbero mantenere il tuo codice molto più semplice.
Flessibilità :Immagina di voler aggiungere un campo data al post. Puoi farlo con un campo incorporato, ma dovrai scrivere il codice per analizzare il tuo array, convalidare i campi, aggiornare i post incorporati esistenti ecc. Con la tabella separata, questo è molto più semplice. Inoltre, supponiamo che tu voglia aggiungere un Editor al tuo sistema che approvi tutti i post. Con l'esempio relazionale questo è facile. Ad esempio, per trovare tutti i post modificati da 'Bob' con ActiveRecord, ti bastano:
Editor.where(name: 'Bob').posts
Per il lato incorporato, dovresti scrivere il codice per esaminare tutti gli utenti nel database, analizzare tutti i loro post e cercare "Bob" nel campo dell'editor.
Prestazioni :Immagina di avere 10.000 utenti con una media di 100 post ciascuno. Ora vuoi trovare tutti i post fatti in una certa data. Con il campo incorporato, devi scorrere ogni record, analizzare l'intera matrice di tutti i post, estrarre le date e ricontrollare quella desiderata. Questo masticherà sia la CPU che il disco i/0. Per il database, puoi facilmente indicizzare il campo della data ed estrarre i record esatti di cui hai bisogno senza analizzare ogni post di ogni utente.
Standard :L'utilizzo di una struttura dati specifica del fornitore significa che spostare l'applicazione in un altro database potrebbe essere un problema. Postgres sembra avere un ricco set di tipi di dati, ma non sono gli stessi di MySQL, Oracle, SQL Server ecc. Se ti attieni ai tipi di dati standard, sarà molto più semplice scambiare i back-end.
Questi sono i problemi principali che vedo dall'alto. Ho commesso questo errore e ne ho pagato il prezzo, quindi, a meno che non ci sia una ragione super convincente per fare diversamente, userei la tabella separata.
