Riferimento personale usando una nuova tabella vs elenco di id concatenati

Question

Riferimento personale usando una nuova tabella vs elenco di id concatenati

#1 da (2 voti)
#2 da (1 voti)

1

Nel mio posto di lavoro attuale c'è un modello comune nella progettazione del database: non usano chiavi esterne ma elencano tutti gli ID corrispondenti in una colonna come questa:

some_table
id  name image_ids
1   a    1,2,3
2   b    4,6,7

images
id url
1  ...
2  ...
...

Memorizzano i riferimenti personali allo stesso modo:

some_table
id  name  some_table_id
1   a     2,3
2   b     1,3
...

Mi incoraggiano a usare questo schema ma non mi sembra giusto. Non progetterei mai un database come quello. Ho alcuni argomenti contrari contro:

E se un giorno aggiungessi dei dati arbitrari a un riferimento personale? Usando questo modello non sarei in grado di
Non garantisce l'integrità referenziale. Posso facilmente aggiungere ID inesistenti che porteranno a problemi
La ricerca di stringhe non è veloce

Devo giustificare le mie lamentele, quindi la mia domanda è: Quali argomentazioni argomentative convincenti riesci a trovare contro questo approccio di progettazione hacky?

mysql database-design

posta Adam Arold 27.08.2013 - 18:48

fonte

2 risposte

Leggi altre domande sui tag mysql database-design

Quanto tempo occorre dedicare ai casi d'uso? Le t-shirt sono un buon metodo per effettuare stime iniziali? [chiuso]

score 2 · Answer 1

Sembra che tu abbia le tue lamentele in ordine. Ne tirerei fuori di più, ma non penso che tu abbia identificato il motivo per cui hanno scelto questa soluzione.

Ci sono molti vantaggi nella normalizzazione e denormalizzazione di un database. Guarda come sentono questa struttura a beneficio dell'applicazione. Speriamo che stiano cercando di fare di più per venderti su questi metodi invece di farti fare.

Potrebbe esserci una mancanza di conoscenza del database relazionale. Hanno già preso la briga di gestire le relazioni e l'integrità referenziale nel codice dell'applicazione. Se questo causa molti bug perché codificano cose che un RDBDMS gestisce quasi fuori dalla scatola, ha senso cambiare il codice invece di provare a mantenere quello che hai.

Forse c'è un nuovo modulo per l'applicazione in cui hai l'opportunità di fare le cose in modo diverso e mostrare loro i benefici? È una vendita dura sul codice che presumibilmente funziona.

Tutti sono a conoscenza delle migliori pratiche, del debito tecnico, della facilità di debugging e miglioramento, ma possono essere difficili da vendere in situazioni in cui potrebbero non applicarsi (ad esempio un sistema di codice legacy con un team legacy che è abile nel loro inefficiente metodi sufficienti per convincere i responsabili che stanno facendo le cose in tempo e non possono essere più veloci.)

score 1 · Answer 2

Alcuni degli argomenti a cui posso pensare contro questo design:

Probabilmente è impossibile indicizzare gli ID dei riferimenti. A volte vuoi indicizzare una tabella non solo dalla sua chiave primaria, ma anche da ciò che fa riferimento. Non vedo un modo semplice per farlo qui.
Le query che partecipano a questi campi diventeranno brutte. Suppongo che ci sia un sacco di utilizzo per in e funzioni di manipolazione delle stringhe (come instr , substr , ecc ...).
L'aggiornamento di questi elenchi di ID sarà brutto, dal momento che devi aggiornare i record e rimuovere / aggiungere stringhe invece di inserire / eliminare semplicemente i record, se questo è stato fatto correttamente con le tabelle ausiliarie che memorizzano queste relazioni.
Come hai detto, questo approccio può anche portare a problemi di integrità dei dati.
Tutto quanto sopra potrebbe portare a problemi di prestazioni.
È contro-intuitivo e sarà più difficile quando nuovi membri si uniranno al team.

Non so quale di questi hai già provato su di loro. L'approccio migliore potrebbe essere quello di realizzare una demo di un piccolo set di tabelle (forse some_table e images ): ricostruire le tabelle con chiavi esterne e tabelle di relazione appropriate e mostrare i guadagni in termini di prestazioni, la facilità di interrogazione, non è possibile introdurre dati non validi ... E spero che tu sia in grado di mostrare alcuni vantaggi significativi. Se questo modello di progettazione è già così trincerato, potrebbe essere molto difficile romperlo senza una buona dimostrazione.