Pour Kibest: DM de programmation

  • Auteur de la discussion magellan
  • Date de début

magellan

Modérâleur
Staff
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!
 

SergioVE

Tout à faire car rien n'est fait.
Dès la fin des années 90, on avait le droit à la débilité du "faut que ça claque visuellement!"... Essaye de rendre sexy une application comptable toi...
C'est sans doute un peu plus calme aujourd'hui, les grosses boîtes ayant heureusement toutes une charte graphique pour leurs applicatifs tant internes qu'externes.
 

magellan

Modérâleur
Staff
C'est sans doute un peu plus calme aujourd'hui, les grosses boîtes ayant heureusement toutes une charte graphique pour leurs applicatifs tant internes qu'externes.
Moui... plus c'est gros plus cela devient difficile à estimer. Ayant eu comme client des trèèès grosses structures... ça va du "on a une charte vous l'utilisez", jusqu'au "on réforme! On refait! Faut changer l'image de la boite!"
:/
 

SergioVE

Tout à faire car rien n'est fait.
Moui... plus c'est gros plus cela devient difficile à estimer. Ayant eu comme client des trèèès grosses structures... ça va du "on a une charte vous l'utilisez", jusqu'au "on réforme! On refait! Faut changer l'image de la boite!"
:/
Le "on refait" ça fait marcher le business !
 

magellan

Modérâleur
Staff
Le "on refait" ça fait marcher le business !
Même pas en plus... si seulement: Pour des sites en interne, qu'on m'explique où est le business à l'échelle de la société. Pour le presta? Oui... ça oui pourquoi pas, mais pourquoi ces... [CENSURE] de la DSI veulent revoir les sites? Pour laisser leur empreinte!
 

magellan

Modérâleur
Staff
Sinon: si quelqu'un voit des choses à retoucher sur les BDD ou autres, qu'il me fasse signe.
 

SergioVE

Tout à faire car rien n'est fait.
Faudrait créer un fil "Les fondements (*) du développement" et épingler tes posts en tête ! Et peut-être aborder la question des tests pré-prod.
(*) aucun rapport avec ton doigt vengeur, bien sûr ! :crazy:
 

magellan

Modérâleur
Staff
A la demande de @SergioVE quelques explications sur ce que sont les phases de recettes.

Déjà, c'est quoi une recette?
Faisons un point de vocabulaire: faire une recette, c'est passer en revue toutes les fonctionnalités d'un environnement et en valider le fonctionnement... avec si possible la confirmation que la version en cours ne fait pas péter les choses qui fonctionnaient avant.

Cela se passe en plusieurs phases, et idéalement toutes ces étapes sont réalisées pour éviter au mieux les éventuels bugs évidents, voire même de faire une livraison "nickel".
Nota: nickel ne veut pas dire parfait. On peut toujours améliorer, corriger des bugs non vus pendant les tests... bref faire des patchs et des mises à jour!

Comment ça se passe?
Il faut bien raisonner que les étapes de tests sont radicalement différentes selon la façon de fonctionner le projet informatique. Je dois donc aborder un peu quelques exemples de gestion de projet qui mènent à des tests organisés de manières très différentes
- Le cycle en "V"
Avantages:
- C'est du gros projet qui dure, où les équipes ne livrent que des version majeures. Cela donne donc de gros blocs qui sont poussés avec un intérêt réel à chaque mise à jour. De plus, on inclue à chaque version majeure les nouvelles fonctionnalités (ce qui est très visible) autant que le cumul de correctifs (pas toujours évidents à voir)
Inconvénients:
- Effet "tunnel". En gros, entre deux versions, c'est le silence radio. On attend les patchs et mises à jour en espérant que cela vaudra la peine de patienter. Pire, cela peut même mener à des mises à jour payantes, ce qui peut faire grincer des dents.
- Les logiciels à extensions: cela donne donc que des patchs et mises à jour sont vendues et plus uniquement fournies à celles et ceux qui possèdent le logiciel.

