1 réponse
Il faut d'abord savoir de quelle fonctionnalité vous avez besoin au niveau de votre SGBD.
Si on se limite au monde SQL : triggers ? procédures stockées ? contraintes d'intégrité ? réplication ? mécanismes de journalisation ? fonctionnalités BI intégrées ?
On peut aussi regarder du côté de l'univers NoSQL mais ce n'est que plus rarement pertinent et ça demande plus d'expérience pour faire le bon choix et bien le mettre en place.
Il y a ensuite les questions de montée en charge et de performances. Mais en général, les problèmes que vous aurez sur une application viendront plus d'une utilisation non-optimale du SGBD que de ses limites à lui.
Si on se limite au monde SQL : triggers ? procédures stockées ? contraintes d'intégrité ? réplication ? mécanismes de journalisation ? fonctionnalités BI intégrées ?
On peut aussi regarder du côté de l'univers NoSQL mais ce n'est que plus rarement pertinent et ça demande plus d'expérience pour faire le bon choix et bien le mettre en place.
Il y a ensuite les questions de montée en charge et de performances. Mais en général, les problèmes que vous aurez sur une application viendront plus d'une utilisation non-optimale du SGBD que de ses limites à lui.