molto utili per frequenti operazioni di lettura (siti web), ma disastrosi se l'integrità dei dati è un requisito fondamentale.
L'integrità referenziale non esiste nei db NoSQL: esistono soltanto dati "ammassati" (secondo qualche criterio, a seconda della tipologia di architettura implementata) in qualche modo e che sono veloci da ricercare (per fare un paragone, puoi pensare alla ricerca FullText che viene offerta da alcuni database).Inoltre non è integrità fisica il loro problema, ma l'integrità dei dati a livello di consistenza. Questi database, infatti, non implementano tecnologie come ACID per le transazioni, per cui è facile che due server / istanze che in parallelo servono le richieste si ritrovino disallineati.Personalmente non posso che condividere quanto già detto da Antonio: meglio un sistema ibrido, che sfrutti il meglio dei due "mondi". Da una parte l'integrità dei dati offerta dai tradizionali engine SQL, e dall'altra l'enorme facilità di scaling dei sistemi NoSQL. E' l'approccio che utilizza anche Spotify (alla scorsa EuroPython ne hanno parlato alcuni loro sviluppatori).
Ne stavo implementando uno e cercavo di capire quale fosse il modo migliore. Tra l'altro non ho avuto la possibilità di studiarli all'Uni per cui sinceramente ne so molto poco.
In ogni caso, il sistema che sto realizzando prevede una (ipotetica?) grande scalabilità. Avevo anche pensato ad un server che wrappava il tutto (il sistema è implementato sotto forma di .so o .dll) in modo da consentire l'uso dei normali comandi SQL e anche l'implementazione di alcune caratteristiche tipiche dei DB "normali" come appunto l'integrità referenziale, anche se credo questo appesantisca non poco il tutto.Cosa ne pensate?
Citazione da: "clros"Ne stavo implementando uno e cercavo di capire quale fosse il modo migliore. Tra l'altro non ho avuto la possibilità di studiarli all'Uni per cui sinceramente ne so molto poco.Vorrei capire: è per puro esercizio personale, oppure hai avuto un nuova idea che vuoi sviluppare?
Penso che, come già detto, integrità referenziale e NoSQL cozzino violentemente, e mi pare anche normale: la prima è nata ed è stata pensata per i db relazionale, mentre i secondi nascono per motivazioni esattamente opposte (NON relazionale i dati; intendo che non offrono alcun meccanismo per farlo, ed eventualmente deve pensarci il programmatore a manina).
Concordo.Claudio, se vuoi aggiungere la possibilità di eseguire comandi SQL a un database NoSQL non credo ci siano problemi. Va benissimo.Ma implementare roba come l'integrità referenziale o, peggio ancora, le transazioni sarebbe... overkill. Non è un caso che ci sia alcuna soluzione NoSQL a implementarli.
