Moi je ne connais pas le noSQl pour moi l’intérêt d'un SGBDR est justement :
1- le format de données est fixe et connu. On ne stoque pas une date à la place d'un nombre, ni une chaine de caractère à la place d'un nombre.
2- Le relationnel (le R à la fin de SGBDR) et les contraintes d’intégrité. Si j'enregistre une clé étrangère, par exemple l'identifiant d'un auteur pour une table de libre, si l'identifiant est inconnu , je ne peux pas enregistrer mon libre. Je ne pourrais pas non plus supprimer un auteur ayant des livres ou alors demande à la base de donnée de supprimer tous les libres quand je supprime au auteur. Mais dans tous les cas je n'aurait jamais de livre sans auteurs, ou dans un autre cas d’école de facture sans client.
Le SQL est juste une manière d'accéder au SGBDR, c'est la manière historique, après tu peux utiliser un système mapping objet qui transformera ton code en SQL pour toi.
Mais souvent la grosse lacune de tous ces systèmes sont les opérations ensemblistes (Je veux dupliquer toutes les rendez-vous de type "répétition automatique" de cette année pour l'année prochaine quand la table de rendez-vous fait quelques millions de lignes) ou les jointures entre table (je veux la liste de livres édité par les maison d’éditions ayant leur siège social à Paris et dont un auteur au moins à plus de 50 ans). Sans parler des fonctions d’agrégations : je veux la plus petite date et la plus grande date de publication de tous les libres d'un auteur.
Toutes ses traitements se font en une requête SQL.
Tu laisse le SGBDR gérer la complexité d'optimiser l’accès aux données, et il le fait en principe très bien. Si ton SGBDR est sous forme de service accessible en réseaux en plus, tu peux libérer de la charge CPU sur ton serveur qui effectue le traitement. La base de donnée pouvant être parallélisé sur plusieurs serveur avec les SGBDR les plus évolués.
Le plus important c'est le SGBDR, et le meilleur moyen d'en exploiter toute la subtilité est le SQL.
[^] # Re: C'est vrais du coup, quel intérêt ?
Posté par Benbben . En réponse au journal Témoignage d'expérience de nosql avec PHP et Mongodb. Évalué à 10.
Moi je ne connais pas le noSQl pour moi l’intérêt d'un SGBDR est justement :
1- le format de données est fixe et connu. On ne stoque pas une date à la place d'un nombre, ni une chaine de caractère à la place d'un nombre.
2- Le relationnel (le R à la fin de SGBDR) et les contraintes d’intégrité. Si j'enregistre une clé étrangère, par exemple l'identifiant d'un auteur pour une table de libre, si l'identifiant est inconnu , je ne peux pas enregistrer mon libre. Je ne pourrais pas non plus supprimer un auteur ayant des livres ou alors demande à la base de donnée de supprimer tous les libres quand je supprime au auteur. Mais dans tous les cas je n'aurait jamais de livre sans auteurs, ou dans un autre cas d’école de facture sans client.
Le SQL est juste une manière d'accéder au SGBDR, c'est la manière historique, après tu peux utiliser un système mapping objet qui transformera ton code en SQL pour toi.
Mais souvent la grosse lacune de tous ces systèmes sont les opérations ensemblistes (Je veux dupliquer toutes les rendez-vous de type "répétition automatique" de cette année pour l'année prochaine quand la table de rendez-vous fait quelques millions de lignes) ou les jointures entre table (je veux la liste de livres édité par les maison d’éditions ayant leur siège social à Paris et dont un auteur au moins à plus de 50 ans). Sans parler des fonctions d’agrégations : je veux la plus petite date et la plus grande date de publication de tous les libres d'un auteur.
Toutes ses traitements se font en une requête SQL.
Tu laisse le SGBDR gérer la complexité d'optimiser l’accès aux données, et il le fait en principe très bien. Si ton SGBDR est sous forme de service accessible en réseaux en plus, tu peux libérer de la charge CPU sur ton serveur qui effectue le traitement. La base de donnée pouvant être parallélisé sur plusieurs serveur avec les SGBDR les plus évolués.
Le plus important c'est le SGBDR, et le meilleur moyen d'en exploiter toute la subtilité est le SQL.