- Les divers méthodes dites "Agile"
Avantages:
- des cycles courts de développement. Cela peut même descendre à la semaine voire moins pour patcher les applications. On livre globalement de petites itérations "aisées" à identifier.
- Des spécifications souples où les évolutions sont rédigées en très peu de temps. On peut donc voir apparaître des fonctionnalités plus rapidement que si l'on attend une version majeure.
Inconvénients:
- Peut donner un enchaînement de patchs successifs parce qu'un bug n'est pas correctement corrigé (urgence du cycle de livraison)
- Une certaine instabilité dans la cohérence de l'application. Cela peut se remarquer quand des parties de l'application sont différentes tant dans l'esthétique que de l'ergonomie par exemple.
- Une vraie nécessité de direction ferme dans les choix. Si le développement se soumet trop aux impératifs commerciaux, on peut en arriver à des dérives avec des "on accepte de tout faire même si c'est idiot".

Alors quels tests concrètement?
Les tests unitaires
Les tests unitaires sont ceux où le développeur vérifie que ce qu'il a réalisé fonctionne... dans son environnement. Concrètement, il vérifie qu'il respecte ce qui est attendu. S'il est minutieux, il poussera ces tests jusqu'à ce que cela soit cohérent et assez propre pour aller plus loin. Globalement, il couvrira pas mal des bugs évidents.
Les tests d'intégration
Là, une fois le tout à peu près validé, on fournit le tout à une autre personne que le développeur lui-même. Il va tester le développement dans un environnement un peu plus complet, voire sur plusieurs environnements de tests (machines différentes, performances différentes, données différentes et surtout plus complexes...)
Les tests de non-régression
Pas toujours faits correctement, ils permettent de vérifier que tout ce qui fonctionnait avant fonctionne toujours après mise à jour.
Les tests de préproduction
Schématiquement, une fois que les allers-retours des tests précédents sont "terminés, si l'on bosse bien (et surtout si on a le personnel et le temps pour), on place le produit en "beta". Pour les jeux, en gros, c'est ce qu'on peut désormais appeler les "early-access". Dans un environnement professionnel, on monte des environnements "identiques" à la production de manière reproduire le monde réel. On teste là via des gens qui vont utiliser le programme en conditions réelles, en effectuant en gros les mêmes tâches qu'avec la version n-1 (dans le cas d'une mise à jour surtout)
La mise en production
Là, on ouvre les vannes et on distribue. Tout simplement.

Là, en principe, on a un cycle propre et suffisamment cadré pour que cela soit propre et suffisamment qualitatif pour que tout roule... sans trop de soucis.

SAUF QUE... comme toujours, tests toujours insuffisants oblige, on doit pallier à l'urgence
Et on fait quoi dans le feu de l'action?
Si c'est l'enfer avec un bug bloquant, on identifie le bug, on corrige, et on patche en urgence, quitte à sauter des étapes de tests. Généralement, les bugs bloquants sont plus simples à reproduire et à corriger qu'on croit. Ce sont les bugs vicieux, peu visibles qui posent de vrais gros soucis de reproduction et de correction.
Donc là, on pousse le patch le plus vite possible.

Et tout ça, cela requiert surtout et avant tout une gestion des sources RIGOUREUSE. Sans ce suivi? Oubliez tout développement sur le long terme, car vous ne pourrez faire que des erreurs...

