Sto vedendo due possibilità: sqlite e BerkeleyDB. Come il mio caso d'uso è chiaramente non relazionale, sono tentato di andare con BerkeleyDB, però io non so davvero come dovrei usarlo per negozio i miei dischi, in quanto memorizza solo coppie chiave/valore.
Quello che stai descrivendo è esattamente ciò di cui parla il rapporto, anche se hai solo bisogno di un tavolo. SQLite probabilmente renderà questo molto facile da fare.
MODIFICA: Il modello relazionale non ha nulla a che fare con le relazioni tra tabelle. Una relazione è un sottoinsieme del prodotto cartesiano di altri set. Ad esempio, il prodotto cartesiano dei numeri reali, numeri reali e numeri reali (sì, tutti e tre uguali) produce lo spazio delle coordinate 3d e potresti definire una relazione su quello spazio con una formula, ad esempio x*y = z. ogni possibile insieme di coordinate (x0,y0,z0) sono nella relazione se soddisfano la formula data, altrimenti non lo sono.
Un database relazionale utilizza questo concetto con alcuni requisiti aggiuntivi. Innanzitutto, e la cosa più importante, la dimensione della relazione deve essere finita. La relazione di prodotto sopra riportata non soddisfa questo requisito, perché ci sono infinitamente più tuple di 3 che soddisfano la formula.Ci sono una serie di altre considerazioni che hanno più a che fare con ciò che è pratico o utile su computer reali che risolvono problemi reali.
Un modo migliore di pensare al problema è pensare a dove ogni tipo di meccanismo di persistenza funziona in modo specifico meglio dell'altro. Si riconosce già che una soluzione relazionale ha senso quando si hanno molti dataset separati (tabelle) che devono supportare le relazioni tra di essi (vincoli di chiave esterna), che è quasi impossibile applicare con un archivio di valori-chiave. Un altro vantaggio reale per le relazioni è il modo in cui rende possibili query ad hoc complete con l'uso di indici appropriati. Questa è una conseguenza del livello del database che comprende effettivamente i dati che rappresenta.
Un archivio di valori-chiave ha il proprio insieme di vantaggi. Uno dei più importanti è il modo in cui i negozi di valore-chiave si ridimensionano. Nessuna conseguenza è che memcached, couchdb, hadoop utilizzino tutti gli archivi con valori-chiave, poiché è facile distribuire la ricerca di valori-chiave su più server. Un'altra area in cui l'archiviazione dei valori-chiave funziona bene è quando la chiave o il valore è opaco, ad esempio quando l'elemento memorizzato viene crittografato, per essere solo leggibile dal proprietario.
a guidare questo punto a casa, che un database relazionale funziona bene anche quando proprio non c'è bisogno più di una tabella, considerare quanto segue (non originale)
SELECT t1.actor1
FROM workswith AS t1,
workswith AS t2,
workswith AS t3,
workswith AS t4,
workswith AS t5,
workswith AS t6
WHERE t1.actor2 = t2.actor1 AND
t2.actor2 = t3.actor1 AND
t3.actor2 = t4.actor1 AND
t4.actor2 = t5.actor1 AND
t5.actor2 = t6.actor1 AND
t6.actor2 = "Kevin Bacon";
Il che, ovviamente, utilizza una singola tabella: workswith per calcolare ogni attore con un numero di bacon di 6
Grazie a tutti voi ragazzi per le vostre risposte molto utili! Scegliere uno migliore è stato davvero difficile: -/ –