Le strutture dati sono, per la maggior parte:

1. Memoria residente,
2. Transient,
3. Limitato nelle dimensioni,
4. Non rientranti senza aggiungere meccanismi di concorrenza come i blocchi o l'immutabilità,
5. Non ACID conforme,
6. Veloce, se scelto attentamente.

I database sono, per la maggior parte:

1. disco-bound,
2. Persistente,
3. Grande,
4. In modo sicuro simultaneo,
5. Conformità ACID, con capacità transazionale ,
6. Più lento delle strutture di dati

Le strutture dati devono essere trasmesse da un luogo a un altro e utilizzate internamente all'interno di un programma. Quando è stata l'ultima volta che hai inviato dati da una pagina web a un server web utilizzando un database o eseguito un calcolo su un database che era interamente residente in memoria?

I sistemi di database utilizzano strutture dati come parte della loro implementazione interna. È una questione di dimensioni e scopo; usi le strutture dati all'interno del tuo programma, ma un sistema di database è un programma a sé stante.

What are the differences between data structures and databases?

A livello astratto, non ce n'è: un database è una struttura dati.

A un livello specifico, i database in genere hanno lo scopo di conservare i dati, di solito in un formato ottimizzato per inserimenti, aggiornamenti, recupero, adesione o altri scopi (o una combinazione).

es. se si confronta una tabella in un RDBMS per dire una matrice di dati, la differenza potrebbe essere nel tempo di esecuzione dell'algoritmo, la quantità di codice che si deve scrivere, la quantità di memoria necessaria per eseguire l'algoritmo, o il flessibilità per lavorare / accedere ai dati dall'esterno del tuo programma / algoritmo.

When do we use algorithms that use data structures defined solely within your own logic and not that of the database's?

In linea di tendenza direi

a) per utilizzare un database se è necessario mantenere i dati in modo accessibile oltre il tempo di esecuzione o lo scopo dell'algoritmo specifico.

b) per utilizzare la propria struttura dati (in memoria) se la velocità di esecuzione è importante o se la persistenza non è richiesta

es. se il tuo algoritmo elabora i record dei clienti, potresti voler archiviare quei record dei clienti (ad esempio per trovare tutti i clienti in una particolare area) per un uso futuro da qualche altro programma / algoritmo e per uno scopo completamente diverso (ad esempio per trovare i clienti più preziosi) . In tal caso l'utilizzo di un database per mantenere i dati è probabilmente una buona idea.

Si noti, tuttavia, che esiste il concetto di database in memoria che non necessariamente mantengono i dati, per motivi di prestazioni. Per esempio. Redis o HANA .

When do the methods in the database become less efficient to use than methods in your own logic?

La risposta dipende molto dalle circostanze e dal (tipo di) database in uso. Vorrei riformulare la domanda "cosa rende un metodo efficiente?" Diventa quindi un esercizio di valutazione dei metodi (= algoritmo) che useresti per la tua struttura dati v.s. i metodi usati dal database. Vedi anche il prossimo punto.

How is processing data with data structures faster than doing it in the database?

Di nuovo, questo dipende dalle specifiche. In generale, l'elaborazione dei dati che sono in memoria, direttamente accessibili al processo che esegue l'algoritmo, è più veloce rispetto all'invio di una richiesta a un altro processo (nello stesso computer o attraverso una rete) e chiedendo di rimandare i risultati . Tuttavia, se i dati risiedono già nel database, inviando un comando - ad esempio un'istruzione SQL per unire due tabelle e calcolare alcune funzioni aggregate - e recuperare solo un piccolo riepilogo o sottoinsieme dei dati potrebbe essere molto più efficiente del primo trasferimento di tutti i dati dati e calcolo dei risultati localmente (utilizzando le proprie strutture dati).

L'accesso al disco è principalmente ciò che è più costoso in questa operazione, più spesso rispetto all'accesso alla rete (http://serverfault.com/questions/238417/are-networks-now-faster-than-disks). A meno che il tuo database non si trovi su almeno una rete da 1 Gbps e la stessa rete del tuo server web \ application, le prestazioni della rete non saranno importanti quanto le prestazioni del disco per i set di dati più grandi. O se i tuoi dati si trovano su dischi a stato solido molto veloci che saranno più veloci del tipico accesso alla rete. Inoltre, i database di solito forniscono un meccanismo IPC come pipe denominate anziché utilizzare TCP / IP se il database risiede sullo stesso server del server delle applicazioni.

Se riesci a mantenere la maggior parte della struttura dei dati in memoria tra le richieste, questa sarà in genere la tua scommessa più rapida. Se non è possibile, è difficile battere una buona struttura di database con tabelle normalizzate e indici appropriati per le prestazioni di ricerca e aggiornamento su qualcosa di diverso dai piccoli set di record, specialmente in un sistema con milioni di record.

I database relazionali usano tipicamente un albero B + o una sua variante sotto il cofano e hanno molte ottimizzazioni come l'allineamento dei dati su disco e pool di buffer per i record ad accesso frequente. Ciò li rende eccellenti nell'elaborazione di grandi set di dati rapidamente, soprattutto se sono coinvolti aggregazione o filtraggio.

Che cosa intendi per database? Intendi un database relazionale come MySQL o SQL Server? Un database relazionale è una struttura meta-dati che supporta alcuni sottoinsiemi delle operazioni definite dal modello relazionale . La teoria del modello relazionale elaborata per lo più da Edgar Codd negli anni '60.

Il modello relazionale è molto generico e flessibile, ma ciò significa che non può trarre alcun vantaggio dalla struttura nei dati o nei modelli di accesso. Le strutture dati sono utili quando si conoscono i dati e il modo in cui saranno accessibili. Ad esempio, se sai che gli ultimi dati inseriti in una struttura dati saranno i primi dati che desideri, puoi utilizzare uno stack.

Ho chiamato il database relazionale una struttura di meta-dati perché in genere è una gran quantità di software che utilizza molte strutture di dati come pile, code, alberi e liste per creare la struttura dati astratta di una tabella relazionale.