Je fais du développement web amateur en php depuis quelques années maintenant et un ami développeur qui déteste coder pour le web et qui n'a pas le temps pour ça m'a récemment demandé de lui développer un site internet pour ses bêta-testeurs, quelque chose de simple où les utilisateurs auraient accès aux différents projets auxquels ils sont inscrits.
Je n'avais jusqu'à maintenant jamais eu le courage de m'attaquer aux bases de données et encore moins au langage sql, même si j'aurais sans doute été capable de m'y mettre, j'avais toujours repoussé mes différents projets, ayant l'étrange impression que l'intégration de sql dans php était un peu comme d'utiliser la fonction exec() pour appeler une application dans un terminal.
J'avais un peu de mal avec l'idée de mettre des morceaux de code dans un autre langage à l'intérieur de mon code, je trouvais ça moche comme façon de faire, et quand on voit tous les problèmes de sécurité que cela semble apporter, je me suis toujours demandé, mais pourquoi sql ?
J'avais entendu parler des bases de données nosql développées avant tout pour la gestion de très grandes bases distribuées, ce que n'est absolument pas mon application, mais j'ai tout de même profité de cette opportunité pour développer cette application en utilisant Mongodb.
La première chose qui était véritablement intéressante pour moi, c'était de pouvoir travailler naturellement et d'avoir une intégration complète de la base de données dans mon code en php. On stocke des tableaux, on récupère des objets qui se comportent comme des tableaux, tout est naturel, il n'y a pas de requêtes complexe à coder, tout fonctionne sous forme de tableau, et j'ai trouvé cette façon de faire très confortable.
Une chose m'a également aidé à développer mon application, le fait que les bases n'aient pas de taille prédéterminée et que les champs ne soient pas obligatoirement typés de façon prédéfinie permet de construire son application pas à pas, en ajoutant au fur et à mesure les différents champs dont on a besoin à l'intérieur de sa base, j'ai pu ainsi développer mon application progressivement et, je trouve, relativement rapidement, sachant que c'était la première fois que je développais ce type d'application et que je suis très loin d'avoir les compétences d'un ingénieur.
Et la dernière chose qui me plait énormément, il s'agit pour le coup de la sécurité de ce type de base. Il faudra juste faire attention à ce que l'utilisateur n'envoie pas un tableau dans une requête GET ou POST pour éviter toute injection ou détournement de requête. Encore une fois, cela facilite grandement la gestion de la sécurité de l'application, et pour le coup, cela permet très simplement bien des choses.
La seule chose que je n'ai pas testée étant les performances, l'application en question n'étant pas critique à ce niveau là.
Du coup, je me pose la question de l'intérêt de développer une application web en utilisant des bases sql. Bien évidemment je n'ai pas l'expérience de sql, et je sais que ce langage est extrêmement puissant, mais pour ma part, ayant développé mon application avec tellement d'aisance, je ne ressens pas le besoin de m'y mettre aujourd'hui, ni de faire l'effort d'apprendre ce langage.
Bon, je dis peut-être quelques bêtises, je reste à mon niveau, mais au final, je me pose la question de l'intérêt des bases sql aujourd'hui, au vu de la puissance des bases nosql comme Mongodb et du confort que cela apporte en terme de développement.
# Objet PHP === Document
Posté par wysman . Évalué à 4.
Je vais dans ton sens aussi,
- Le driver Mongo pour PHP est très bien fait et la conversion tableau/objet/document est très simple.
- Ce genre de BDD est pratique pour sa flexibilité lorsque le developpement de l'application commence tôt, et ou le contenu des documents va varier.
Personnellement, je m'en sert pour stocker des contextes de calcul dont je n'ai a priori aucune idée sur le contenu et la forme.
# Mélange de langage
Posté par barmic . Évalué à 10.
C'est marrant de la part d'un développeur web (ne le prend pas pour toi c'est vraiment très général) où pendant longtemps cela consistait à mélanger à minima HTMl et PHP (avant d'avoir des templates) ou HTML/JS. Au contraire SQL a une séparation relativement bonne puisque tu les mets dans des string.
Mais je tiens a apporter deux petites choses :
1 : C'est un point dont je peux difficilement parler je fais du sql depuis quelques années et ça ne me paraît pas bien compliqué.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mélange de langage
Posté par Moonz . Évalué à 4.
Dans le même genre, je recommande chaudement idiorm
[^] # Re: Mélange de langage
Posté par eMerzh (site web personnel) . Évalué à 3.
Dommage que idiorm n'est plus maintenu…
p-e certains fork vont reprendre le flambeau ? comme https://github.com/kevinsperrine/idiorm
[^] # Re: Mélange de langage
Posté par Kangs . Évalué à 2.
Il y a une bonne pratique qui consister à stocker tous les requêtes (non dynamiques) dans un fichier et de les appeler par un identifiant, ce qui permet dans certain SGBD/R d'ajouter des "hints" par exemple sans devoir toucher au code principal.
Une autre école consiste à n'utiliser que des procédures stockées (quand le SGBD/R le permet) ce qui fait qu'on manipule la base comme une sorte de bibliothèque.
Si tes requêtes utilisent des 'binds variables' tu minimises (fais disparaitre ?) les problèmes de sécurité liée à l'injection de code.
[^] # Re: Mélange de langage
Posté par claudex . Évalué à 3.
Le gros désavantage, c'est de perdre de l'indépendance par rapport au SGBDR et d'avoir de la logique applicative un peu partout.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Mélange de langage
Posté par windu.2b . Évalué à 6.
Tu perds en effet la possibilité d'utiliser des SGBDR ne gérant pas les procédures stockées…
Mais tu gardes une indépendance vis-à-vis de tous les autres SGBDR (ceux gérant les procédures stockées), et cela te permet même d'optimiser tes requêtes SQL, au sein de la ProcSto, du moment que les types des valeurs d'entrée et de sortie restent identiques.
Enfin, avantage indéniable de la ProcSto sur la requête dans le code : toute modification du schéma des bases lèvera immédiatement une alerte si une ProcSto est concernée et ne compile plus. Quand tu as une grosse application PHP avec des centaines de requêtes SQL dispersées dans le code, c'est pas évident de voir de suite les impacts sur le code. Et c'est donc souvent à l'exécution que tu t'en rends compte…
[^] # Re: Mélange de langage
Posté par claudex . Évalué à 3.
Et tu dois tout réécrire quand tu change. Ça revient à avoir autant d'importance que le langage dans lequel tu code.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Mélange de langage
Posté par Kangs . Évalué à 4.
Quand tu changes quoi ?
Les procédures stockées définissent une interface public, tu peux changer le code des procs de facon transparente.
On part du principe que :
- les procédures stockées gèrent la logique métier.
- le client dans un langage X gère l'affichage.
Tu peux changer de client facilement, passer d'un client lourd à un client léger sans perdre toutes les règles métier.
Tu évites de positionner des triggers à la con, parce qu'un insert est éparpillé dans 50 points du programme, …
Il est beaucoup plus simple d'écrire du code correcte avec des procédures stockées, par exemple lors de l'utilisation de bind variable.
Ensuite ca peut éviter d'avoir des développeurs qui n'ont pas la logique SQL mais uniquement itérative de faire des boucles à tout va pour manipuler des données, ce qui peut être très pénalisant en terme de performance.
Si tu dois changer de SGBD il me semble que la signature des procédures stockées et plus portable.
Par contre pour porter le code c'est un autre histoire, il existe des outils mais je ne sais pas ce qu'ils valent.
De plus changer de SGBD peut être très problématique :
- façon de gérer les transactions par défaut (DB2, Sysbase IQ ne font pas de "read committed" et ce n'est pas simple à mettre en oeuvre avec MS Sql Server).
- différence subtile dans la fonctionnement des contraintes uniques (différent entre Oracle et MS Sql Server par exemple. D'un point de vue de la norme ils ont tous les 2 raisons)
- Les bons usages liés à un SGBD particulier.
Les requêtes vraiment portables sont forcément simple tu dois te limiter à la norme minimum du sql et oublier par exemple les requêtes analytiques.
[^] # Re: Mélange de langage
Posté par claudex . Évalué à 5.
Quand tu change de bdd, les clients ont bien plus souvent des exigences de bdd que de langage
N'importe quelle développement bien fait permet ça.
Normalement, ça ne doit se trouver que dans les DAO.
Ceux qui n'ont pas la logique SQL n'écrivent pas les DAO et tout le monde s'en sort bien.
Si tes procédures sont un poil complexe, c'est aussi simple que de changer de langage.
Pas si on a bien écrit ses DAO.
Il est évident qu'il faut réécrire les requêtes mais il est plus simple de devoir uniquement réécrire les requêtes que de devoir réécrire les requêtes et la logique si on change de bdd.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Mélange de langage
Posté par Kangs . Évalué à 1.
Ah…, affirmer l'inverse serait tout aussi facile.
J'apprécie ton argumentation pertinent…
Et dans ton développement tu écris un bibliothèque que tu pourras liée à tes deux projets ?
Le DAO est un pattern, je ne vois pas trop de sens dans ta phrase.
Disons que tu ais une class qui implémente le pattern DAO, elle est écrite dans un langage X, tu crées un autre client dans un autre langage : tu ré-écris.
Sur les 10 dernières années beaucoup d'application on évoluer vers des clients léger qui utilisaient des technologies différentes de l'appli initiale.
Avec ta proposition on doit gérer deux lignes de code.
De plus dans ta class si tu as plusieurs requêtes à exécuter tu feras autant d'aller/retour vers la base, perte de scalabilité au minimum …
Merveilleux…
Les procédures stockées sont très similaires d'une base à l'autre et des outils de portages existent.
PostgreSQL permet, par exemple, de convertir du code Oracle en code PostgreSQL.
Porter du code écrit en Java vers un des langages du .net n'est pas trivial, par exemple.
Que fait tu de la logique des transactions, de la façon de gérer les contraintes différentes d'une base à l'autre.
Si tu changes de SGBDR tu auras aussi des problématiques avec les DDL, à moins que ta base soit simpliste.
Avec une petite base et un code simpliste tu peux utiliser le SGBD que tu veux et les langages qui te plaisent, se n'est pas un problème.
Tu vois une base de données juste un ensemble de requêtes sql ce qui te permet d'ignorer confortablement toutes les différences existantes et donc les grosses problématiques de migrations d'un SGBD à l'autre que se soit la partie SGBD/R ou le code lui même (gestion des transactions, comportement des contraintes, ordres SQL, ordres DDL, etc)
[^] # Re: Mélange de langage
Posté par claudex . Évalué à 2.
C'est mon expérience. Et quand je vois le nombre de projets libre qui prennent en charge plusieurs SGBDR je me dis que je ne dois pas être le seul.
Si tu sais mieux que moi ce qui se passe dans ma tête, on va en rester là.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Mélange de langage
Posté par Kangs . Évalué à 0.
Oui, dans ce cas tu utilises le minimum commun, cad du code simple etc
Je ne lisais pas dans esprit je constate par rapport à ce que tu me dis et effectivement vaut mieux en rester là.
[^] # Re: Mélange de langage
Posté par scand1sk (site web personnel) . Évalué à 4. Dernière modification le 22 octobre 2012 à 18:11.
Euh, là quand même, je ne sais pas où tu vas les chercher, tes développeurs. Toutes les formations en informatique traitent le langage SQL, et sinon, deux semaines de formation transforment un développeur inutile en développeur compétent. Enfin bon, si je devais engager un développeur pour bosser sur une appli BDD et qu'il me dit qu'il n'a aucune connaissance en SQL, je crois que j'en prendrais un autre…
[^] # Re: Mélange de langage
Posté par Kangs . Évalué à 1.
Je ne parle pas de niveau de formation ou compétence mais de facilité de codage et donc de maintenance etc.
Les procédures stockées simplifies des mécanismes dans l'écriture du code que des langages hôtes ne peuvent pas faire.
[^] # Re: Mélange de langage
Posté par Xavier Combelle (site web personnel) . Évalué à 1.
Mon dernier souvenir de procédure stockée était du PL/SQL sous oracle 8 si je me souviens bien et ce souvenir n'avait rien à voir avec de la facilité de codage
[^] # Re: Mélange de langage
Posté par barmic . Évalué à 3.
Tu n'a de toute manière pas de vraie indépendance du SGBD ne serais-ce que parce qu'il te faut un driver différent (les serveurs d'application résolvent en partie ce problème) ou que la gestion des dates diffère entre tel ou tel serveur. Ce qui permet de switcher plus facilement (et par configuration) c'est d'avoir un DAO (que l'on travail avec du relationnel ou non c'est à mon avis nécessaire).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mélange de langage
Posté par claudex . Évalué à 4.
Ce ne sont que des modification mineures dont tu parle (surtout si tu as utilisé un DAO) par rapport à devoir réécrire toute la logique qui sont dans tes procédures si tu veux une autre base de données.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Mélange de langage
Posté par barmic . Évalué à 2.
Pas mal de bibliothèques te permettent de « compiler » les requêtes (avec ou sans paramètre), ça te fait gagner de la performance et c'est sécurisé. C'est par exemple le cas de JDBC avec les PreparedStatement.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mélange de langage
Posté par Kangs . Évalué à 1.
Ça ne change rien à mon propos, le code tu dois le passer à ta class.
Que se soit ODBC ou JDBC les requêtes préparés existent depuis très longtemps, je serais surpris qu'une bibliothèque ne propose pas la possibilité de préparer une requête de nos jours.
# C'est vrais du coup, quel intérêt ?
Posté par reynum (site web personnel) . Évalué à 1.
Maintenant qu'on a mongoDB et plus généralement le système noSQL avec tous les avantages que cela apporte quel est l'intérêt/avenir des bases SQL ? Est ce qu'un utilisateur confirmé en SGDB pourrait m'éclairer sur ce point ?
Au passage
Avec le framework Django (python) tu ne fais aucune requette SQL ton modèle de donnée est géré automatiquement.
kentoc'h mervel eget bezan saotred
[^] # Re: C'est vrais du coup, quel intérêt ?
Posté par NeoX . Évalué à 2.
je ne suis pas forcement un expert dans le domaine, mais peut-on avoir une architecture éclatée (3tiers ?) avec du nosql.
Comprendre par là avoir un serveur qui stocke les données, lesquelles sont interrogées/modifiées par d'autres serveurs comme les serveurs frontaux web et API.
[^] # Re: C'est vrais du coup, quel intérêt ?
Posté par reynum (site web personnel) . Évalué à 3.
Je ne vois aucun rapport en un modèle de base de données et une architecture 3 tiers, dans cette architecture tu as :
- La couche présentation (GUI)
- La couche métier (Logiciels)
- La couche données (accès à la base de donnée)
Nulle part on voit que la BDD doit être SQL elle peut parfaitement être noSQL (ou un autre truc proprio) cela ne modifie en rien l'architecture.
kentoc'h mervel eget bezan saotred
[^] # Re: C'est vrais du coup, quel intérêt ?
Posté par NeoX . Évalué à 1.
ce que je voulais dire, c'est "le systeme nosql permet-il d'avoir des bases deportés sur des serveurs autres que ceux ou s'executent le code"
[^] # Re: C'est vrais du coup, quel intérêt ?
Posté par claudex . Évalué à 4.
Oui, plusieurs des systèmes existant utilise des sockets tcp pour communiquer avec la base (que ce soit en local ou à distance).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: C'est vrais du coup, quel intérêt ?
Posté par claudex . Évalué à 6.
Il me semble que les bdd nosql ne respectent pas forcément les contraintes ACID (ce n'est pas toujours nécessaire d'avoir une bdd qui le fait mais quand on en a besoin, c'est mieux que ce soit le cas). De plus, il me semble qu'avoir un schéma structuré permet d'avoir de meilleures performances (quand on ne peut pas tout mettre en RAM). Bref, ça dépend des cas.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: C'est vrais du coup, quel intérêt ?
Posté par Benbben . É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.
[^] # Re: C'est vrais du coup, quel intérêt ?
Posté par Spack . Évalué à 10.
Hum… Clavier espagnole ?
[^] # Re: C'est vrais du coup, quel intérêt ?
Posté par Gui13 (site web personnel) . Évalué à 5.
Je ne suis pas aveugle à ta propagande pour le libre!
Elle est à peine cachée dans une diatribe sur les livres, mais un coup d’œil avisé m'a alerté, coquin.
[^] # Re: C'est vrais du coup, quel intérêt ?
Posté par ckyl . Évalué à 10.
Je vais te donner le mot clé magique pour trouver les réponses à ce que tu cherches: newSQL.
En gros, historiquement on a des SGDB qui proposent une intégrité relationnel, sont ACID et offrent un support des transactions. Cela a plein de bonnes propriétés mais tu as d'un côté un problème d’impédance avec les langages objets (toujours la merde pour faire les bindings), et de l'autre ça devient souvent assez vite usine à gaz et surtout ça peut avoir du mal à scaler pour les besoins des grosses dotcom. Tu as des solutions maitres-esclaves, si tu as peu d'écritures. Et tu as des solutions reposant sur le sharding. Le problème c'est que tu arrives vite à perdre les propriétés ACID et/ou transaction en shardant, et tu vas très vite te retrouver à devoir gérer tout ça dans ton code métier (refaire tes jointures etc.).
De la est parti le noSQL qui regroupe vraiment beaucoup de choses n'ayant pas grand chose à voir ensemble si ne n'est que généralement tu perds le côté relationnel, l'ACID et les TX. C'est très cool pour certaines choses, ca répond au besoin de scalabilité pour certains mais tu te retrouves rapidement à devoir gérer plein de contraintes dans le code métier. Refaire des TX adhoc, gérer les jointures et pleins de trucs rigolos que les devs passent leur temps à foirer par ce que c'est compliqué.
Et maintenant on observe une vague de retour sur des bases qui scalent mais qui repassent sur le modèle SQL et proposent les TX ACID. Le constat est que pour un certain nombre de besoins filer une vue document, une table orientée ligne ce n'est pas suffisant et on passe son temps à tout refaire à la main. On case ça sous le nom newSQL et tu peux notamment lire le papier sur Google Spanner pour te faire une idée.
Après cette introduction grossière tu as tout les mots clés qu'il te faut pour trouver des articles beaucoup plus pertinents et intéressants sur le sujet. Encore une fois, il n'y a pas d'outil magique. Il faut bien comprendre ses besoins et sa partie métier pour choisir l'outil ou l'ensemble d'outils adaptés. Refaire du relationnel sur du noSQL est aussi merdique que l'inverse. Il faut pas non plus être prétentieux sur la scalabilité; il faut taper fort pour arriver aux limites et il vaut mieux partir sur des choses simples plutôt sur une pile hype "tout le monde utilise"; de toute façon tu auras du mal à prévoir ce qui sera limitant et faudra réécrire / ré-architecturer.
[^] # Re: C'est vrais du coup, quel intérêt ?
Posté par Toufou (site web personnel) . Évalué à 4.
Pour ma part je ne parlerais pas d'avantage mais de particularités : d'ailleurs il existe pas mal d'approches noSQL, chacune plus ou moins liées à une certaine problématique.
NoSQL n'est pas plus une réponse ultime à toutes les problématiques de gestion de données que SQL : ça dépend des cas. Les différentes approches NoSQL ne sont que des outils de plus dans la panoplie à ta disposition pour gérer ton problème.
A mes yeux l’intérêt principal d'une base relationnelle SQL c'est justement le SQL : normalisé, énormément supporté et vraiment très puissant.
Tu as l'air de raisonner uniquement sur l'aspect persistance des données, or stocker de la donnée sert aussi très souvent à exploiter celle ci de manière synthétique. J'ai quand même l'impression que ce n'est pas le fort de beaucoup d'approches NoSQL.
# Sécurité
Posté par Georges Dubus (site web personnel) . Évalué à 10.
Ça ne pose des problèmes de sécurité que si on se dit que ce serait une idée magnifique de construire ses requêtes par concaténation. Si on utilise la méthode recommandée par n'importe qui s'étant posé la question 5 minutes, on utilise des placeholders et on a aucune problème de sécurité.
Donc non, le nosql n'apporte aucune sécurité supplémentaire par rapport au sql. Et ne va surtout pas croire que le choix de ta base de donnée te protège contre les autres problèmes dé sécurité classiques dans les application web : xss, csrf, cookies pas sécures, etc (je ne sais pas dans quelle mesure php fournit des solutions à ces problèmes ).
[^] # Re: Sécurité
Posté par maboiteaspam . Évalué à 0.
nativement : aucune. D'où l'utilité du framework, pour ce qui concerne le cas php.
N’était ce pas moins cryptique de citer PDO ? Ou pensais tu as autre chose?
[^] # Re: Sécurité
Posté par Georges Dubus (site web personnel) . Évalué à 4.
Je ne pratique pas le php ; je connais les solutions génériques à ce genre de problèmes mais je ne connais pas les nom des outils pour faire ça en php. Mais oui, effectivement, PDO ressemble à ça.
# Jointures et bases complexes
Posté par scand1sk (site web personnel) . Évalué à 8. Dernière modification le 22 octobre 2012 à 11:00.
Le noSQL, c'est bien quand on a peu de très grandes tables. Dans la situation inverse (ce qui est souvent le cas dès qu'on fait de la gestion), on se retrouve très vite coincé par l'absence de jointures entre tables. On est alors obligé de dénormaliser les tables, c'est-à-dire rajouter des informations que l'on pourrait obtenir autrement, ce qui augmente la taille des tables, et donc l'espace mémoire/disque, inutilement. Sans parler des difficultés accrues à modifier les informations, modéliser des associations many-to-many ou non-binaires, etc.
C'est aussi se passer des nombreuses fonctionnalités de SQL difficiles à transposer avec juste des opérations fonctionnelles : requêtes imbriquées, triggers, contraintes, intégrité…
En ce qui concerne les calculs sur de grands volumes de données, je sais que le MapReduce est très puissant, mais je le trouve beaucoup moins intuitif qu'un GROUP BY en SQL.
En ce qui concerne les risques d'injection SQL, c'est surtout dû à une très mauvaise pratique de personnes n'ayant jamais été réellement formées au SQL, ou s'étant arrêté à la deuxième page du tuto du site du Zéro. Il y a des myriades d'outils (requêtes préparées, protection des chaines…) pour s'en prémunir, avec une règle simple : ne jamais passer directement une information issu du GET/POST/COOKIE… directement dans une requête SQL par concaténation.
# Base relationnelle
Posté par Flyinva . Évalué à 10.
Derrière le SQL, il y a surtout des bases de données relationnelles qui apportent des fonctionnalités intéressantes pour la cohérence des données.
Exemple : j'ai deux tables, une avec des voitures qui doivent forcément avoir un propriétaire et une avec des propriétaires. Si M Durand a la voiture n° YYY-666-UUU et que j'ai mis les bonnes contraintes, je ne peux pas supprimer M Durand tant qu'il y a une relation avec la voiture YYY-666-UUU dans la base. Dans le cas contraire, je me retrouverais avec une voiture sans propriétaire ce qui va à l'encontre de mon modèle de donnée.
On peut faire les contrôles nécessaires au niveau de code de l'application mais la base de données apporte un modèle dont le rôle est justement d'assurer la cohérence. Sans cela, un jour tu finis pas avoir plein de voiture sans propriétaire.
Quand on voit certaines applications qui se servent d'une base de données comme d'un fichier tableur avec des varchar(255) pour chaque champs, c'est sûr que SQL n'apporte pas grand chose mais il y a d'autres utilisations ;-). Les bases relationnelles et les base noSQL n'offrent pas les mêmes fonctionnalités et ne répondent pas aux mêmes besoins.
# en mode humour
Posté par fabien . Évalué à 8.
Je n'avais jusqu'à maintenant jamais eu le courage de m'attaquer à l'ordinateur et encore moins à linux.
J'avais entendu parler des bases de donnés nosql développé avant tout pour la gestion de très grandes bases distribués, ce que n'est absolument pas mon application.
J'ai trouvé un vtech, resistant (c'est important la securité, on evite toute injection de petit pot purée carote, c'est ce qui me plait énormément) avec une intégration complète des applications avec les 4 boutons fluo.
La seule chose que je n'ai pas testé étant de faire quelques chose avec…
Bon, je dis peut-être quelques bêtises, je reste à mon niveau, mais au final, je me pose la question de l'intérêt de l'utilisation d'un ordinateur aujourd'hui, au vu de la puissance des jouet vtech.
…
Bref,
tout ca pour dire, que de toute evidence tu n'a pas la moindre notio nde ce que peut être une base de données, plutot que de faire un post technique (certains l'ont dejà fait) je voulais te montrer que quand on ne connais rien a un sujet, on est capable d'ecrire plein de connerie…
nosql et Mongodb on un marché, les sgbdr un autre.
http://fr.wikipedia.org/wiki/SGBDR#Fonctionnalit.C3.A9s
[^] # Re: en mode humour
Posté par Anonyme . Évalué à 5.
C'est très amusant comme démonstration… Effectivement, je n'y connais rien en base de donnée, et je l'ai en plus écrit au début de mon billet.
L'idée de mon billet était avant tout de donner le point de vu de l'accessibilité aux base de données d'un point de vu purement profane, et là je me sens particulièrement insulté par ce que tu as écrit.
Ça m'apprendra à la ramener.
[^] # Re: en mode humour
Posté par scand1sk (site web personnel) . Évalué à 7.
Le « point de vue purement profane » est biaisé. J'ai déjà vu des sites Web codés par des gens qui n'y connaissent visiblement rien en SQL (même pas une jointure !) Ben en utilisant 2-3 fonctionnalités du SQL, on pourrait diviser la taille de leur code par 3, et la maintenabilité d'autant plus. Le truc, c'est qu'ils n'en avaient même pas l'idée… Un peu comme si on laissait les employés Ikea monter tous les meubles d'exposition avec juste la clé Allen fournie avec chaque meuble. Ils peuvent y arriver, mais ils gagneraient des heures à utiliser une visseuse électrique.
[^] # Re: en mode humour
Posté par Thomas Douillard . Évalué à 5.
Personne n'a dit que le profane allait faire une application parfaite du premier coup, l'intérêt de son témoignage c'est justement de voir comment il a abordé la chose en amateur assumé.
[^] # Re: en mode humour
Posté par fabien . Évalué à 3.
désolé, c'était pas pour t'insulter.
Mais c'est marrant cette manie defois, il y a des gens qui ne connaissent rien, mais qui ne sont pas les derniers pour l'ouvrir et ballancer des "et pourquoi c'est pas comme ca", "ouais, c'est nul, gan gna gna..", bref.
Et c'est valable dans plein de domaine je te rassure…
Ok, j'ai bien compris que ton objet n'était pas de dénigrer le sql, mais de partager ta bonne surprise concernant la prise en main de nosql.
C'etait dans le "mode humour", et c'est pas moins percutant que l'explication plus techniques des mes predecesseurs.
# un parking
Posté par steph1978 . Évalué à -2.
Dans un parking, est ce qu'il est préférable de ranger les voitures:
1/ une par place, les places étant numérotées
2/ en morceaux, les portes dans un boxes, les moteurs dans un autre, etc. De tout séparer quand on rentre et de tout reconstruire quand on sort.
Vous aurez reconnu le modèle relationnel en 2 et le NoSQL en 1.
Dans 99% des usages, le modèle 1 est préférable. Mais pour quelques usages, le modèle 2 est préférable.
Donc le relationnel, c'est bien quand on en a besoin. Mais cela ne devrait pas être le modèle par défaut, n'en déplaise à Oracle (et certains architectes SI).
[^] # Re: un parking
Posté par ckyl . Évalué à 5.
Ton commentaire était bien jusqu'au dogmatique "99% des usages". Dommage, de tomber dans ce travers.
[^] # Re: un parking
Posté par steph1978 . Évalué à 0.
C'était pour contrebalancer le dogme inverse.
Mais n'ayant pas d'indicateur réel, je te l'accorde, j'aurai du me passer d'utiliser un chiffre.
[^] # Re: un parking
Posté par ckyl . Évalué à 4.
Voilà. Si quelqu'un te dit qu'une vis sert à tout, tu ne lui répond pas qu'il à tord par ce qu'en fait c'est le clou qui sert à tout. Mais tu lui expliques les propriétés de chaque, leurs différences d'usage et tu lui dis même qu'il existe des boulons.
Au passage pour ta remarque sur Oracle, on notera que "l'ancêtre du noSQL" qu'est BerkeleyDB appartient maintenant à Oracle (si si toi aussi tu te souviens avoir utilisé le module Perl DBM). Comme quoi ;)
[^] # Re: un parking
Posté par steph1978 . Évalué à -1. Dernière modification le 22 octobre 2012 à 15:43.
Bon exemple aussi.
Mais de mon expérience, le relationnel est sur utilisé. Un peu comme si on tapait sur des vis pour les utiliser comme des clous; en oubliant de les tailler en pointe par dessus le marché.
Vrai ! Mais là c'est toi qui frôle le sophisme ;)
Oracle fait son blé avec Oracle DB qui est purement relationnel.
Berkley DB est un très bon produit mais qui n'est pas beaucoup promu par Oracle.
[^] # Re: un parking
Posté par ckyl . Évalué à 3.
C'était juste pour l'anecdote marrante ;)
[^] # Re: un parking
Posté par scand1sk (site web personnel) . Évalué à 3.
L'exemple est foireux : ici, on parle d'information, pas de matériel. On peut la déconstruire, la fusionner, et la reconstruire bien plus efficacement qu'avec du matériel. C'est le même débat qu'avec vol vs contrefaçon…
Ici, dès qu'on doit modifier ou rechercher une donnée, on gagne en efficacité avec une base normalisée. J'ai du mal à croire sur parole un gus qui prétend que dans 99% des cas, on ne veut pas modifier ou rechercher des informations dans une BDD…
[^] # Re: un parking
Posté par steph1978 . Évalué à -1. Dernière modification le 22 octobre 2012 à 19:16.
Si tu en es là, je te suggère de chercher un peu d'information sur tout ce qui est indexation.
Et, mais c'est l'étape suivante, regarde qui utilise des modèles relationnels et qui utilise autre chose.
Bien cordialement,
Gus
[^] # Re: un parking
Posté par lendemain . Évalué à 1.
Par "indexation" tu veux dire "moteur de recherche" ou index de base de donné?
[^] # Re: un parking
Posté par steph1978 . Évalué à 2.
index de base de données.
[^] # Re: un parking
Posté par lendemain . Évalué à 2.
Je comprend pas, avec les index de base de donnée on peut pas vraiment faire mieux en terme de vitesse d'accès.
[^] # Re: un parking
Posté par steph1978 . Évalué à 1.
Tout à fait.
Mais ce n'est pas propre à une base de donnée relationnelle.
En fait je répondais au commentaire tout à fait sympathique de scand1sk qui semblait dire que seul un modèle relationnel permettait automagiquement de "modifier ou rechercher des informations dans une BDD" et qu'il fallait être un imbécile pour penser le contraire.
[^] # Re: un parking
Posté par scand1sk (site web personnel) . Évalué à 0.
Disons que dans l'exemple du parking, si tu fais une recherche sur les voitures équipées d'un moteur V6, ça risque d'être plus efficace de faire d'abord une recherche dans les moteurs, puis une fois le moteur identifié, de faire la recherche sur les voitures.
Je t'accorde qu'en terme de complexité, ça ne change pas grand chose (ça peut même être pire s'il y a plus de moteurs que de voitures, ce qui reste peu envisageable).
Par contre, en termes de modification, le problème existe vraiment : mettre à jour toutes les voitures équipées d'un moteur V6, ou seulement le moteur…
Il me semble que Twitter est le principal utilisateur de bases noSQL, et justement il n'est pas possible de modifier les messages…
# Pléonasme
Posté par Nicolas Blanco (site web personnel) . Évalué à 0.
développement web
amateuren phpSuivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.