Ah et du vocabulaire
- Version mineure:
Globalement des corrections mineures et généralement non bloquantes. Peut inclure de petites améliorations, mais rien quoi soit fondamental
- Version majeure: Mise à jour contenant souvent de l'extension de contenu et/ou de fonctionnalités. Apporte aussi très souvent des corrections de bugs bloquants ou très gênants.
- Patch: Composant de déploiement d'une mise à jour
- Version alpha: Première version fournie permettant de procéder aux premiers tests. Généralement, les alpha sont pétries de bugs, et le résultat final n'a plus aucun rapport avec la version alpha considérée.
- Version beta: C'est une version alpha qui a été mise à jour avec plein de corrections. Généralement, la beta n'est pas très loin de la version de production... Encore que, il est encore tout à fait possible d'y trouver d'énormes bugs très graves. Cela sert normalement à la partie tests de qualité (Q&A)
- Régression: Un bug qui apparaît sur une fonctionnalité qui fonctionnait auparavant. Attention à ne pas vous faire avoir par ceux qui vous gueulent dessus à propos des bugs! Une régression c'est "ça marchait avant, ça ne marche plus" et pas "tiens cette nouvelle fonctionnalité déconne, c'est une régression". Théoriquement, la régression ne doit pas se produire, car cela démontre un manque de tests flagrants... ou une certaine incompétence chez les développeurs.
- Effet de bord: en gros, c'est un bout de code réutilisé qui, mis à jour, fait foirer d'autres parties du code. Cela génère des bugs inattendus. Un petit exemple s'impose pour comprendre. Admettons qu'une partie du code permet de faire de la correction orthographique un peu partout dans l'application. Admettons une modification de ce correcteur qui marche dans un test spécifique, mais met la grouille partout ailleurs. L'effet de bord est donc que l'évolution du correcteur a des bugs qui cassent ce qui marchait avant.
- Déploiement: Action de distribuer l'application/mise à jour
 

SergioVE

Tout à faire car rien n'est fait.
Merci @magellan ! Net, clair et concis, comme tes chapitres précédents.
C'est un cadre sans doute peu pertinent pour en parler ici, mais il existe encore et toujours des applications dites "batch" ou par lot, c'est à dire qui traitent uniquement des fichiers. Pour ces applications, on utilise habituellement des "jeux d'essai", fichiers conçus en principe par les auteurs du cahier des charges du projet. L'exploitation correcte de ces fichiers lors des tests permet de s'assurer facilement du bon fonctionnement de l'applicatif et bien sûr de l'absence de régression. Si toutefois les jeux d'essai sont complets et à jour...
 

magellan

Modérâleur
Staff
Merci @magellan ! Net, clair et concis, comme tes chapitres précédents.
C'est un cadre sans doute peu pertinent pour en parler ici, mais il existe encore et toujours des applications dites "batch" ou par lot, c'est à dire qui traitent uniquement des fichiers. Pour ces applications, on utilise habituellement des "jeux d'essai", fichiers conçus en principe par les auteurs du cahier des charges du projet. L'exploitation correcte de ces fichiers lors des tests permet de s'assurer facilement du bon fonctionnement de l'applicatif et bien sûr de l'absence de régression. Si toutefois les jeux d'essai sont complets et à jour...
ça c'est un autre sujet que je peux traiter si tu y tiens.
 

SergioVE

Tout à faire car rien n'est fait.
ça c'est un autre sujet que je peux traiter si tu y tiens.
Sur un forum micro, les traitements batch c'est peu hors-sujet, bien qu'il en existe forcément dans des logiciels comptables ou de paie par exemple... Mais si tu connais d'autres utilisations des jeux d'essais, pourquoi pas ? Je n'ai jamais vu en entreprise des protocoles de tests détaillés, complets, définis avec des données précises et les résultats attendus dans un cahier des charges d'appli temps réel ou micro, mais ça ne prouve pas leur inexistence...
 

magellan

Modérâleur
Staff
Automatiser les tests... est-ce possible?
Oui... Et non. En gros, restons sur des données plutôt que sur des choses comme les jeux. Quand on traite de la donnée, on peut construire des scénarios fermes et répétables qui ne doivent théoriquement pas évoluer avec le temps.
Alors, oui, on peut effectivement automatiser les tests, faire en sorte que cela se construise tout seul, afin que les développeurs et les testeurs aient des rapports circonstanciés.

Comment ça se passe concrètement?
On passe par trois étapes
- Construire les choses à tester
- Mettre en place des données définitives qui couvrent "tous les cas possibles"
- Intégrer des outils permettant l'exécution automatique de tous les tests.

