519Fermer521
GoldenCrystalLe 01/07/2016 à 22:59
Le truc c'est qu'on peut tout faire avec une base SQL, mais c'est pas toujours suffisamment performant (ça dépend de la volumétrie, parfois ça scale très mal (ça dépend là aussi), et il arrive fréquemment que la modélisation relationnelle soit plus un problème qu'une solution. (i.e. quand ça n'apporte rien de positif: les objects)
En réalité, la base SQL c'est un peu le couteau suisse de la base de données. Si c'était vraiment naze, ça ferait longtemps qu'on aurait arrêté de s'en servir, et si c'était meilleur que tout, on aurait pas inventé d'autres types de bases de données qui sont bien plus avantageux dans des cas spécifiques. (Tout comme un couteau suisse est un outil génial quand tu pars en pique nique, randonnée ou camping, chez toi tu es bien mieux loti avec un tire-bouchons et un couteau d'office)

Pour ce qui est de choisir un système NoSQL, il faut garder en tête qu'il n'existe pas de solution universelle. Il y a plein de types de systèmes (relationnal, document storage, key-value store, graph, time series database, moteur de recherche, …) et beaucoup de recoupement entre chacun des types. La plupart des systèmes SQL/NoSQL rentrent dans plusieurs de ces typologies sans forcer, mais ils sont toujours meilleurs dans l'une d'entre elles par rapport aux autres.
Pour faire ton choix, tu dois être capable d'identifier ce que tu veux faire de ta donnée et vers quel(s) type(s) de système tu voudrais te tourner en conséquence. Puis, tu dois prendre en compte ta volumétrie et les performances attendues. Déterminer si ça doit être scalable horizontalement ou verticalement (ou les deux). Prendre en compte les systèmes dont tu disposes déjà et que tu maîtrises bien (ex: une base SQL). Te renseigner ce qui se fait de mieux au niveau du type de système dont tu aurais besoin. Et là alors, tu peux peut-être arriver à faire le bon choix grin

(PS: ça vous dit de forker ?)