NoSQL è una scelta migliore quando si lavora con OOP? [chiuso]

Question

NoSQL è una scelta migliore quando si lavora con OOP? [chiuso]

#1 da (7 voti)

3

Questa potrebbe essere una domanda stupida, ma ho letto un po 'sui database NoSQL negli ultimi giorni e sto cercando di capire quando ci aiutano davvero. Una cosa che ho capito è che sembra che i database NoSQL siano più vicini a OOP di RDBMS.

Lo dico perché di solito quando trattiamo con OOAD non otteniamo una versione finale del modello in anticipo. Il modello cambia molte volte prima di arrivare alla cosa reale. Ne ho persino interrogato su questo qui su Programmers.SE. Con NoSQL, tuttavia, sembra la cosa più naturale, dal momento che il database può anche cambiare senza troppi problemi.

Inoltre, per un primo tentativo con questo tipo di tecnologia ho creato un database MongoDB e i dati sono stati salvati come POJO, in modo che sembrasse molto più vicino alla progettazione orientata agli oggetti.

In questa impostazione, NoSQL è davvero una buona idea quando si lavora con OOP o è solo una buona idea nei casi in cui abbiamo bisogno di ridimensionare il database, a cui possono accedere molti utenti e tutte queste cose?

object-oriented nosql relational-database

posta user1620696 15.04.2014 - 14:02

fonte

1 risposta

Leggi altre domande sui tag object-oriented nosql relational-database

Come si chiama un programma da un altro? Test di tutte le combinazioni

score 7 · Answer 1

Non esiste una cosa come NoSQL. C'è una miriade di nuove tecnologie di database raggruppate sotto quell'etichetta, e funzionano tutte in modo completamente diverso.

Ma quando si parla di database orientati ai documenti come MongoDB, che sono un sottoinsieme di NoSQL, allora sì, questi sono spesso più adatti per modellare gerarchie orientate agli oggetti rispetto ai database relazionali, perché di solito sono meno influenzati da il problema di mancata corrispondenza relazionale all'oggetto . Quando si ha una gerarchia di classi con classi che ereditano da altre classi, queste classi di solito hanno alcuni campi in comune, ma altri campi che sono univoci per certi sottotipi. Quando si tenta di raggruppare tutti questi oggetti in una tabella di database relazionale, sarà necessario creare molte colonne per i campi che si applicano solo a un piccolo sottoinsieme di voci e saranno NULL per tutti gli altri. Un'alternativa sarebbe utilizzare una tabella separata per ogni sottotipo, ma questo diventerà brutto quando proverai a interrogare tutti gli oggetti di una determinata classe base indipendentemente da quale sia la loro sottoclasse.

Una corrispondenza ancora migliore rispetto ai database di schemaless sono puri database di oggetti, ma si tratta in genere di tecnologie piuttosto esotiche senza un uso diffuso. Inoltre, sono spesso legati a un linguaggio di programmazione specifico che ostacola l'interoperabilità con i sistemi programmati in altre lingue.

Ma quanto bene puoi modellare i tuoi dati è solo un aspetto che dovrebbe essere preso in considerazione quando si sceglie una tecnologia di database. Ci sono spesso molti altri requisiti in un progetto che danno motivo di favorire una tecnologia di database o l'altra.