Les choses à tester
Si l'on fait bien son job, la partie traitement est dissociée de la présentation. Dans les faits, cela veut dire qu'on injecte dans des appels logiciels les données à traiter, et qu'en sortie on doit toujours avoir le même résultat. Donc, on bâtit ses développements afin qu'ils puissent être interrogés sans qu'aucun clic utilisateur soit requis.

Les données
On place toujours les mêmes données afin que chaque nouveau test exécuté se fasse sur les mêmes résultats attendus. On ne va pas aller modifier ces valeurs sans raison, sous peine de biaiser les résultats finaux

Les automates
Il y a quantité de manières pour le faire. Les environnements de développement bien configurés permettent de créer des scripts pour ces robots de tests. Au surplus, on peut les enrichir à chaque fois qu'une nouvelle étape/fonctionnalité est à prendre en compte.

A terme, le but est que "toute l'application" soit passée au filtre des tests automatisés, sans intervention humaine ou presque.

Et comment on automatise vraiment?
En étant rigoureux. Si l'on gère correctement ses sources, chaque nouveau dépôt de modification vient s'injecter dans la version de développement, puis cette version est exécutée soit à la demande, soit toutes les nuits par l'automate. Une fois l'intégration et les tests terminés, le rapport de test donne une vue sur tous les résultats obtenus.
En prenant l'historique, en comparant chaque résultat (merci les comparateurs de texte inclus dans notepad++ ou Winmerge par exemple), on voit les écarts qu'on analysera au cas par cas.

Encore mieux: si les logs sont strictement identiques, on peut même pousser un compilé quotidien tant que les résultats des tests ne diffèrent pas de ceux attendus! Cela donne une version quotidienne du produit, toujours à jour, et toujours disponible pour distribution en phase beta. C'est qu'utilisaient (dans le temps... aujourd'hui je n'en sais rien) les développeurs chez Firefox! En prenant le parti de mettre à jour à chaque nouveau dépôt de compilé, on pouvait donc avoir perpétuellement la dernière version du navigateur.

Et c'est efficace, VRAIMENT?!
Mauvaise question: si c'est bien fait, c'est vital. Si c'est mal fait, autant s'en passer.
Il a y des pro déploiement et tests auto, d'autres qui s'y opposent fermement.
Pour ma part, je suis partagé car chaque clan a de bonnes raisons de défendre son point de vue.
Les +
* Efficace et pertinent surtout s'il y a énormément de tests différents à effectuer
* Zéro intervention humaine: tout se fait automatiquement, l'outil n'oubliera aucun des tests configurés
* Résultats toujours pertinents en regard des tests inclus dans le moteur
Les -
* Difficile à maintenir... d'autant plus si les devs n'aiment pas le faire, ou pire encore s'ils ne savent pas le faire correctement... ou n'en ont pas vraiment le temps
* Taille exponentielle des différences. Plus le programme évolue dans sa complexité, plus les résultats seront riches jusqu'à finir inexploitables car trop nombreux
* Fiabilité en regard des paramétrages. Un oubli et c'est l'échec et l'invalidation de tous les tests effectués.

C'est une chose qui s'instaure au début du projet et non en cours de route. L'existant est l'ennemi du développeur, car souvent (toujours?) rien n'est conçu pour fédérer les tests. Donc, déjà, avant même de pondre une ligne, on se retrouve face à un périmètre difficile à encadrer. Pire encore, cela prend du temps, beaucoup de temps, trop de temps pour en justifier la nécessité auprès des clients. Ceci dit, les mentalités évoluent, et plus le produit sera sensible, plus le client acceptera ces délais induits par la mise en place d'outils et le suivi des anomalies.

N'oubliez jamais cet adage: tout produit fini aura un bug inconnu qui émergera spontanément. Tout bug inconnu puis corrigé donnera forcément lieu à des doutes sur la fiabilité du produit... surtout si de nouvelles anomalies apparaissent dans la foulée d'une mise à jour.

