#41
Et là, comment on utilise tout ça
Toute base de données a un langage d'interrogation. Il peut être divers et varié, ou carrément des composants spécialisés en développement. J'aborde ça dans la dernière partie dédiée à la technique pure.
Cependant, parlons en "littéral"
"Je veux les livres de Baudelaire disponibles"
Cela donne
"Chercher dans les exemplaires tous les livres dont le code auteur est égal à 3"
L'intérêt? Cela simplifie le classement! On peut même pousser le vice jusqu'à ajouter des notions de section de rangement, de position dans les étagères... et donc simplifier le travail de classement et d'organisation. En allant au bout de la démarche, cette notation logique facilite aussi les entrées et les sorties lors des achats et des retours des livres empruntés.
Très bien, c'est classé... et après?
Plus on gère correctement l'organisation, moins on prend de place, et plus les recherches vont vite. Typiquement, imaginez une bibliothèque de 50.000 ouvrages. On aura donc 50.000 exemplaires, mais combien d'auteurs? Bien moins. La recherche sera donc par auteur, et cela sortira à toute vitesse (indexation de la donnée) les exemplaires qui sont associés. Le statut pourra être un critère complémentaire
- Prêté
- En étagère
- En stock
- En restauration
- Détruit
Etc.
Rien qu'en ayant ces critères, on peut affiner.
On peut aussi affiner par style, par année d'édition, par format, par langue... il y a là des possibilités qui se multiplient sans pour autant pourrir les données stockées!
Et techniquement, c'est quoi une base de données?
Primo, une BDD c'est un "moteur". Il met à disposition la donnée qu'on peut interroger soit par des composants dédiés, soit par un langage adapté. Le plus connu est le SQL, qui est une vraie syntaxe d'interrogation.
Exemple: "Select * from exemplaires where idtitre=3"
Cela retournera les lignes dont le titre est codé "3".
Secondo, une BDD, c'est un choix car il existe quelques familles de BDD
- NoSQL, qui sont ... sans SQL. Ce sont des bases où l'on évite tant que faire se peut de les utiliser s'il y a beaucoup de données, mais sont extrêmement pratiques pour des données simples. Elles sont bien souvent structurées sur des fichiers textes, avec peu voire pas d'indexation. C'est notamment comme ça que sont stockés des articles de blog, ce qui épargne énormément de problèmes techniques et de complexité... au détriment des performances
- Les BDD SQL
Les plus courantes et les plus connues. elles sont toutes à utiliser le langage du SQL, en prenant pour seul écart que chaque moteur a la fâcheuse tendance à réinventer la poudre en adaptant les commandes avancées à leur sauce. Ceci étant, ce sont les plus simples à concevoir, à maintenir et à interroger.
- Les BDD Objet
Inaccessible au commun des mortels non formés au codage, elles construisent les informations sous la forme de langage objet. C'est très puissant, complet, performant... mais pas toujours adapté. Cela se réfléchit fortement car Facebook est sur un moteur de ce genre, mais cela n'est pas adapté à d'autres usages (banque par exemple)
Et que choisir?
Compliqué!
Chaque cas est unique, et donner des tendances est délicat. Pire, selon les modes, cela peut changer de discours. Personnellement, je prends comme base
- Complexité d'interrogation et maintenance aisée->SQL
- Volumétrie: à débattre entre Objet/SQL
- Simplicité sans volumétrie-> NoSQL
Payant/gratuit?
Difficile d'arbitrer. Les bases payantes intègrent des outils de suivi, de recherche, de maintenance et même de conception... là où le gratuit c'est "démerde-toi". Donc je n'arbitrerai pas. C'est globalement à arbitrer avec le client final et ses moyens.
Pour finir
Par pitié.. n'achetez de la BDD que quand ça se justifie! MySQL couvrira la majorité des besoins,, on pourra opter pour MongoDB (base objet) si la conception s'y prête... Acheter de l'Oracle ou du MsSQL ne sera utile QUE si cela s'intègre dans une problématique d'entreprise!
Toute base de données a un langage d'interrogation. Il peut être divers et varié, ou carrément des composants spécialisés en développement. J'aborde ça dans la dernière partie dédiée à la technique pure.
Cependant, parlons en "littéral"
"Je veux les livres de Baudelaire disponibles"
Cela donne
"Chercher dans les exemplaires tous les livres dont le code auteur est égal à 3"
L'intérêt? Cela simplifie le classement! On peut même pousser le vice jusqu'à ajouter des notions de section de rangement, de position dans les étagères... et donc simplifier le travail de classement et d'organisation. En allant au bout de la démarche, cette notation logique facilite aussi les entrées et les sorties lors des achats et des retours des livres empruntés.
Très bien, c'est classé... et après?
Plus on gère correctement l'organisation, moins on prend de place, et plus les recherches vont vite. Typiquement, imaginez une bibliothèque de 50.000 ouvrages. On aura donc 50.000 exemplaires, mais combien d'auteurs? Bien moins. La recherche sera donc par auteur, et cela sortira à toute vitesse (indexation de la donnée) les exemplaires qui sont associés. Le statut pourra être un critère complémentaire
- Prêté
- En étagère
- En stock
- En restauration
- Détruit
Etc.
Rien qu'en ayant ces critères, on peut affiner.
On peut aussi affiner par style, par année d'édition, par format, par langue... il y a là des possibilités qui se multiplient sans pour autant pourrir les données stockées!
Et techniquement, c'est quoi une base de données?
Primo, une BDD c'est un "moteur". Il met à disposition la donnée qu'on peut interroger soit par des composants dédiés, soit par un langage adapté. Le plus connu est le SQL, qui est une vraie syntaxe d'interrogation.
Exemple: "Select * from exemplaires where idtitre=3"
Cela retournera les lignes dont le titre est codé "3".
Secondo, une BDD, c'est un choix car il existe quelques familles de BDD
- NoSQL, qui sont ... sans SQL. Ce sont des bases où l'on évite tant que faire se peut de les utiliser s'il y a beaucoup de données, mais sont extrêmement pratiques pour des données simples. Elles sont bien souvent structurées sur des fichiers textes, avec peu voire pas d'indexation. C'est notamment comme ça que sont stockés des articles de blog, ce qui épargne énormément de problèmes techniques et de complexité... au détriment des performances
- Les BDD SQL
Les plus courantes et les plus connues. elles sont toutes à utiliser le langage du SQL, en prenant pour seul écart que chaque moteur a la fâcheuse tendance à réinventer la poudre en adaptant les commandes avancées à leur sauce. Ceci étant, ce sont les plus simples à concevoir, à maintenir et à interroger.
- Les BDD Objet
Inaccessible au commun des mortels non formés au codage, elles construisent les informations sous la forme de langage objet. C'est très puissant, complet, performant... mais pas toujours adapté. Cela se réfléchit fortement car Facebook est sur un moteur de ce genre, mais cela n'est pas adapté à d'autres usages (banque par exemple)
Et que choisir?
Compliqué!
Chaque cas est unique, et donner des tendances est délicat. Pire, selon les modes, cela peut changer de discours. Personnellement, je prends comme base
- Complexité d'interrogation et maintenance aisée->SQL
- Volumétrie: à débattre entre Objet/SQL
- Simplicité sans volumétrie-> NoSQL
Payant/gratuit?
Difficile d'arbitrer. Les bases payantes intègrent des outils de suivi, de recherche, de maintenance et même de conception... là où le gratuit c'est "démerde-toi". Donc je n'arbitrerai pas. C'est globalement à arbitrer avec le client final et ses moyens.
Pour finir
Par pitié.. n'achetez de la BDD que quand ça se justifie! MySQL couvrira la majorité des besoins,, on pourra opter pour MongoDB (base objet) si la conception s'y prête... Acheter de l'Oracle ou du MsSQL ne sera utile QUE si cela s'intègre dans une problématique d'entreprise!
