J'écris ceci mais comme une contestation de la réponse de Rex.
Je conteste l'idée que le nosql est sans relation et flou.
J'avais travaillé avec CODASYL il y a de nombreuses années avec C et Cobol - les relations entre entités sont très étroites dans CODASYL.
En revanche, les systèmes de bases de données relationnelles ont une politique très libérale à l'égard des relations. Tant que vous pouvez identifier une clé étrangère, vous pouvez former une relation adhoc.
Il est souvent considéré comme acquis que SQL est synonyme de SGBDR, mais des personnes ont écrit des pilotes SQL pour CODASYL, XML, des ensembles inversés, etc.
RDBMS/SQL ne sont pas synonymes de précision des données ou des relations. En fait, les SGBDR ont été une cause constante d'imprécision et de mauvaise perception des relations. Je ne vois pas comment les SGBDR offrent une meilleure intégrité des données et des relations que hadoop, par exemple. Mettez une couche de JDO - et nous pouvons construire un réseau de bonnes et propres relations entre les entités dans hadoop.
Cependant, j'aime travailler avec SQL parce qu'il me donne la possibilité de script des relations adhoc, même si je réalise que les relations adhoc sont une cause constante d'adultération des relations et de problèmes.
Ayant l'occasion de travailler avec l'analyse statistique des processus commerciaux et industriels, SQL m'a donné la possibilité d'explorer des relations là où aucune relation n'avait été perçue auparavant. L'opportunité de travailler avec l'analyse statistique m'a donné la possibilité d'explorer des relations que les programmeurs SQL n'auraient normalement pas perçues.
Par exemple, vous concevrez et normaliserez votre schéma pour refléter un ensemble de processus. Ce dont vous ne vous rendez peut-être pas compte, c'est que les relations évoluent avec le temps. Les caractéristiques statistiques révéleraient qu'un schéma n'est peut-être plus aussi "correctement normalisé" qu'il l'était auparavant. Que les principales composantes des processus ont muté au fil du temps. Mais les programmeurs non statisticiens ne comprennent pas cela et continuent de vanter les mérites des SGBDR comme étant la solution parfaite pour l'intégrité des données et la précision des relations.
Cependant, dans une base de données de liens relationnels, vous pourriez lier les entités dans les relations au fur et à mesure qu'elles apparaissent. Lorsque les relations mutent, les liens mutent naturellement avec les données. Les relations et leur mutation sont documentées dans le système de base de données sans qu'il soit nécessaire de renormaliser le schéma, ce qui est coûteux. À ce stade, le SGBDR n'est bon qu'en tant que base de données temporaire.
Mais vous pourriez alors rétorquer que le SGBDR vous permet également de modifier vos relations de manière flexible, puisque c'est ce que SQL fait le mieux. C'est vrai, très vrai - tant que vous effectuez BCNF ou même 4NF. Sinon, vous commencerez à voir que vos requêtes et vos chargeurs de données effectuent des opérations répliquées. Mais vos nombreuses années d'expérience dans le domaine des SGBDR vous ont certainement fait prendre conscience que BCNF est très coûteux et inefficace d'un point de vue opérationnel et que nous sommes constamment coupables de 2,5 NFer nos schémas.
Dire que les SGBDR et le SQL favorisent l'intégrité des données et des relations est une erreur grossière. Soit vous travaillez dans une entreprise si minuscule, soit vous n'êtes pas resté à votre poste pendant plus de deux ans - vous ne verriez pas la quantité de données ou la mutation des informations et les problèmes causés par les SGBDR. L'abus des SGBDR est à l'origine du fait que les cadres sont limités dans leur vision par les applications informatiques et à l'origine des échecs financiers des entreprises qui ne voient pas les changements dans le comportement du marché parce que leur vision est limitée par les programmeurs dont la vision est limitée à leur vénération de leurs chers schémas de SGBDR.
C'est pourquoi les programmeurs SQL ne comprennent pas pourquoi le statisticien de votre entreprise refuse d'utiliser votre application, que vous avez conçue méticuleusement, alors qu'il a employé un stagiaire universitaire pour écrire du SQL afin de télécharger des données sur ses serveurs personnels, et que les cadres de votre entreprise apprennent à faire confiance aux feuilles de calcul des comptables et des statisticiens plutôt qu'à vos élégantes applications à plusieurs niveaux, en raison de l'incapacité de vos applications à évoluer avec les processus.
Ce n'est peut-être pas possible, mais je vous invite tout de même à acquérir quelques connaissances statistiques pour percevoir comment les processus évoluent dans le temps, afin de pouvoir prendre la bonne décision technologique.
La raison pour laquelle les gens ne passent pas au SQL-less est l'absence d'un bon environnement de script comme SQL pour effectuer des analyses de relations adhoc. Ce n'est pas parce que la technologie SQL-less manque de précision ou d'intégrité. L'analyse des relations adhoc est très importante aujourd'hui en raison des attitudes et stratégies de développement rapide et agile des applications que nous connaissons aujourd'hui.