Et pire que tout: si on vous dit "cela ne marche plus depuis la mise à jour", vérifiez d'abord si le code a évolué dans la zone supposée buggée. Si la réponse est négative, pas de panique, c'est l'effet "mise à jour". Soit cela a révélé un bug existant... ou plus chiant soit l'utilisateur met une erreur de sa part sur le dos du patch. Restez calme, et analysez!
 

SergioVE

Tout à faire car rien n'est fait.
Allez, une anecdote préhistorique pour illustrer ça. Mon premier boulot était dans une compagnie d'assurances sur la vie et le DI aimait bien raconter son pire cauchemar de jeunesse.
Tous les ans, la compagnie devait calculer les provisions mathématiques de tout son portefeuille à l'aide d'une formule assez compliquée. La machine de l'époque avait 4K de mémoire (oui, quatre kilos non pas octets d'ailleurs mais sextets) et se programmait en langage machine (non, non, pas en assembleur). De gros programmes de ce type en utilisaient la totalité. Tous les ans, avant de traiter le million de cartes perforées du stock, un jeu d'essai de quelques centaines de cartes était passé, et l'actuaire qui l'avait établi contrôlait le résultat. Après son feu vert, l'ensemble des cartes passait à la moulinette. Et voilà qu'une année, catastrophe : résultats faux. Après deux jours entiers d'efforts, le bug a été trouvé. Comme diviseur pour les contrats semestriels, c'était le "6" de la décennie de la date d'exercice qui était utilisé. Mais là, c'était 1970... Ensuite encore une demi-journée de boulot pour trouver une place pour ce foutu 6 !
 

magellan

Modérâleur
Staff
Allez, une anecdote préhistorique pour illustrer ça. Mon premier boulot était dans une compagnie d'assurances sur la vie et le DI aimait bien raconter son pire cauchemar de jeunesse.
Tous les ans, la compagnie devait calculer les provisions mathématiques de tout son portefeuille à l'aide d'une formule assez compliquée. La machine de l'époque avait 4K de mémoire (oui, quatre kilos non pas octets d'ailleurs mais sextets) et se programmait en langage machine (non, non, pas en assembleur). De gros programmes de ce type en utilisaient la totalité. Tous les ans, avant de traiter le million de cartes perforées du stock, un jeu d'essai de quelques centaines de cartes était passé, et l'actuaire qui l'avait établi contrôlait le résultat. Après son feu vert, l'ensemble des cartes passait à la moulinette. Et voilà qu'une année, catastrophe : résultats faux. Après deux jours entiers d'efforts, le bug a été trouvé. Comme diviseur pour les contrats semestriels, c'était le "6" de la décennie de la date d'exercice qui était utilisé. Mais là, c'était 1970... Ensuite encore une demi-journée de boulot pour trouver une place pour ce foutu 6 !
Classique.

Je me suis cogné la révision et la réécriture de programmes sous Dos qui traitaient l'année sur deux caractères... avant l'an 2000.

Tu vois où je veux en venir?
 

SergioVE

Tout à faire car rien n'est fait.
Classique.

Je me suis cogné la révision et la réécriture de programmes sous Dos qui traitaient l'année sur deux caractères... avant l'an 2000.

Tu vois où je veux en venir?
Ah ben oui, j'ai donné aussi, mais avec sans doute beaucoup moins de boulot que toi, toutes les dates venant du host étaient depuis longtemps en AAAAMMJJ. Le plus pénible pour nous a été de tester tous les micros du parc, un par un, pour voir comment ils passeraient la nuit fatidique... Tous les IBM étaient OK ; dans les exotiques, comme on disait alors, quelques surprises !
On avait aussi le souci des Macs, pour lesquels l'origine des temps était le 1er janvier 1904 et non 1900, parce que les fainéants d'Apple voulaient se débarrasser du 29 février 1900 qui n'existe pas... Y avait même pour ça une case spéciale à cocher dans Excel Windows pour traiter correctement les tableaux issus des Macs.
 

