Perché creare un nuovo linguaggio MDX invece di estendere SQL?

Ogni fornitore di database ha il proprio set di estensioni SQL proprietarie per raggiungere determinati obiettivi frammentari. Ma nessuna di queste estensioni ha raggiunto un'adozione diffusa come quella di SQL.

Se il tuo obiettivo è creare funzionalità avanzate in un modo basato su standard, hai due opzioni. Puoi andare al comitato per gli standard SQL e creare il tuo caso (che potrebbe richiedere anni), oppure puoi creare il tuo standard e sperare che la comunità lo adotti. Le estensioni del fornitore sullo standard SQL non sono riuscite in questo modo.

Quindi Microsoft, invece di adottare un approccio frammentario, ha deciso di andare all-in e creare una soluzione completa. E ha funzionato; l'industria l'ha adottato come soluzione ideale per l'interrogazione OLAP. Ergo, uno standard defacto, senza il dolore del comitato.

MDX è uno standard de facto , creato da un singolo fornitore. Supponendo che tu possa ottenere un ampio consenso, hai eliminato la necessità del design da parte del comitato e ti sei risparmiato un sacco di tempo, impegno e denaro.

Penso che il motivo sia che i database OLAP (che sono quelli con cui MDX sembra essere destinato all'uso) NON sono solo database relazionali. Sono un po 'diversi (non ho esperienza con loro, quindi i dettagli mi sfuggono al momento), e un diverso modello mentale è utile per interagire con loro (anche se in realtà è un DB relazionale sotto).

Il problema che stai incontrando è che stai vedendo il database OLAP come un DB relazionale, e quindi vuoi usare il linguaggio appropriato (SQL) per interrogare il database relazionale. Ma NON è un DB relazionale, è qualcosa di simile, ma non proprio lo stesso. È strutturato per un diverso modello mentale e il linguaggio di query MDX si adatta a tale modello meglio di SQL.

why go on to the trouble of creating a new completely different language when you could build on SQL, extend it to add the features needed by OLAP applications?

Condivido il tuo dolore nella curva di apprendimento MDX; avendo usato SQL per un po 'di tempo, la mia azienda ha deciso di adottare Analysis Services e creare cubi OLAP per fornire la possibilità di eseguire analisi rapide dei dati. Sono stato pesantemente coinvolto in questo e ho avuto qualche problema nel prendere alcuni bit di MDX.

Detto questo, penso che non sia giusto etichettare MDX come non necessario. Fornisce vantaggi, ma solo se non si tenta di usarlo come se fosse SQL. In effetti, la ragione per cui è difficile da raccogliere è perché spesso non esiste un equivalente diretto in SQL, quindi stai cercando di imparare l'idea e la sintassi.

C'è una vena di pensiero inutile tra alcuni membri del team quando si tratta di recuperare i dati: i cubi OLAP sono un "upgrade" rispetto alle tradizionali tabelle SQL. Questo non è vero, OLAP / MDX sono buoni in certe cose, ma le tabelle / SQL tradizionali sono migliori per gli altri. Vedere le due versioni equivalenti o diverse della stessa cosa non è utile, almeno concettualmente nella mia esperienza.