Pro e contro di database a più valori

Question

Ho appena iniziato un nuovo lavoro in cui dovrò fare un buon lavoro con un database multi-valore (UniVerse). La mia piccola esperienza di database è in database relazionali (SqlServer) e sto cercando alcune informazioni non distorte su ciò che i pro e i contro di un MVD vengono confrontati con i database relazionali.

Tutti in ufficio provengono da uno sfondo di database relazionale (e odia UniVerse) o sono stati qui per anni e lo adora.

Answer 1

In primo luogo, un disclaimer. Lavoro con UniData (il DB gemello di UniVerse) e occasionalmente blog on it, quindi non posso affermare di essere completamente imparziale; Proverò, comunque.

Ecco alcuni punti di considerazione per voi:

• Una grande differenza tra un DB SQL e DB multivalore è che il MVDB non aderisce alla 1NF. Questo ha pro e contro. Può essere (e comunemente è) abusato, ma ci sono momenti in cui può essere estremamente funzionale. Il più grande vantaggio è che non è sempre necessaria una tabella di join in grado di rendere certe query molto più veloci.

• Memorizza i metadati in modo completamente nuovo rispetto ai DB SQL standard. Ogni file/tabella non ha uno schema concreto. Invece, ha uno o più file 'dizionario' composti da record che ti dicono come interpretare i dati. Ciò consente di memorizzare non solo più interpretazioni dei dati (raw/maiuscolo/minuscolo, campi combinati, ecc.) Ma consente anche di eseguire l'equivalente di enum e join. Può essere extremely powerful if done right.

• Purtroppo, anche se il concetto ha molto potenziale, set di strumenti del DBMS è carente. Lo sviluppo è guidato, ma un insieme estremamente ristretto di casi aziendali sembra essere guidato da una mentalità "keep-the-lights-on" dei sistemi di software di invecchiamento esistenti & che sono stati creati su di esso. Sebbene abbia strumenti per l'integrazione (come i connettori .NET, l'interfaccia ODBC per le query SQL, ecc.) Hanno problemi. Ad esempio, l'interfaccia di UniObjects .NET non ha granulazioni di sicurezza (praticamente tutto o niente).

• Non è solo un DBMS, ma è essenzialmente un'intera piattaforma di applicazioni. Anche se UniBasic non è così potente come dire un linguaggio basato su .NET, è sicuro che batte fuori i pantaloni da T-SQL e ha una svolta veloce per il pompaggio delle regole di business.

Answer 2

Non ci sono pro e contro in quanto tali - semplicemente usano metodi diversi per memorizzare i valori. UniVerse utilizza un delimitatore per separare i valori (IIRC utilizza char (254) e char (253) per suddividere i valori multipli in un campo e char (255) per separare i record effettivi nel file di dati. però - sono passati più di 10 anni dall'ultima volta che l'ho usato). Alcune persone adorano questo metodo di memorizzazione dei dati, proprio come alcune persone preferiscono ancora le auto d'epoca a quelle del modello in ritardo, o alcune persone preferiscono usare un cavallo e un carrello invece di un moderno veicolo a motore. (Ovviamente questa è solo la mia opinione).

Memorizzare più valori in un campo indica che non si dispone della tabella aggiuntiva che SQLServer avrebbe utilizzato, si ha effettivamente un livello di denormalizzazione. L'uso di questi multi-valori è tutto facile e buono se si utilizza una tecnologia nativa con UniVerse (usavamo un sistema di finestre chiamato CueBIC), ma diventa una PITA quando si collega al database da un'altra lingua come C++ o VB - quindi leggere un record e separare i valori da soli. Ciò significa che era anche difficile cercare su quei valori multipli.

Ma poi di nuovo, forse le cose sono passate da quando l'ho usato, forse qualcuno ha scritto un buon driver in modo da poter facilmente interfacciarsi con UniVerse da una piattaforma .Net. Spero per il tuo bene che hanno.

