(Dis-) Vantaggi dell'archiviazione di oggetti nel database relazionale?

3

In un commento fuori mano su questa domanda su memorizzazione di oggetti PHP in un database MySQL Ho già detto che probabilmente non è una buona idea farlo.

Il mio ragionamento è che MySQL è esplicitamente un DBMS relazionale e che non ha senso forzarlo ad essere qualcos'altro, in quanto non sarà ottimizzato per quello.

Suppongo che limiti severamente la potenza di SQL - ogni azione come la combinazione di dati da tabelle diverse ora verrebbe spostata sul livello dell'applicazione - e suppongo che ciò comporterà una perdita di prestazioni piuttosto significativa - l'intero oggetto dovrebbe ora essere recuperato ogni volta, e così via.

L'OP di quella domanda diceva che il loro insegnante raccomandava ancora di archiviare interi oggetti in MySQL - e ci sono più domande a riguardo su StackOverflow, quindi presumo che non siano gli unici a farlo - quindi mi chiedo se ci sono davvero dei vantaggi a questo approccio e se ho identificato correttamente gli aspetti negativi di questo approccio.

Si noti che non sto chiedendo i vantaggi di NoSQL / Object DBMS, ma riguardo (errare) l'uso di un database relazionale per memorizzare oggetti.

    
posta tim 20.08.2016 - 18:29
fonte

1 risposta

3

Memorizzerai un oggetto in un record del database quando hai bisogno dei benefici che ciò comporta. Ci sono casi d'uso validi per questo, altrimenti non ci sarebbero cose come i database degli oggetti oi database relazionali agli oggetti.

Quando memorizzerai oggetti in un database relazionale?

  1. Quando i tuoi dati non hanno schemi; cioè, gli oggetti possono contenere campi arbitrari. Memorizzare un oggetto significa che puoi mettere tutto ciò che vuoi in quell'oggetto

  2. Quando vuoi archiviare un oggetto grafico di qualsiasi tipo.

  3. Quando le funzionalità di ricerca e unione di un database relazionale sono di importanza secondaria alla flessibilità di memorizzazione degli oggetti.

SQL Server consente di archiviare oggetti serializzati in formato JSON o XML e quindi eseguire query SQL di prima classe su di essi. Sostengono che usereste queste funzionalità quando:

  • I tuoi dati sono sparsi o non conosci la struttura dei dati, o la struttura dei tuoi dati potrebbe cambiare in modo significativo in futuro.
  • I tuoi dati rappresentano gerarchia di contenimento, anziché riferimenti tra entità, e potrebbero essere ricorsivi.
  • Vuoi interrogare i dati o aggiornarne alcune parti, in base alla sua struttura.
risposta data 20.08.2016 - 18:54
fonte

Leggi altre domande sui tag