Quale è un modo più efficiente di memorizzare i dati in un database usando Oggetti o stringhe (progettazione del database)

In un database SQL relazionale, non ci sono oggetti, e devi mappare i tuoi dati in modo che alla fine tutto sia in un campo di uno dei tipi di database fondamentali (int, stringhe ...) in una tabella.

Un commento sul tuo primo schema: non ci sono matrici in sql. Devi convertire gli array in una tabella con le proprie righe, aggiungendo una chiave esterna che consente di connettere gli elementi dell'array all'ID del ristorante.

Per mantenere i benefici degli oggetti, dovresti isolare il mapping del database in un livello di origine dati che rende la mappatura tra entrambi i mondi. Quindi se in seguito cambi il componente db non metti in discussione tutto il tuo codice. Ad esempio, se in un determinato momento dovessi passare a un database di nessun database sql, come MongoDB, l'approccio a oggetti sarebbe più adatto.

Sebbene le prestazioni e la facilità di replica possano essere aree di preoccupazione, quando stai cercando di decidere tra sql e nosql, considera la struttura o la mancanza di esso nei tuoi dati.

Hai proposto una struttura dati abbastanza semplice per tenere traccia degli stabilimenti alimentari, quindi non penso che sia sufficiente. Tuttavia, ciò che accade quando è necessario diventare un po 'più complicato perché i ristoranti fast-food richiedono informazioni specifiche per loro e i ristoranti a 5 stelle di fascia alta hanno un insieme di requisiti di dati completamente diverso. Cercare di gestirli entrambi nelle stesse strutture dati può essere complicato. I database NoSQL tendono a gestire questo tipo di cose un po 'meglio. I dati sono in genere strutturati nel modo in cui vuoi interrogarli - boom, funziona molto velocemente.

I database SQL tendono a funzionare meglio quando i dati possono adattarsi bene alle colonne (senza variabilità o sorprese) che di solito si riempiono di dati. Essere in grado di relazionarsi con i dati in altre tabelle offre coerenza e consente modi imprevisti e complessi di interrogare i dati. L'indicizzazione può cercare di offrire il meglio di entrambi i mondi, ma è meglio sapere cosa stai facendo e considerare i risultati delle prestazioni quando apporti le modifiche. Forse apportare modifiche non è un grosso problema. Dopo tutto, i ristoranti non cambiano ogni 3 secondi.

A meno che non si tratti di una situazione di apprendimento, segui quella che conosci meglio. Sarai in grado di modificarlo in modo tempestivo e modificare se necessario. Decidi alcune metriche in anticipo e monitorale in modo da avere un'idea di quali indicatori potrebbero apparire che suggeriscono di utilizzare la piattaforma sbagliata.

Fai entrambi. In doxdb ho usato questo approccio. Il concetto è di memorizzare i dati che verrebbero interrogati e gli indici separatamente dai dati effettivi. In tal modo puoi essere un po 'più liberale con il design dello schema.

Puoi usare la ricerca mongo o elastico anche per fare questo.