Come persona del database voglio vomitare l'idea che qualcuno stia progettando una tabella di database in questo modo.

Le tabelle del database dovrebbero essere progettate utilizzando tre criteri principali:

1. Integrità dei dati
2. Prestazioni dell'interrogazione del database
3. Sicurezza dei dati

Un buon progetto di database spesso richiede campi che non sono utilizzati dall'applicazione in alcun modo (ma potrebbero essere necessari per l'importazione o il controllo dei dati o per altri motivi) e in molti database, più applicazioni avranno bisogno di accedere ai dati e hanno esigenze diverse.

Ciò che sembra facile da fare per le schermate di immissione dei dati potrebbe non funzionare affatto per i rapporti (che è spesso un'applicazione completamente diversa di cui lo sviluppatore non progetta solo per la sua logica) perché i rapporti tendono ad occuparsi di dati più grandi imposta schermate di inserimento dati che in genere riguardano solo un record alla volta. Quindi, una struture di database che sembra logica dal punto di vista dei programmatori di applicazioni (come una tabella EAV, shudder!) Può essere la cosa peggiore da utilizzare quando si estraggono i dati dal database in un secondo momento. Soprattutto se ci saranno milioni di record.

I database sono ottimizzati per utilizzare tabelle normalizzate e dovrebbero essere progettati con principi di normalizzazione in mente non usando principi orientati agli oggetti. Sì, c'è una discrepanza tra ciò che è meglio per il database e ciò che è meglio per un'applicazione orientata agli oggetti. Sì, devi affrontarlo e no non è una buona idea affrontarlo facendo in modo che il database corrisponda all'orientamento dell'orientamento.

Pegging quadrato, foro rotondo

I can see how creating a mapping like this simplifies thinking about the data, but I also feel it restricts you to thinking about the data in only this way. How conforming do you make your database tables to data structure(s), if at all?

Non sono affatto conforme al database. Supponendo che i benefici che si possono ottenere da una particolare struttura di dati nel codice possano essere mappati direttamente nel database è un errore nel comprendere i punti di forza dei database.

È una buona idea rappresentare i dati nella sua forma più vera, spogliati dell'implementazione perché l'implementazione molto probabilmente cambierà nel tempo.

La semplice regola è "dati separati dall'implementazione".

Should databases be viewed as realms of raw data that are to be shaped and molded (translated) to data structures selected dependent on the program's purpose?

Chiediti questo. Vuoi duplicare tutte le funzionalità di un database nel codice (inclusi indicizzazione, chiavi primarie, chiavi esterne, ecc.)? Certo che no, perché nel contesto del programma non aggiungono alcun valore.

Tutto quello che vuoi sono i dati corrispondenti ai parametri che hai inserito.

È meglio modellare la struttura del database nel miglior modo possibile per il recupero della memoria e modellare le strutture di dati nell'applicazione nel modo migliore per come verranno utilizzate nel codice.

Non capirai come costruire un database ideale finché non avrai acquisito una solida comprensione di quali database sono progettati per realizzare.

Il punto è che non esiste una mappatura 1-1 da DB a nessuna struttura di dati. Il database potrebbe essere considerato il proprio tipo di struttura di dati di scopo speciale di livello superiore basato su un'intera raccolta di strutture di dati di livello inferiore.

Specificamente per la situazione dell'elenco collegato: nei database SQL è solitamente molto più facile memorizzare un campo "ordinamento" (numerico) che viene rinumerato se si desidera inserire o rimuovere un nodo: anche aggiornando un numero elevato di colonne (ordinare = ordinare + 1) è solitamente veloce. La navigazione di un elenco di nodi collegati è molto poco pratica, poiché non è possibile farlo con una semplice query.

Questo di per sé è un perfetto esempio del perché le strutture e l'implementazione di dati non sempre si adattino bene l'una all'altra.

Per essere perfettamente sincero, sembra una cattiva idea. Questo modello mescola alcune cose che dovrebbero rimanere separate.

Da questa specifica, vedo tre liste di tabelle, nodi, dati.

list

• id
• nome

nodo

• id
• position_in_list
• list_id
• datum_id

Riferimento

• id
• data_value_1
• data_value_2
• ...

OK, ovviamente non avrai una tabella di riferimento, ma è un segnaposto per i tuoi dati reali.

Un nome di lista 'foo' nel può quindi essere ricostruito con:

SELECT datum.*
  FROM datum
  LEFT JOIN node ON datum.id = node.datum_id
  LEFT JOIN list ON node.list_id = list.id
WHERE list.name = 'foo'
  BY node.position_in_list

Risposta breve: NO

Risposta più lunga:

Un singolo database può essere utilizzato con le mie numerose applicazioni e un'applicazione può utilizzare molti database.

Inoltre: programma contro le visualizzazioni, non contro le tabelle.

Should a database table(s) structure match its intended data structure(s) in the logic?

In breve: NO, è un errore tecnico pensare in questo modo.

Ogni progetto dovrebbe avere il design e la struttura del database basati su SOLO e SOLO sui requisiti aziendali forniti e approvati dai portatori di interesse del progetto . Eventuali alterazioni minori e miglioramenti alla struttura del DB potrebbero essere potenzialmente eseguiti nelle fasi successive del progetto, a seconda dei trade-off delle prestazioni e dell'usabilità.