AccroPC2

Fou du PC
Staff
@magellan très joli topic, on constate ta grande expérience du métier toutefois sur les bases de données ( probablement le sujet que je connais le mieux ), je ne suis pas tout à fait d'accord avec toi, sur les points suivants :

Le NoSQL ( Not Only SQL ) : en général c'est un peu compliqué car chaque moteur ou presque est unique. Là ou sur un moteur SQL, on retrouve les fondamentaux dans tous les moteurs ( même si l'implémentation diffère ). On choisira un moteur en fonction de son usage car ils sont en général beaucoup plus performant ( et souvent scalable ) qu'un base SQL ( si on respecte le cas d'usage sinon ils peuvent se montrer excessivement lent également ). On pourrait citer Cassandra, HBase, Hadoop qui répondent à des cas d'usage précis mais sont prévues pour traiter des péta de données.
MongoDB est également un moteur NoSQL, très simple à utiliser, installer, administrer et normalement, il plait aux développeurs grâce à son format natif "JSON".
Dans tous les cas, si on choisit une base NoSQL c'est qu'on sait exactement ce qu'on va faire avec et la problématique que le moteur permet de résoudre.

Perso plus je bosse avec MySQL et moins j'aime ce moteur. Postgresql a de loin ma préférence en moteur gratuit. Après je pense que si on fait abstraction du prix qui est juste scandaleux, Oracle reste la rolls. Sinon M$ SqlServer dans sa version Express est gratuite ( mais très limitée ).

Bye
 

magellan

Modérâleur
Staff
@magellan très joli topic, on constate ta grande expérience du métier toutefois sur les bases de données ( probablement le sujet que je connais le mieux ), je ne suis pas tout à fait d'accord avec toi, sur les points suivants :

Le NoSQL ( Not Only SQL ) : en général c'est un peu compliqué car chaque moteur ou presque est unique. Là ou sur un moteur SQL, on retrouve les fondamentaux dans tous les moteurs ( même si l'implémentation diffère ). On choisira un moteur en fonction de son usage car ils sont en général beaucoup plus performant ( et souvent scalable ) qu'un base SQL ( si on respecte le cas d'usage sinon ils peuvent se montrer excessivement lent également ). On pourrait citer Cassandra, HBase, Hadoop qui répondent à des cas d'usage précis mais sont prévues pour traiter des péta de données.
MongoDB est également un moteur NoSQL, très simple à utiliser, installer, administrer et normalement, il plait aux développeurs grâce à son format natif "JSON".
Dans tous les cas, si on choisit une base NoSQL c'est qu'on sait exactement ce qu'on va faire avec et la problématique que le moteur permet de résoudre.

Perso plus je bosse avec MySQL et moins j'aime ce moteur. Postgresql a de loin ma préférence en moteur gratuit. Après je pense que si on fait abstraction du prix qui est juste scandaleux, Oracle reste la rolls. Sinon M$ SqlServer dans sa version Express est gratuite ( mais très limitée ).

Bye
Perso je distingue les bases objets des base "NoSql" au sens "pas de SQL". Je songe notamment à ces machins faits en XML pour les blogs qui, s'ils fonctionnent comme des BDD en théorie, en pratique explosent en vol au-delà d'une certaine volumétrie.

Pour ce que tu dis sur la distinction SQL/Objet, c'est ce que je dis: ça n'est pas tant une problématique de volumétrie que de conception et de fonctionnalités.

Enfin pour le choix de MySQL, c'est avant tout parce qu'il est plus que suffisant pour une bonne partie des projets. inutile d'aller dans du Oracle si la volumétrie ne le justifie pas, notamment parce que le coût induit n'est pas rattrapé par les usages.

PS: Ms a un moteur que je pratique depuis 99 ... et je lui trouve comme énorme avantage des outils annexes de conception... mais GROS DOIGT faute de pouvoir les faire hors de Windows (là où tous les autres le permettent).
 

