Perché non andare su questo più assiomaticamente? Ad esempio, perché è "CMS / blogging" più adatto per documentare i database (o qualsiasi altra cosa)? Quali sono le proprietà comuni di queste applicazioni che ti fanno pensare che siano più adatte all'una o all'altra tecnologia?
Considerare i punti di forza di ciascuna tecnologia DBMS e, in effetti, la teoria su cui si basa ciascuna. Che modello di dati implementano? (Ognuno di fatto ha un modello di dati?) Quali sono le proprietà di ciascun modello di dati e in che modo le proprietà dell'applicazione si associano a quelle del modello di dati? Se sviluppi una mappa del genere, avrai un modo per caratterizzare qualsiasi applicazione, anche se non ne hai mai sentito parlare o uno che non è stato ancora inventato.
Codd ha definito un modello di dati comprendente tre caratteristiche di interblocco: struttura, operazioni e vincoli. Il modello relazionale ha tutti e tre i colori. Se osservi da vicino le alternative, scoprirai che mancano almeno una e in genere due di queste. Qualsiasi tecnologia non basata sul modello relazionale è ipso facto meno funzionale. Per questo motivo è sicuro dire che l'applicazione ogni può essere supportata dal modello relazionale (se non da prodotti relazionali esistenti). Il modello relazionale è ancora più sviluppato, più potente, e tuttavia più semplice di qualsiasi altro ancora ideato. Sarà difficile migliorare perché si basa sulla logica dei predicati e sulla teoria degli insiemi.
Forse puoi identificare applicazioni per le quali, ad esempio, operazioni ben definite non contano. Ma vuoi essere molto sicuro di capire prima perché sono importanti in generale, prima di poter dire con certezza perché non sono necessari (o anche solo utili) per una particolare applicazione.
Prima o poi qualcuno ti dirà che "la relazione non scala" e che la tecnologia X è veloce. Quando lo fanno, ricordate che hanno implicitamente rinunciato a funzionalità che la tecnologia X non ha rispetto al modello relazionale, caratteristiche che potrebbero essere importanti. Inoltre, un modello di dati non è veloce o lento, solo un'implementazione lo è. Ogni volta che ci sono più programmatori che macchine, è più economico acquistare hardware più veloce che assumere più programmatori.