Answer 3

I database MV sono noti per spremere prestazioni impressionanti da server a basso consumo energetico.

Essi utilizzano un sistema di archiviazione hash di collegamento che riduce la maggior parte delle operazioni di accesso ai file a un'operazione matematica e un singolo disco letto quando la chiave di registrazione è nota. In un sistema configurato correttamente, le letture da un file di file con 1.000.000.000 di registrazioni non richiedono più tempo di quelle da un file con 1.000 record purché sia ​​nota la chiave del record.

Le chiavi di registrazione devono essere univoche e nelle applicazioni in cui è possibile impostare una chiave di registrazione in modo tale che possa essere determinata in modo algoritmico o programmatico, l'overhead coinvolto nell'accesso al database può essere minimo. Ma, naturalmente, questo di solito comporta l'accesso al database in modi che probabilmente non sarebbero considerati "relazionali".

Answer 4

Come suggerito da Dave, i database MV sono progettati per funzionare al meglio quando si conosce la chiave del record che si sta tentando di recuperare. Alcune persone si riferiscono a loro come sistemi di database basati su record, al contrario di SQL, che è un sistema di database basato su set.

Dipende davvero da cosa si sta tentando di fare, da come devono essere strutturati i dati e da quali altri strumenti sono disponibili. Trascorro la maggior parte del mio tempo lavorando in MV (prodotti Revelation, per lo più) e gestiamo regolarmente set di record su 10.000.000+, e la velocità va bene.

L'intensità del database MV è quando i dati sono fluidi. Troviamo che la maggior parte dei nostri clienti lo usa per applicazioni come prodotti legali, medici e finanziari; applicazioni in cui le relazioni sono complesse e possono cambiare rapidamente e drasticamente nel tempo.

Si potrebbe voler esaminare il movimento senza SQL, che condivide gran parte degli stessi concetti, anche se MV e SQL non sono realmente la stessa cosa.

Lo svantaggio principale di MV è meno nella sua struttura, che negli strumenti. Generalmente, poiché la base di sviluppatori è più piccola, il toolkit e l'aiuto disponibili sono più piccoli. Potresti anche scoprire che il linguaggio di base incorporato a cui la maggior parte delle offerte ti dà manca del codice stile oggetto a cui sei abituato. Ci sono volte in cui anche JavaScript sembra avere più funzionalità come lingua.

Detto questo, poiché i database MV sono principalmente stringhe giganti, la gestione delle stringhe delle lingue è eccellente. Sono grandi per la manipolazione diretta di stringhe HTML e XML.

Suppongo che la grande domanda che ho, è che avete domande specifiche? Non aprirò una guerra dicendo che è come passare da Windows a Linux o un Mac, o anche passare da Debian a Red Hat, ma le strutture e i sistemi sono diversi, quindi hanno concetti, punti di forza, limitazioni e scopi diversi . Se provi a gestire un database MV come SQL (che puoi), scoprirai che non è la soluzione migliore. Un database MV mal progettato può essere un esercizio di frustrazione. Un database MV ben progettato può essere una cosa di bellezza.

Answer 5

Il ridimensionamento di molti elementi (record) nei file funziona correttamente. Il ridimensionamento a molti valori o sotto-valori all'interno dei record creerà problemi di prestazioni. La progettazione dell'applicazione deve essere sensibile agli elenchi di valori limitati e di valori secondari sotto la soglia dei diversi 1000.

La gestione delle stringhe è eccellente.Come è la gestione dei numeri interi. I linguaggi MV Basic sono generati in modo approssimativo, quindi non aspettarti troppa implementazione dal compilatore. Detto questo, poiché gli elementi di origine di MV Basic sono come qualsiasi altro dato e il compilatore è solo un altro verbo nell'ambiente di DB, scrivere generatori di codice e pre-compilatori è un gioco da ragazzi. È un buon ambiente per la creazione di uno strato di strumenti sotto l'applicazione.