AccroPC2

Fou du PC
Staff
NoSQL est un peu un fourre tout, par exemple Cassandra est du NoSQL et pourtant son langage d'interrogation est du SQL.

NoSQL ce sont plus toutes les bases de données qui en fait ne sont pas vraiment "Relationnelles", souvent parce qu'elle s’assoit sur le principe "ACID" des SGBDR pour apporter d'autres fonctionnalités. ( voir le théorème de CAP ).

On est d'accord sur Oracle et son prix. Reste que si postgres est probablement moins "user friendly", elle me semble bien plus "fiable" que du MySQL. A tel point que, toujours de mon point de vue, je ne mettrai aucune donnée que je ne peux pas me permettre de perdre dans du MySQL.

Bye
 

magellan

Modérâleur
Staff
NoSQL est un peu un fourre tout, par exemple Cassandra est du NoSQL et pourtant son langage d'interrogation est du SQL.

NoSQL ce sont plus toutes les bases de données qui en fait ne sont pas vraiment "Relationnelles", souvent parce qu'elle s’assoit sur le principe "ACID" des SGBDR pour apporter d'autres fonctionnalités. ( voir le théorème de CAP ).

On est d'accord sur Oracle et son prix. Reste que si postgres est probablement moins "user friendly", elle me semble bien plus "fiable" que du MySQL. A tel point que, toujours de mon point de vue, je ne mettrai aucune donnée que je ne peux pas me permettre de perdre dans du MySQL.

Bye
Merci pour ces précisions (tant pour le lecteur que pour moi-même). Je fais la dichotomie parce que je trouve que le fourre-tout en informatique est une belle ânerie qui ne fait que rendre obscur un sujet qui se devrait d'être clair. Dans tous les cas, ça m'aide à affiner le propos.

Côté fiabilité, je ne dirai rien dans un sens ou l'autre, car mon retour sur expérience personnelle ne corrobore pas tes propos... Mais cela reste personnel et pas généralisable pour deux sous.. J'ai essentiellement utilisé PostGres, bien plus que MySql en tout cas, et ce qui m'a incité à parler de MySQL c'est qu'il a pour lui une très forte facilité d'intégration via les LAMP/WAMP, chose qui pour un débutant est un énorme avantage. Disons juste que j'ai encore en production des dizaines de bases en MySQL avec de la donnée très sensibles, et je n'ai jamais vu la moindre perte, et qu'on parle de dizaines voire centaines d'utilisateurs en simultané. Par contre ce qui est sûr, c'est que si tu prends les patch notes (comme je le fais à chaque MAJ même mineure des BDD en question), tu peux trouver des trucs délicats voire mauvais sur chaque moteur... Oracle compris.

Après, je ne te contredirai pas, tu es visiblement autrement plus pointu que moi sur le sujet (et je t'en félicite car c'est une expertise trèèèès difficile à acquérir tant ce domaine contient des choses très hétéroclites). C'est d'autant plus vrai sur les bases 'objet' sur lesquels j'ai eu un retour sur expérience allant du "très bon... si on sait où on va" au "C'est quoi ce bordel?!", et cela a probablement évolué car là je parle de l'intégration de ces BDD spécifiques à leur apparition, et non aujourd'hui. Cela a probablement énormément évolué entre les deux. Donc, mon avis sur ces BDD est daté et prête énormément à caution.
 

LeeLarant

Speedy Configales, le plus rapide de tout TH
Staff
@magellan je repensais.
En c# il vaut mieux les listes ou les tableaux?
Je kiffe les listes, quand même bien moins de bazard que les tableaux. (Et la fonction add remove est trop géniale)
Mais en terme de performances, lisibilité et fonctionnalités?
:)
 
Vous devez vous inscrire ou vous connecter pour répondre ici.
Derniers messages publiés
Statistiques globales
Discussions
730 098
Messages
6 717 056
Membres
1 586 284
Dernier membre
fjfkfjfkfjfjcj
Partager cette page
Haut