Journal Microsoft va porter SQL Server sur Linux

Posté par . Licence CC by-sa
22
7
mar.
2016

Non on n'est pas Vendredi, et on n'est pas le 1er avril non plus…

https://blogs.microsoft.com/blog/2016/03/07/announcing-sql-server-on-linux/

Today I’m excited to announce our plans to bring SQL Server to Linux as well. This will enable SQL Server to deliver a consistent data platform across Windows Server and Linux, as well as on-premises and cloud. We are bringing the core relational database capabilities to preview today, and are targeting availability in mid-2017.

Maintenant il ne reste plus qu'à attendre quelles critiques certains vont encore réussir à trouver pour se plaindre de MS, il va falloir être de plus en plus imaginatif les gars.

  • # L'OS n'est pas le problème

    Posté par . Évalué à 2.

    Si déjà ils arrivaient à faire un SGBD qui n'a pas besoin de 4Go de ram pour faire tourner une base vide, ça serait bien.

    • [^] # Re: L'OS n'est pas le problème

      Posté par . Évalué à -2.

      Tes connaissances de DBA sont bien évidentes. SQL Server prends autant de mémoire que tu lui laisses, pour une raison simple: il cache au maximum les résultats des requêtes. Pour info, Gartner positionne SQL Server dans le carré des leaders, au dessus de Oracle.

      • [^] # Re: L'OS n'est pas le problème

        Posté par (page perso) . Évalué à 9.

        "MS SQL au dessus de Oracle" -> sources ???

        (bonne blague ceci dit…)

        • [^] # Re: L'OS n'est pas le problème

          Posté par . Évalué à 10.

          Après il s'agit de Gartner, je suis pas certain d'avoir un jour était intéressé par leurs avis (quelque soit le domaine).

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: L'OS n'est pas le problème

            Posté par . Évalué à 2.

            Et c'est surtout qu'il n'y pas les outils statistiques fournis. Donc quelque soit l'orientation voulue/souhaitée donnée aux analyses de résultats de l'étude, ce qui peut se faire en interprétant normalement, il y a un défaut de transparence.

            Et plutôt que de se battre sur des pouillèmes je préfèrerai avoir une étude de cas avec des données d'aujourd'hui. Pas du .txt à mettre en base avec 3 méta données qui se battent en duel, merci.

        • [^] # Re: L'OS n'est pas le problème

          Posté par (page perso) . Évalué à 8. Dernière modification le 08/03/16 à 10:05.

          voir ici : http://www.gartner.com/doc/reprints?id=1-2PO8Z2O&ct=151013&st=sb

          Si tu regardes le quadrant, tu vois que Microsoft est tout en haut à droite : c'est la solution qui domine toutes les autres au sens de Pareto.

          Je ne me prononce pas sur la qualité de l'analyse, mais c'est qui est dit est factuellement vrai : d'après Gartner, SQL Server est au-dessus d'Oracle.

          • [^] # Re: L'OS n'est pas le problème

            Posté par . Évalué à 2.

            Comme toujours, il suffit de regarder qui a financé l'étude. Mais noter comme avant-gardiste une base SQL, c'est rigolo.

            SQL server est quand même un jouet coincé entre MySQL/mariaDB d'un coté, puis Oracle/MongoDb/Cassandra/redis de l'autre.

            "La première sécurité est la liberté"

            • [^] # Re: L'OS n'est pas le problème

              Posté par . Évalué à 10.

              SQL server est quand même un jouet coincé entre MySQL/mariaDB d'un coté, puis Oracle/MongoDb/Cassandra/redis de l'autre.

              MongoDb ? Franchement, ce truc est encore plus bricolé que MySQL - et Redis comme base de données générique ? Vraiment ?

              Restons sérieux trente secondes.

              • [^] # Re: L'OS n'est pas le problème

                Posté par . Évalué à 2.

                C'est pourtant des databases du top 5 les plus utilisés (pour tout usage, pas forcément "générique") MongoDb est devant cassandra par exemple.

                "La première sécurité est la liberté"

                • [^] # Re: L'OS n'est pas le problème

                  Posté par . Évalué à 3.

                  C'est pourtant des databases du top 5 les plus utilisés (pour tout usage, pas forcément "générique") MongoDb est devant cassandra par exemple.

                  Ben comme MySQL en son temps. Mais quand on voit les solutions NoSQL disponibles, y compris en libre - on ne peut définitivement pas classer MongoDB dans la catégorie "Outil sérieux et professionnel".

                  • [^] # Re: L'OS n'est pas le problème

                    Posté par (page perso) . Évalué à 2.

                    Je suit de loin riak qui a l'air très bien.

                    • [^] # Re: L'OS n'est pas le problème

                      Posté par . Évalué à 3.

                      Je suit de loin riak qui a l'air très bien.

                      Très très bien pour le suivi haute resistance, scale moins bien que OpenTSDB sur les logs ceci dit. Par contre les insertions simultanées ou en conflit sont assez pénibles à gérer.

                      Après dans la catégorie "qu'est qu'il fout là celui-là ?" je recommande vivement PostgreSQL avec le cstore_fdw de citus. Moins puissant en insertion, par contre en WORM il dépote grave. Le truc est d'utiliser row_to_json pour faire des requètes sur des tables hétérogènes - et hop on a une vraie base yeSQL qui peut fonctionner comme une base noSQL si on insiste un peu.

            • [^] # Re: L'OS n'est pas le problème

              Posté par . Évalué à 8.

              SQL server est quand même un jouet

              Microsoft disait ça de Linux avant, c'est drôle de voir d'anciennes vannes ressurgir. Ce que tu appelles jouet, je l'appelle le meilleur SGBDR du moment. Les dba PostGReSQL vont me dire que SQL Server n'est pas libre, je leur dirais que ça ne rentre pas en ligne de compte pour savoir qui est le meilleur. Les dba Oracle vont me dire que c'est moins puissant que leur usines à gaz, je répondrai que la profession de dba oracle est en train de mourrir au profit de dba tout court.

              coincé entre MySQL/mariaDB d'un coté, puis Oracle/MongoDb/Cassandra/redis de l'autre.

              Oulah… Je pense que SQL Server taquine Oracle depuis quelques années maintenant et qu'avec une pente d'apprentissage bien plus faible ça va continuer. Ça ne veut pas dire qu'on ne peut pas faire de traitements complexes.

          • [^] # Re: L'OS n'est pas le problème

            Posté par . Évalué à 2.

            Je sais pas comment ils expliquent de ne pas avoir évaluer ElasticSearch (ou alors je suis bigleux ?).

            Par contre, ils indiquent les qualités et défauts qu'ils voient. C'est original. C'est des critères de décideur pressé pas de technicien (c'est un point de vu différent pas pire pas mieux).

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

            • [^] # Re: L'OS n'est pas le problème

              Posté par (page perso) . Évalué à 10.

              Je sais pas comment ils expliquent de ne pas avoir évaluer ElasticSearch (ou alors je suis bigleux ?).

              Je leur reproche surtout de ne pas avoir évalué PostgreSQL, qui joue plus dans la même catégorie (en mieux), alors qu'ils le citent plus bas avec ce proposent certains acteurs.

              • [^] # Re: L'OS n'est pas le problème

                Posté par . Évalué à 5.

                PostgreSQL semble avoir été pris en considération via EntrepriseDB … mais leur analyse reste celle du décideur pressé comme dit plus haut.

        • [^] # Re: L'OS n'est pas le problème

          Posté par . Évalué à 2.

          en nombre d'instances, je ne serais pas étonné que mssql soit devant oracle.

          En revanche, si on regarde les tailles moyennes des bases ou encore leur criticité, Oracle est très certainement devant.

          Faut arrêter de chercher des poux à $krosoft gratuitement et puis il faut aussi sortir de sa caverne pour voir ce qu'il se passe en entreprise

      • [^] # Re: L'OS n'est pas le problème

        Posté par . Évalué à 5.

        Je me suis abstenu de noter son commentaire, car je n'arrive pas à savoir si c'est une blague suite à "Maintenant il ne reste plus qu'à attendre quelles critiques certains vont encore réussir à trouver pour se plaindre de MS, il va falloir être de plus en plus imaginatif les gars.", ou juste une méconnaissance des usages en DBA.

        On pourrait comparer ca vaguement au cache fichier sous linux, sauf que ça ne marche pas pareil et l'OS ne peut pas vraiment réclamer la RAM s'il vient à en manquer (enfin pas à ma connaissance), ce qui fait que ça en fait une cible de choix pour le oom_killer :)

        Il ne faut pas décorner les boeufs avant d'avoir semé le vent

    • [^] # Re: L'OS n'est pas le problème

      Posté par . Évalué à 8.

      C'est précisément ce que fait cassandra. Par défaut son xms et son xmx sont à 4Gio à fin de ne pas perdre de temps avec la gestion de la mémoire et parce que pour limiter les accès disque il a un tas d'index et de cache en mémoire.

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: L'OS n'est pas le problème

        Posté par . Évalué à 3. Dernière modification le 09/03/16 à 04:22.

        La jvm gere toujours la memoire, c'est juste que sur une appli dont le profile d'execution est (on l'espere) bien connu a l'avance, et qui tourne (on l'espere) sur un machine/vm dediee, ca sert pas a grand chose d'aggrandir/diminuer la heap. T'as besoin de x go, ils vont toujours etre utilises, tu met xms == xmx, ca t'eviteras que la jvm te joue des tours derriere ton dos.
        C'est assez standard comme pratique quand le profil d'execution est connu (je fais la meme chose sur mes webapps)

        Linuxfr, le portail francais du logiciel libre et du neo nazisme.

  • # Facile!

    Posté par . Évalué à 10.

    Maintenant il ne reste plus qu'à attendre quelles critiques certains vont encore réussir à trouver pour se plaindre de MS, il va falloir être de plus en plus imaginatif les gars.

    SQL Server ça pue, c'est pas libre!

    Ça, c'est fait!
    ------> [ ]

    • [^] # Re: Facile!

      Posté par . Évalué à 10.

      Bin oui, quel intérêt d'utiliser SQL Server sinon le plaisir d'utiliser un SGBD non libre ? Quels sont ses avantages ?
      Vraie question, je suis d'un niveau zéro+ en SGBD.

      Autre chose : quel est l'intérêt de passer sous Linux pour ceux qui utilisent déjà une solution Windows/SQLServeur ? (bon, là j'ai une vague idée…)

      • [^] # Re: Facile!

        Posté par . Évalué à 4.

        En effet, sérieusement, le problème qui reste, c’est la licence (et le tarif). Pour ceux qui ont une base de code serveur en .NET qui compile avec la partie déjà libérée, il est bien possible que la seule raison de rester sous Windows Server soit SQL Server. Maintenant, ils vont pouvoir envisager de quitter cette plaie qu’est Windows Server (quelle galère à administrer, et quels tarifs !) et passer sous Linux. Évidemment ce n’est pas aussi simple que ça, il y a encore plein de composants manquants. Mais ça va clairement ramener du monde du côté MS, ou en garder, et quand ce monde-là aura besoin de services complémentaires, il verra bien vite à quel point c’est plus simple, quand on a commencé avec MS, si on utilise Azure. Enlever des restrictions sur les produits pour vendre plus de services : c’est clairement leur direction actuelle, et à mon avis ils ont raison.

      • [^] # Re: Facile!

        Posté par (page perso) . Évalué à 10.

        Quels sont les avantages de SQL Server par rapport à un autre SGBD ? Je ne les connais pas tous, donc je vais juste en prendre quelques uns :)

        • l'intégration de .Net comme langage support pour le développement de fonction/procédure stockée utilisateur ;
        • les outils de gestion (Sql Server Studio est plutôt bien foutu) ;
        • les services de reporting, de business intelligence, etc… qui gravitent autour ;
        • la pérénité des dumps et la compatibilité descendante (aucun soucis pour charger un dump de SQL Server 2005 sur un SQL Server 2012). Faite la même chose avec un postgresql par exemple… pas sur que cela se fasse sans heurt (avant qu'on me dise que je raconte des cracks : malheureusement testé et approuvé :'( )

        Après, niveau intérêt, le premier que je vois c'est la "conteneurisation" (docker and co.). Ensuite, ça évite d'avoir à payer une licence Windows juste pour SQL Server et ainsi d'homogénéiser le parc et de pouvoir faire un full linux :)

        • [^] # Re: Facile!

          Posté par . Évalué à -8.

          l'intégration de .Net comme langage support pour le développement de fonction/procédure stockée utilisateur ;

          Quelque soit le SGBDR, le mec qui me dit qu'il faut faire de la procédure stockée, mérite d'être pendu haut et court.

          Sinon oui SQL Server est pas mal à ce qu'il paraît. Par exemple, il a un bon support de la norme (ah ! ah !) SQL.

          la pérénité des dumps et la compatibilité descendante (aucun soucis pour charger un dump de SQL Server 2005 sur un SQL Server 2012). Faite la même chose avec un postgresql par exemple… pas sur que cela se fasse sans heurt (avant qu'on me dise que je raconte des cracks : malheureusement testé et approuvé :'( )

          Les ETL ne permettent pas ce genre de choses (prendre en entrée une sauvegarde) ?

          Après, niveau intérêt, le premier que je vois c'est la "conteneurisation" (docker and co.).

          Windows pourra bientôt tourner dans Docker (oui ça surprend toujours la première fois).

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: Facile!

            Posté par (page perso) . Évalué à 10.

            Quelque soit le SGBDR, le mec qui me dit qu'il faut faire de la procédure stockée, mérite d'être pendu haut et court.

            Vient me pendre alors xD

            Plus sérieusement, à te lire, on a l'impression que la procédure stockée, c'est le mal. Que tu ne les utilises pas et/ou que tu ne l'aimes pas, c'est ton choix. Dire que c'est de la merde, désolé, je ne peux pas ne pas réagir.

            Les ETL ne permettent pas ce genre de choses (prendre en entrée une sauvegarde) ?

            Ouch. Il y a certainement des ETL qui le permette si. Mais si tu as un dump d'une BD, tu aimerais pouvoir la restaurer uniquement avec le dump, sans avoir à sortir l'artillerie lourde qu'est un ETL ! En plus de la phase d'apprentissage dudit ETL. Pour le coup, là c'est moi qui ait envie de te pendre (utiliser un ETL pour restaurer une BD !). Un ETL, c'est pour de l'agrégation et de la transformation. Un bazooka ça peut tuer une mouche, mais personne ne s'en sert pour ça.

            • [^] # Re: Facile!

              Posté par . Évalué à 5.

              Plus sérieusement, à te lire, on a l'impression que la procédure stockée, c'est le mal. Que tu ne les utilises pas et/ou que tu ne l'aimes pas, c'est ton choix. Dire que c'est de la merde, désolé, je ne peux pas ne pas réagir.

              L'impossibilité de maintenir ce genre de code, le fait de séparer ta logique dans des endroits aussi divers que variés,… J'ai vu trop de projets se mordre les doigts, les mains, les poignets,… après quelques années d'utilisation de ce genre de choses. Cerise sur le gâteau, c'est hyper intrusif dans ton design ! Retirer ce genre de chose est une galère sans nom.

              Une base de données c'est un modèle de données et un système de requête cohérent avec un certain nombre de garantie. Déplacer un bout de ta logique dans ta base de données, c'est foncé droit dans un mur.

              Alors oui, tu peut avoir de bonne raison (souvent c'est la perf) pour faire des petits traitements coté db, mais je préfère faire le chien de garde pour éviter au maximum de le faire et si c'est fait réduire au maximum la logique que tu y met.

              En fait je suis un peu méchant, avec couchdb ça peut avoir du sens parce que selon ce que tu fait tu peut tout mettre dans couch (tu as un reverse proxy http pour le statique et il redirige toutes les requêtes WS vers couchdb). Mais c'est vraiment un cas particulier.

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

              • [^] # Re: Facile!

                Posté par (page perso) . Évalué à 10. Dernière modification le 08/03/16 à 11:37.

                L'impossibilité de maintenir ce genre de code, le fait de séparer ta logique dans des endroits aussi divers que variés,… J'ai vu trop de projets se mordre les doigts, les mains, les poignets,… après quelques années d'utilisation de ce genre de choses. Cerise sur le gâteau, c'est hyper intrusif dans ton design ! Retirer ce genre de chose est une galère sans nom.

                Ce que tu décris là ressemble beaucoup plus à un problème d'organisation qu'autre chose. J'en ai vu des choses aussi, mais généralement dans l'autre sens : la bd n'était qu'un "centre de stockage". Va maintenir cela. N'importe quelle modification implique une mise à jour complète de l'application. Comprendre la base de données passe par une lecture du code de la couche métier. Ouch !

                Depuis que j'utilise des procédures stockées (quelles soient native ou pas d'ailleurs), j'ai largement gagné en maintenance :
                - je peux mettre à jour le schéma de ma BD sans impacter ma couche métier ;
                - ma couche métier gagne en lisibilité, dans la mesure où les opérations les plus complexes sont réalisées en BD ;
                - les opérations complexes en BD utilisent moins de ligne de code que leur équivalent dans ma couche métier. Je gagne encore en maintenabilité. Sans compter les gains de performance.
                - la BD se suffit a elle-même pour sa compréhension. Pas besoin d'aller lire le code de la couche métier. On gagne encore en maintenabilité.

                Une base de données c'est un modèle de données et un système de requête cohérent avec un certain nombre de garantie. Déplacer un bout de ta logique dans ta base de données, c'est foncé droit dans un mur.

                Ce qui est foncer droit dans le mur, ce n'est pas de déplacer la logique dans la base de données. C'est d'éparpiller ta logique : qu'elle se retrouve à la fois dans ton application, ta couche métier et ta BD. De mon côté, pour faire simple, j'ai le principe suivant :
                - ma BD est garante de la cohérence de mes données. Si une opération complexe peut remettre en cause la cohérence de mes données, elle sera présente dans ma BD et non dans ma couche métier. Ma BD définie ainsi des opérations atomiques ;
                - ma couche métier est une interface d'accès à mes données, en offrant des services de haut niveau. Un bogue dans ma couche métier ne remet pas en cause la cohérence de mes données. Et ça, c'est super important !

                On oublie souvent qu'aujourd'hui, plus qu'une application, ce qui est important, ce sont les données. Une application, cela se développe, cela se créer. Les données, il faut du temps pour les récolter… Alors quand il faut les réparer… (si cette opération est possible, ce qui n'est pas toujours le cas).

                Alors oui, tu peut avoir de bonne raison (souvent c'est la perf) pour faire des petits traitements coté db, mais je préfère faire le chien de garde pour éviter au maximum de le faire et si c'est fait réduire au maximum la logique que tu y met.

                J'ai presque envie de dire que c'est la pire des raisons. Recherche la perf via ce genre de chose n'est, en général, pas la bonne méthode. Si problème de performance il y a, dans 95% des cas, c'est un problème de conception (modèle de données non adapté, algorithme non optimisé) et non un problème de langage.

                En fait je suis un peu méchant, avec couchdb ça peut avoir du sens parce que selon ce que tu fait tu peut tout mettre dans couch (tu as un reverse proxy http pour le statique et il redirige toutes les requêtes WS vers couchdb). Mais c'est vraiment un cas particulier.

                La tu passes sur un cas en particulier. La discussion était jusqu'à présent sur les SGBD en général ;)

                • [^] # Re: Facile!

                  Posté par (page perso) . Évalué à 3.

                  Une précision : je ne dis pas que ma méthode est la meilleure. Je la présente uniquement pour montrer qu'on peut gagner en maintenabilité, contrairement à ce que tu affirmes.

                • [^] # Re: Facile!

                  Posté par . Évalué à 1.

                  • je peux mettre à jour le schéma de ma BD sans impacter ma couche métier ;

                  Ce qui n'a pas de sens. Enfin… Pas dans le sens que tu l'indique. Soit changer ton modèle a des implications métier (ça arrive forcément), soit ça impact uniquement ta couche persistance (quand tu travail en couche).

                  • ma couche métier gagne en lisibilité, dans la mesure où les opérations les plus complexes sont réalisées en BD ;

                  Je ne vois pas comment tu peux avoir une opération complexe qui ne fais pas partie de ta logique métier… Tu peux parler d'un code purement technique qui serait de la tambouille de données, par exemple faire une projection ou des statistiques sur tes données, mais ça je ne le ferrais jamais dans une procédure stockée. Le faire dans un code à toi, ça permet de le distribuer, de le lancer en mode batch, de l'envoyer dans un job hadoop/spark/storm,… Mais aussi de le tester avec tes outils de tests unitaires classiques.

                  • les opérations complexes en BD utilisent moins de ligne de code que leur équivalent dans ma couche métier. Je gagne encore en maintenabilité. Sans compter les gains de performance.

                  AMHA garder le même langage que sur le reste de l'application, ainsi que le même protocole de test est bien plus efficace pour maintenir ce code.

                  • la BD se suffit a elle-même pour sa compréhension. Pas besoin d'aller lire le code de la couche métier. On gagne encore en maintenabilité.

                  C'est là que je vois que j'ai beaucoup évolué ces dernières années (pas forcément en bien). J'étais aussi de ton avis avant. Aujourd'hui, je ne vois pas l'intérêt d'avoir une « base de données qui se suffit à elle-même ». Ta base de données est faites pour soutenir une application et pas pour la beauté du geste.

                  • ma BD est garante de la cohérence de mes données. Si une opération complexe peut remettre en cause la cohérence de mes données, elle sera présente dans ma BD et non dans ma couche métier. Ma BD définie ainsi des opérations atomiques ;

                  Euh… tu as tes contraintes d'intégrité pour ça et si ça ne suffit vraiment pas tu as des triggers qui peuvent faire le boulot. Je suis pas grand fan, mais si vraiment tu veux de la cohérence forte c'est une possibilité (en se limitant à coder des invariants).

                  • ma couche métier est une interface d'accès à mes données, en offrant des services de haut niveau. Un bogue dans ma couche métier ne remet pas en cause la cohérence de mes données. Et ça, c'est super important !

                  Et il est impossible d'avoir de bug dans une procédure stockée ? :)

                  On oublie souvent qu'aujourd'hui, plus qu'une application, ce qui est important, ce sont les données. Une application, cela se développe, cela se créer. Les données, il faut du temps pour les récolter… Alors quand il faut les réparer… (si cette opération est possible, ce qui n'est pas toujours le cas).

                  Si j'en suis vraiment là, je préfère partir sur de l'event sourcing. Mes données sont immutables. Je reçois les données, je les stocke et ensuite je vois comment les organiser pour les rendre utilisable (sans toucher le premier stockage des données). C'est résilient (je peux reconstruire mes projections à tout moment), ça évolue très facilement et c'est facilement distribuable.

                  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                  • [^] # Re: Facile!

                    Posté par . Évalué à 10.

                    Je ne vois pas comment tu peux avoir une opération complexe qui ne fais pas partie de ta logique métier…

                    Supposons que tu es une très grosse base, ou pleins de bases, qui contiennent pleins d'éléments différents en fonction des ventes, de la techniques, des investisseurs, des fournisseurs, des clients etc.

                    Supposons maintenant que quelqu'un veuille faire du reporting avec des données consolidées, parfois par année ou par mois ou encore par produit pour chaque sous ensemble des données précités.

                    Genre un top ten des clients les plus rentables pour le mois de mars 2015, ou une liste des taux d'incidents par produit en fonction du fournisseur.

                    Tu as le choix entre trois solutions :
                    - Choix 1) un super cube OLAP, mais ça ne marche que si les types de données demandés par la direction ne changent pas trop - sinon il faut refaire tous les rapports le jour ou on décide qu'il faut ajouter le respect ou non de ISO-TrucBidule sur tous les déploiements.

                    • Choix 2) 8000+ vues, une pour chaque découpe. C'est la teuf à la maintenance aussi.

                    • Choix 3) Des jeux de procédures stockées et de fonctions (et autres, en postgresql le DO INSTEAD est surpuissant si bien utilisé) qui vont être utilisés comme des vues par le client de reporting - mais qui centralisent le code en un point et simplifient grandement la maintenance.

                    Par exemple une fonction getStatsBy(< col >) qui fournira toutes les infos consolidées possibles et imaginables avec consolidation sur la colonne spécifiée.

                    Clairement les procédures stockées ne doivent jamais contenir de logique métier, mais elles peuvent être extrêmement pratiques même sans ça.

                    • [^] # Re: Facile!

                      Posté par . Évalué à 1.

                      Le cas d'usage que tu décris c'est de la logique métier pour preuve tu explique que c'est des choses demandé par la direction. Un code pas métier c'est un code qui ne touche pas au besoin fonctionnel de l'application (performance, robustesse, etc).

                      Il y a d'autres choix que les 3 que tu donne. Par exemple tu peux gérer ça via des batch ou monter une architecture lambda si tu a besoin de temps réelle et tu as tout un tas d'organisation possibles qui vont plus ou moins impacter ton design en fonction des besoins que tu as.

                      Choix 3) Des jeux de procédures stockées et de fonctions (et autres, en postgresql le DO INSTEAD est surpuissant si bien utilisé) qui vont être utilisés comme des vues par le client de reporting - mais qui centralisent le code en un point et simplifient grandement la maintenance.

                      J'aurais vraiment peur de cette solution. Comment ça se comporte avec un million de ligne ? 100 millions ? Si ta base est en cluster (est-ce distribué ? Est-ce que tu perçois clairement ce qui va entraîner une réduction de tes données ? Quelle est la granularité de lock que tu met sur tes données) ? Faire des traitement de plusieurs secondes sur une base (qui doit déjà prendre la charge de la production) ça me semble pas être une excellente idée.

                      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                      • [^] # Re: Facile!

                        Posté par . Évalué à 6.

                        Le cas d'usage que tu décris c'est de la logique métier pour preuve tu explique que c'est des choses demandé par la direction

                        GNI ? L'exemple que je donne c'est la réponse à un besoin exprimé par la direction au niveau base de données. La base de données elle même a probablement été créé pour répondre à un besoin exprimé par la direction (ou autre). Ça revient à dire que toute base de données qui sert à quelque chose au niveau fonctionnel serait en fait de la logique métier…

                        Sérieusement, l'exemple que je donne remplace des milliers de vues par une fonction ou procédure stockée. Les vues seraient de la logique métier selon toi ?

                        Il y a d'autres choix que les 3 que tu donne. Par exemple tu peux gérer ça via des batch ou monter une architecture lambda si tu a besoin de temps réelle et tu as tout un tas d'organisation possibles qui vont plus ou moins impacter ton design en fonction des besoins que tu as.

                        Pourquoi j'irai compliquer mon architecture, rajouter des scripts ou des datastore à droite à gauche si je n'en ai pas besoin ? Tu te plains plus haut de la dispersion des éléments logiques entre plusieurs endroits et ta solution consiste à disperser les éléments data à la place ?
                        Mon gars qui fait du reporting je préfère grandement qu'il ait une seule connexion via une seule interface plutôt que de le voir ouvrir une connexion à la DB, une autre à l'ETL et une troisième à un datastore quelconque pour pouvoir faire ses rapports.

                        J'aurais vraiment peur de cette solution. Comment ça se comporte avec un million de ligne ? 100 millions ? Si ta base est en cluster (est-ce distribué ? Est-ce que tu perçois clairement ce qui va entraîner une réduction de tes données ? Quelle est la granularité de lock que tu met sur tes données) ? Faire des traitement de plusieurs secondes sur une base (qui doit déjà prendre la charge de la production) ça me semble pas être une excellente idée.

                        Alors dans le désordre :
                        - Le lock : besoin très minime, c'est de la lecture seule. Si vraiment le besoin s'en fait sentir on peut créer un index sur un timestamp pour s'assurer que toutes les données étaient présentes à l'instant X et qu'aucune n'est arrivée en cours de route. Mais sur du reporting financier/marketing je ne pense pas que ce soit nécessaire (les chiffres de la dernière seconde intéressent peu de monde, généralement on fait ce type de reporting sur des données qui ont au moins 24h )

                        • La tenue de charge en cas de forte demande/grosse quantité de données : Ce sera la même que celle de la base SQL ou NoSQL sous-jacente. Peut importe que ce soit via fonction, vue ou cube OLAP virtuel, si la base de données ne peut pas encaisser la charge d'une façon il y a peu de chance qu'elle puisse l'encaisser d'une autre. Et encore les fonctions et procédures seront plus performantes que les deux autres méthodes.

                        • Le partitionnement ou les cluster : Je ne vois pas de cas ou cela pourrait avoir un impact négatif. Une fois de plus un traitement par fonction ou procédure sera nécessairement meilleur qu'un traitement séquentiel par requête ou par vue. ne serait-ce que parce que lors d'un traitement par fonction la BDD peut travailler en format binaire interne tout du long et ne doit faire la conversion format de sortie des données qu'à la toute dernière étape.

                        • La durée des traitement et la saturation des I/O BDD : Une fois de plus les fonctions et procédures ne peuvent qu'améliorer l'existant sans rien bloquer autour. En plus on peut parfaitement faire une base dédiée reporting (donc sans impact sur la prod) et utiliser des procédures quand même sur cette base. Pour finir il est nettement plus simple de limiter les I/O et la consomation CPU d'une procédure définie que de tous les accès possibles et imaginables à des vues et des tables.

                        A titre d'information j'utilise ce type de techniques sur des centaines de millions de lignes (données géométriques, ça va très vite) avec des temps de réponses de l'ordre de la milliseconde. C'est un problème de design de base de données et de placement des index - l'utilisation ou non des procedures stockées n'a pas grande influence sur le résultat final.

                        • [^] # Re: Facile!

                          Posté par . Évalué à 3.

                          GNI ? L'exemple que je donne c'est la réponse à un besoin exprimé par la direction au niveau base de données. La base de données elle même a probablement été créé pour répondre à un besoin exprimé par la direction (ou autre). Ça revient à dire que toute base de données qui sert à quelque chose au niveau fonctionnel serait en fait de la logique métier…

                          Tes utilisateurs se foutent de ta base. Si ta base consiste à écrire sur du papier tes données, c'est pas leur problème (tant que ça répond aux contrainte que l'on te donne).

                          Le code métier c'est celui qui répond à une problématique métier. C'est pointé directement par une User Storie. Le code non métier c'est celui qui consiste à traduire tes dates en timestamp parce que tu préfère les stocker comme ça.

                          Ici le fait que tu calcul tes projections dans une direction ou dans une autre ça impact directement tes utilisateurs. C'est donc quelque chose que tu dois valider avec les utilisateurs ça concerne leur métier.

                          Si tu décide de passer à du stockage en fichier XML. Cette traduction en XML ce n'est pas métier, l'utilisateur se fout de savoir si tu stocke du XML ou autre chose ça ne va pas changer sa façon de travailler.

                          C'est plus clair ?

                          Pourquoi j'irai compliquer mon architecture, rajouter des scripts ou des datastore à droite à gauche si je n'en ai pas besoin ? Tu te plains plus haut de la dispersion des éléments logiques entre plusieurs endroits et ta solution consiste à disperser les éléments data à la place ?

                          Ça ne demande rien de tout ça. Ça demande à créer des classes/fonctions en plus oui. Le reste est uniquement dépendant de ton besoin. Ce n'est pas parce que tu organise ton code pour qu'il soit distribuable qu'il faut le distribuer.

                          La tenue de charge en cas de forte demande/grosse quantité de données : Ce sera la même que celle de la base SQL ou NoSQL sous-jacente. Peut importe que ce soit via fonction, vue ou cube OLAP virtuel, si la base de données ne peut pas encaisser la charge d'une façon il y a peu de chance qu'elle puisse l'encaisser d'une autre. Et encore les fonctions et procédures seront plus performantes que les deux autres méthodes.

                          Ton code s'exécute sans demander de temps CPU ? Le faire exécuter l'algo sur un autre service, ça permet de réduire la charge CPU consommée par ta base (et donc de lui laisser faire ce qu'elle fait de mieux : les IO) et du peux lisser la charge que tu impose à ta base via de la backpressure.

                          Une fois de plus les fonctions et procédures ne peuvent qu'améliorer l'existant sans rien bloquer autour. En plus on peut parfaitement faire une base dédiée reporting (donc sans impact sur la prod) et utiliser des procédures quand même sur cette base.

                          Quel est l'intérêt ? Tu peux calculer tes projections lors de l'alimentation de cette base. Si un changement de besoin interviens, tu peut détruire ta base de reporting et la reconstruire avec tes nouvelles projections.

                          C'est un problème de design de base de données et de placement des index - l'utilisation ou non des procedures stockées n'a pas grande influence sur le résultat final.

                          Elles sont juste une misère à tester :)

                          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                          • [^] # Re: Facile!

                            Posté par . Évalué à 7.

                            Ici le fait que tu calcul tes projections dans une direction ou dans une autre ça impact directement tes utilisateurs. C'est donc quelque chose que tu dois valider avec les utilisateurs ça concerne leur métier.

                            Je ne calcule pas mes projections d'une façon ou d'une autre, je créé des vues - il n'y a pas de calcul coté BDD. Une vue SQL par exemple c'est juste un test qui dit "si on te demande les données de TITI, renvoie à la place les données de TATA ". Et comme je n'ai pas envie de créer toutes les vues possibles et imaginables je fais une fonction à la place. Il n'y a aucun calcul spécifique métier qui est fait en base. Ce ne sont que des opérations de consolidation et d'agrégation génériques. Je n'ai rien besoin de valider avec mes utilisateurs si ce n'est l'interface qu'ils doivent utiliser. Plutôt que de leur dire tu fais

                            SELECT * from (
                            SELECT …
                            UNION SELECT …
                            UNION SELECT …
                            UNION SELECT …
                            JOIN
                            SELECT …
                            UNION SELECT …

                            ON …
                            ) WHERE month=4 GROUP BY "CLIENT", "PRODUIT" HAVING SUM("CA") > 10000

                            Je leur dit tu fais

                            SELECT * FROM fonction_aggregat(['CLIENT','PRODUIT'], '{"month":"=4", "sumca":">10000"}')

                            Pour la base de données il n'y a aucune différence en terme SQL, il y a un petit surcout lors de la préparation de la procédure fonction_aggregat, mais qui est négligeable et qui se rembourse largement si la procédure est appelée plus d'une fois. Le surcout du parsing est infime, les I/O sont divisés par 10 par rapport à des requêtes classiques ou des vues, je peux forcer le plan d’exécution que je veux, la priorité, le temps CPU etc.

                            Et une fois de plus ça ne rempli pas d'autres rôle qu'une vue.

                            Ça ne demande rien de tout ça. Ça demande à créer des classes/fonctions en plus oui. Le reste est uniquement dépendant de ton besoin. Ce n'est pas parce que tu organise ton code pour qu'il soit distribuable qu'il faut le distribuer.

                            Mais pourquoi j'irais créer des fonctions (ou classes) de filtrage et de présentation de données dans mon code, alors que ça va pénaliser la base de données. Si je ressors la table entière, l'impact I/O va être délirant - si je fait une partie du filtrage coté BDD (WHERE ou HAVING) pourquoi j'irais mettre le reste du filtrage dans mon appli ? Filtrer et présenter les données c'est le boulot de la base, et elle va le faire beaucoup mieux, beaucoup plus vite (surtout en BDD relationnel) que mon appli qui voit devoir commencer par tout remapper avant de pouvoir finir le boulot.

                            Ton code s'exécute sans demander de temps CPU ?

                            OUI ! Le cout CPU des procédures que je cite est nul, voire négatif par rapport à une execution SQL brute de décoffrage. La première exécution va prendre quelques pouillèmes de millisecondes en plus (et encore une très grosse procédure) - toutes les exécutions suivantes seront plus rapide et moins consommatrice de CPU que l'équivalent SQL. La BDD n'aura plus à faire le préscan, à choisir entre le bitmap scan ou le seq scan ou les index, à définir la taille des rows de sortie, à dimensionner les flux etc. Tout ce travail aura été fait lors du premier appel, et les appels suivant seront plus rapides et moins gourmands que le SQL.

                            Quel est l'intérêt ? Tu peux calculer tes projections lors de l'alimentation de cette base. Si un changement de besoin interviens, tu peut détruire ta base de reporting et la reconstruire avec tes nouvelles projections.

                            Les données sont en flux continue depuis plusieurs sources. C'est pas parce qu'une source change que je vais détruire toute ma base et refaire toutes mes vues.

                            Elles sont juste une misère à tester :)

                            Par rapport à des milliers de vues, ou des milliers de requètes SQL plus ou moins propres et subtilement différentes dans le code de l'appli ? Mon choix est vite fait…

                            • [^] # Re: Facile!

                              Posté par . Évalué à 4.

                              Je comprends tu remplace surtout du SQL par des procédures stockées. La comparaison que je fais est différente. J'ai probablement perdu un peu l'habitude de travailler avec du sql et c'est vrai qu'il faut savoir utiliser ses outils à bon escient (suivre la philosophie de ses outils). Néanmoins je pense qu'il faut tout de même faire attention à la charge que l'on ajoute sur ces serveurs :

                              • ils sont taillés pour du stockage et du débit pas du calcul
                              • il y a certains calculs qui vont être particulièrement optimisables, mais pas forcément tous (la complexité de ton algo ne change pas magiquement parce que tu l'excute sur la bas de données)

                              Merci en tout cas pour ton exemple très pertinent

                              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                  • [^] # Re: Facile!

                    Posté par (page perso) . Évalué à 3.

                    Ce qui n'a pas de sens. Enfin… Pas dans le sens que tu l'indique. Soit changer ton modèle a des implications métier (ça arrive forcément), soit ça impact uniquement ta couche persistance (quand tu travail en couche).

                    Cela manque de précision, je le concède ;) Le plus simple est de prendre un exemple. Actuellement, je suis sur une application qui évolue tout le temps (car les besoins changent, le cadre d'application, la loi, etc…). Il m'arrive de devoir faire des modifications au niveau du schéma de la BD afin justement de pouvoir prendre en compte ces besoins futurs (qui ne vont pas tarder à arriver), mais qui ne sont pas encore développés. Je peux ainsi mettre à jour petit à petit l'application, souvent, et sans difficulté. C'est très pratique pour pouvoir la tester en condition réelle (je fais bien entendu des tests avant ! Mais les meilleurs testeurs restent les utilisateurs).

                    AMHA garder le même langage que sur le reste de l'application, ainsi que le même protocole de test est bien plus efficace pour maintenir ce code.

                    Il y a des pour et des contre dans chacune de ces approches. Pour avoir tester les deux, je préfère celle que j'emploie actuellement. Mais là, c'est purement subjectif ! (D'ailleurs, j'aurais d'autre type de projet, ce n'est pas dis que je ne choisirai pas l'autre).

                    Euh… tu as tes contraintes d'intégrité pour ça et si ça ne suffit vraiment pas tu as des triggers qui peuvent faire le boulot. Je suis pas grand fan, mais si vraiment tu veux de la cohérence forte c'est une possibilité (en se limitant à coder des invariants).

                    Les contraintes d'intégrités ne font pas tout. Bien sûr, c'est l'élément de base ! Mais cela reste limité et ne fait donc pas tout. Va faire une contrainte du style "si j'ai une ligne X dans la table A, alors il me faut les lignes Y et Z dans la table B".

                    Quant aux triggers, je suis étonné de te le voir mentionner. Car si pour toi l'utilisation des procédures stockées mérite d'être pendu haut et court, que dire de l'utilisation des triggers ? C'est le truc le plus discret qui soit ! Discret dans le sens où ce sont des actions qui sont faite de manière implicite en réponse à un événement, contrairement aux procédures stockées qui sont appelées explicitement.

                    Et il est impossible d'avoir de bug dans une procédure stockée ? :)

                    Je n'ai jamais dis cela ;) Mais quand on est dans un environnement où il faut faire vite, pouvoir cibler les tests, ce n'est pas plus mal :)

                    Si j'en suis vraiment là, je préfère partir sur de l'event sourcing. Mes données sont immutables. Je reçois les données, je les stocke et ensuite je vois comment les organiser pour les rendre utilisable (sans toucher le premier stockage des données). C'est résilient (je peux reconstruire mes projections à tout moment), ça évolue très facilement et c'est facilement distribuable.

                    Ce qui a un impact sur l'architecture en place (je pense à la configuration du serveur notamment). Des contraintes budgétaires peuvent faire en sorte que ce n'est pas possible de mettre cela en place. Par exemple, une application hébergeant des données de santé doit utiliser un hébergeur agréé données de santé. Les prix ne sont pas du tout les mêmes qu'un VPS chez OVH, crois moi ! (j'ai choisi VPS car c'est ce qui se rapproche le plus de la config du serveur que j'exploite actuellement). 140€HT/an pour l'un, plus de 10000€HT/an pour l'autre (et encore, le VPS est plus gonflé en RAM et dispose d'un SSD :p)

                    Maintenant, je le redis (juste au cas où ;) ). Je ne dis pas que mon approche est meilleure. Je l'ai seulement décrite pour te montrer, par un cas concret, que ce que tu disais est faux (procédure stocké, hérésie, non maintenable) :)

                    • [^] # Re: Facile!

                      Posté par . Évalué à 2.

                      Cela manque de précision, je le concède ;) Le plus simple est de prendre un exemple. Actuellement, je suis sur une application qui évolue tout le temps (car les besoins changent, le cadre d'application, la loi, etc…). Il m'arrive de devoir faire des modifications au niveau du schéma de la BD afin justement de pouvoir prendre en compte ces besoins futurs (qui ne vont pas tarder à arriver), mais qui ne sont pas encore développés. Je peux ainsi mettre à jour petit à petit l'application, souvent, et sans difficulté. C'est très pratique pour pouvoir la tester en condition réelle (je fais bien entendu des tests avant ! Mais les meilleurs testeurs restent les utilisateurs).

                      C'est la couche métier qui fait ce boulot chez moi (la DAO si tu préfère).

                      Quant aux triggers, je suis étonné de te le voir mentionner. Car si pour toi l'utilisation des procédures stockées mérite d'être pendu haut et court, que dire de l'utilisation des triggers ? C'est le truc le plus discret qui soit ! Discret dans le sens où ce sont des actions qui sont faite de manière implicite en réponse à un événement, contrairement aux procédures stockées qui sont appelées explicitement.

                      Tout est dans la parenthèse « en se limitant à coder des invariants ». Il s'agit uniquement de faire péter une erreur en cas de modification foireuse de tes données. Tu ne fais que valider la cohérence de tes données rien de plus.

                      Ce qui a un impact sur l'architecture en place (je pense à la configuration du serveur notamment).

                      Pas forcément autant que tu ne semble le croire. Je suis entrain de m'amuser avec vertx. Pour faire de l'event sourcing. Pour le moment c'est juste une application java multithreadé avec un mongodb et un hazelcast (embarqué). Donc le tout avec un seul serveur. Puis gérer une distribution du système uniquement par configuration et ainsi être capable de monter en charge via la multiplication de serveur spécifique et utiliser le bus d'événement que j'utilise déjà pour faire le job.

                      C'est peut être la volumétrie qui augmente si tu as beaucoup d'événements qui modifie des données existante. Tu peut optimiser ça par un batch qui va agréger tes données (il suffit que ça fréquence soit inférieure au temps que tu métrais pour détecter le bug).

                      Dans l'autre sens, tu as beaucoup de cas où tu cherche une traçabilité totale de tes données, là tu l'a de base. :)

                      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

            • [^] # Re: Facile!

              Posté par . Évalué à 2.

              Plus sérieusement, à te lire, on a l'impression que la procédure stockée, c'est le mal. Que tu ne les utilises pas et/ou que tu ne l'aimes pas, c'est ton choix. Dire que c'est de la merde, désolé, je ne peux pas ne pas réagir.

              C'est comme pour les frameworks …

              • [^] # Re: Facile!

                Posté par . Évalué à 2.

                Et même solution : les microservices :-)

          • [^] # Re: Facile!

            Posté par . Évalué à 2.

            Windows pourra bientôt tourner dans Docker (oui ça surprend toujours la première fois).

            Je sais qu'ils bossent sur cela mais j'attend vraiment de voir cela, un docker windows sous linux.

            • [^] # Re: Facile!

              Posté par (page perso) . Évalué à 5.

              j'avais compris le contraire : des conteneurs Docker classiques qui tournent sur du Windows.

            • [^] # Re: Facile!

              Posté par . Évalué à 2.

              J'avais compris des containers windows sur windows et des containers linux sous linux.
              Après, c'était avec qemu. Non ?

          • [^] # Re: Facile!

            Posté par . Évalué à 7.

            Le mec qui me dit que le mec qui lui dit qu'il faut faire des proc stockées doit être pendu, je le prends pas sur un projet.

            C'est une approche dogmatique. Comme d'habitude, il n'y a pas d'approche miracle qui répond à tout.

            Tu as déjà eu des traitements de masse à faire sur une base SQL ? Et tu fais ça via ton appli qui charge chaque ligne, fait le calcul, et stocke le résultat ? Tu fais ça 10,000,000 fois, et tu penses que parce que tu as été super fort, en répartissant le travail sur 200 noeuds, tu as obtenu une bonne vitesse de traitement ? Quid des I/Os engendrées entre la machine hébergeant la base, et la machine hébergeant ton application ? Le franchissement de DMZ, la charge sur la baie de stockage, la non-utilisation du cache de la base, et j'en passe ?

            Mon dieu…

            C'est pas seulement une question de savoir où on met la couche truc et la layer bidule. C'est juste d'avoir un temps d'exécution acceptable pour répondre aux contraintes des utilisateurs.

            • [^] # Re: Facile!

              Posté par . Évalué à 0.

              Le mec qui me dit que le mec qui lui dit qu'il faut faire des proc stockées doit être pendu, je le prends pas sur un projet.

              C'est une approche dogmatique. Comme d'habitude, il n'y a pas d'approche miracle qui répond à tout.

              Hé hé ! Comme je l'ai dit après je vais surtout t'obliger à affûter tes arguments autant que possible pour la moindre ligne de ce genre de code.

              Par exemple personne ne m'a encore expliqué comment tu teste ce code (avec une certaine complétude tout de même donc mesurable).

              C'est assez drôle l'histoire de la DMZ. Si tu penses pouvoir te permettre d'avoir un mauvais débit entre ta base et ton application, c'est que tu te fous des performances.

              Par contre ça peut être sympa d'aller voir des gens qui ont ce genre de problèmes mais avec une charge plusieurs magnitudes de fois supérieure à ce qu'on trouve généralement. Les Google, Facebook, Netflix, etc sont très prolixes sur ce genre de sujets et ils ne cherchent pas à vendre du cloud, une appli ou une techno, juste ils partagent leur expérience.

              Je ne doute pas qu'il y en a qui sont contents avec des procédures stockées. Mais il faut les tester et maintenir les tests et leur qualité tout au long de la vie du logiciel. C'est très coûteux parce que tu n'a pas framework de test et très long parce que du coup ce sont des tests d'intégration. Et ça ne se vend pas. Alors que la performance si, donc on a facilement tendance a ajouter des choses en procédure stockée parce que c'est plus rapide, avec une tendance a faire moins de tests parce que c'est plus long et compliqué tout ça avec potentiellement plus de bugs parce que c'est un mode d'exécution différents du reste de l'application. Ok tu arrive à gérer tout ça… Aujourd'hui, mais dans un ou deux ans ?

              Puis un jour tu as de nouvelles contraintes qui te poussent à changer de base (l'arrêt du support de ta base actuelle par exemple ?) et là tu pleure tout ce que tu peux.

              Ce n'est pas de la théorie, j'ai déjà eu plusieurs expérience de ce genre.

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

              • [^] # Re: Facile!

                Posté par (page perso) . Évalué à 8.

                Je ne doute pas qu'il y en a qui sont contents avec des procédures stockées. Mais il faut les tester et maintenir les tests et leur qualité tout au long de la vie du logiciel. C'est très coûteux parce que tu n'a pas framework de test et très long parce que du coup ce sont des tests d'intégration.

                Ceci dit le monsieur parlait de migration. Tu peux faire du pl/pgsql (par exemple) pour les migrations en documentant que ça marche de telle version à telle version c'est tout. Pas besoin de les maintenir en toute circonstance.

                Par contre ça peut être sympa d'aller voir des gens qui ont ce genre de problèmes mais avec une charge plusieurs magnitudes de fois supérieure à ce qu'on trouve généralement. Les Google, Facebook, Netflix

                Il faut aussi revenir sur terre et se dégonfler les chevilles. Non seulement tout le monde n'est pas Google, Facebook, Netflix, mais en fait personne n'est Google, Facebook, Netflix. J'avais beaucoup aimé un tweet qui mettait une bonne claque aux mecs qui disent faire du BigData parce qu'ils ont quelques dizaines/centaines de Go de data, qui expliquait en gros qu'un dédié OVH avec 128Go de RAM coûte 120€/mois, alors si ta data tient dans la RAM d'un serveur bas de gamme, faut arrêter de s'exciter.

                • [^] # Re: Facile!

                  Posté par . Évalué à 5.

                  Moi j'aime bien le tweet qui expliquais que le big data ce n'est pas une question de volume de données, mais une architecture qui met la données au centre de ta problématique.

                  Comme quoi…

                  Toujours est-il que m'expliquer que c'est intenable question performances alors que beaucoup de monde s'en servent c'est rigolo.

                  C'est une autre manière de penser et de nouvelles architectures qui ont émergées avec la volonté de réduire la complexité des bases de données avec les bases NoSQL.

                  Ça s'utilise très bien même à petite échelle. Ce n'est pas parce qu'on te parle d'un processus en plus que t'a besoin d'un nouveau serveur ou d'un serveur en plus.

                  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

              • [^] # Re: Facile!

                Posté par . Évalué à 3.

                C'est assez drôle l'histoire de la DMZ. Si tu penses pouvoir te permettre d'avoir un mauvais débit entre ta base et ton application, c'est que tu te fous des performances.

                Il n'y a pas que le débit, il y a la latence aussi. Tu peux avoir 20Gbs entre deux éléments, si tu as 100000000 aller retour, ça peut être long et accessoirement ça peut charger un Firewall.

            • [^] # Re: Facile!

              Posté par . Évalué à 2.

              la non-utilisation du cache de la base

              Tu l'a testé ça ? Parce que selon ton profile d'utilisation tu augmente juste la pression sur ce cache et tu réduis les perf de ta production.

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

              • [^] # Re: Facile!

                Posté par . Évalué à 2.

                Ce que tu décris, c'est l'exception ; dans la plupart des cas, plus de cache signifie moins d'I/O physiques et plus d'I/O logiques.

                Sur une base pouvant tenir entièrement en RAM (i.e. moins de 200 Go pour des machines un peu récentes), j'ai vu une amélioration des performances d'environ 50% sur une machine qui saturait les I/Os entre le dataserver et le SAN.

                Donc oui, je l'ai déjà testé. Plusieurs fois.

          • [^] # Re: Facile!

            Posté par (page perso) . Évalué à 7.

            Quelque soit le SGBDR, le mec qui me dit qu'il faut faire de la procédure stockée, mérite d'être pendu haut et court.

            Ça fait plus de 35 ans que j'en écris et en lisant ce genre d'assertion farfelue je comprends pourquoi l'informatique va si mal.
            Vivement la retraite…

            • [^] # Re: Facile!

              Posté par . Évalué à 3.

              J'ai aussi du mal à comprendre… Quand il s'agit de faire un choix sur le placement d'une fonctionnalité je réfléchi toujours en terme de métier. L'ingénieur bases de données s'en fou que derrière il y ai du java ou du brainfuck, il faut qu'il présente des données intelligibles par lui même. Cela peut être plus parlant avec les traductions i18n, cela viendrait à l'esprit de quelqu'un de mettre les traductions dans des fichiers java, car le reste est en java? Bien sur que non, je vois bien la gueule du traducteur si on lui file un fichier java.
              Et je ne comprend pas trop l'argument de la testabilité des procédures ? Qu'es ce qui t'empêche de faire des suites de tests? Il manque peut être le framework qui va bien…
              Malheureusement dans ma courte expérience et les différents exemples que l'on peut trouver, c'est très fréquent de tout mélanger pour une (pseudo) histoire de simplicité. Définir une base de données à partir du SQL généré par hibernate qui vient de beans java et d'annotation. Ces même beans envoyés directement par le WS au client. Pas grave on génère le wadl et le xsd depuis ces même beans. C'est sûr, c'est rapide à créer… C'est bien le seul point positif.

              • [^] # Re: Facile!

                Posté par . Évalué à 3.

                Quand il s'agit de faire un choix sur le placement d'une fonctionnalité je réfléchi toujours en terme de métier.

                De métier dans la conception de logiciels ? :-) On est loin des développeurs fullstack ou du devops.

                Mais en quoi est-ce le boulot de ton dba de savoir ce qu'est un modèle linéaire ? De faire des régressions statistiques ? Ou tout un tas d'autres choses encore plus intéressantes les unes que les autres ?


                Je suis content, j'ai fait émerger des questions que je trouvais intéressantes et des cas où oui les procédures stockées peuvent être utiles. Je reste sur mon idée de limiter ça autant que possible parce que personne n'a encore su me répondre sur les tests (ça me paraît grave), que l'on voit plus bas que ça peut être limitant, parce que ça crée une dépendance forte sur la base de données,…

                Je pense être arrivé au bout du débat et qu'il n'est pas possible de continuer de manière intéressante (sans tourner en rond et sans partir sur des cas précis sans être en mesure de connaître leur représentativité).

                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                • [^] # Re: Facile!

                  Posté par (page perso) . Évalué à 2.

                  Je suis content, j'ai fait émerger des questions que je trouvais intéressantes et des cas où oui les procédures stockées peuvent être utiles. Je reste sur mon idée de limiter ça autant que possible parce que personne n'a encore su me répondre sur les tests (ça me paraît grave),

                  Personnellement, je n'ai pas répondu sur les tests, car je n'ai aucun soucis pour en faire ! Explique nous ton problème et alors on pourra peut-être y répondre. Mais il n'y a pas de soucis majeur. C'est comme un test classique. Eventuellement, tu charges un dump de ta BD pour connaitre précisément ton état de départ et faire les vérifications qui vont bien ensuite. Mais il n'y a aucune difficulté majeure.

                  parce que ça crée une dépendance forte sur la base de données,…

                  Je comprends très bien cette notion de dépendance. Néanmoins, elle dépend aussi du contexte. Quand ton client est une entreprise, elle se fou généralement de pouvoir changer de SGBD l'année prochaine. C'est très loin de sa priorité. Elles veulent généralement quelque chose qui marche, qui est rapide, stable et pas cher (donc forcément, il y a des compromis à faire :) )

                  Un contexte où, par contre, cela a son importance, ce sont les logiciels libres. Quel bonheur de pouvoir utiliser un redmine avec le SGBD de son choix par exemple (mais ce n'est pas non plus une obligation non plus. Wordpress impose mysql par exemple (enfin sauf si ça a changé récemment xD)).

                  • [^] # Re: Facile!

                    Posté par . Évalué à 3.

                    Éventuellement, tu charges un dump de ta BD pour connaître précisément ton état de départ et faire les vérifications qui vont bien ensuite. Mais il n'y a aucune difficulté majeure.

                    Tu mesure comment la complétude de ton test ? Ça impose de créer des tests d'intégration pour quelque chose que je préfère très largement tester de manière unitaire (avoir une boucle de feedback courte et tester tous les cas les plus bizarre sans que ça ne me prenne trop de temps). Même pour un test d'intégration c'est particulièrement lourd parce qu'il faut manager la base de données (créer des bases à la volée ou les nettoyer à la volée).

                    C'est très loin de sa priorité. Elles veulent généralement quelque chose qui marche, qui est rapide, stable et pas cher (donc forcément, il y a des compromis à faire :) )

                    Tout à fait, l'implémentation elle s'en fout, mais tu obtiens des retours d'expérience comme ça : https://linuxfr.org/users/msusa/journaux/microsoft-va-porter-sql-server-sur-linux#comment-1647122

                    Ça peut aussi avoir son importance en fonction de qui c'est qui fait l'administration du projet. Tu peut avoir une entreprise qui t'explique que leur compétence interne (ou leur presta) c'est la base X, qu'ils ont déjà un cluster et qu'ils maîtrisent parfaitement ça (voir qu'ils ont un partenariat avec l'éditeur de cette base) et que si tu leur impose d'utiliser ta base ça va probablement pas coller. C'est ultra relou (c'est pas à eux de t'imposer la conception normalement), mais ça existe (pas dans tous les contextes bienheureusement).

                    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                    • [^] # Re: Facile!

                      Posté par (page perso) . Évalué à 2.

                      Tu mesure comment la complétude de ton test ? Ça impose de créer des tests d'intégration pour quelque chose que je préfère très largement tester de manière unitaire (avoir une boucle de feedback courte et tester tous les cas les plus bizarre sans que ça ne me prenne trop de temps). Même pour un test d'intégration c'est particulièrement lourd parce qu'il faut manager la base de données (créer des bases à la volée ou les nettoyer à la volée).

                      La réponse est simple : je ne teste pas la complétude xD

                      Il y a une raison simple à cela : quand j'écris des tests unitaires, je le fais sur une interface, et non sur une implémentation.

                      Ensuite, cela n'aurait que peu de sens de toutes façons, car là où en programmation séquentielle on va être obligée de faire des boucles, des if, etc… on peut souvent se contenter d'opération ensembliste en SQL (je ne dis pas que c'est toujours le cas hein !).

                      Tout à fait, l'implémentation elle s'en fout, mais tu obtiens des retours d'expérience comme ça : https://linuxfr.org/users/msusa/journaux/microsoft-va-porter-sql-server-sur-linux#comment-1647122

                      Retour d'expérience du développeur, pas du client ;) Après, c'est l'argument qui marche dans les deux sens. Ici, en négatif car il manque plein de fonctionnalité par rapport aux "concurrents". Mais il pourrait être en positif (j'utilise Postgresql, je peux faire des recherches via des regex, des opérations sur des coordonnées (merci postgis)). Choses qui ne seraient pas possibles en restant généraliste.

                      Ça peut aussi avoir son importance en fonction de qui c'est qui fait l'administration du projet. Tu peut avoir une entreprise qui t'explique que leur compétence interne (ou leur presta) c'est la base X, qu'ils ont déjà un cluster et qu'ils maîtrisent parfaitement ça (voir qu'ils ont un partenariat avec l'éditeur de cette base) et que si tu leur impose d'utiliser ta base ça va probablement pas coller. C'est ultra relou (c'est pas à eux de t'imposer la conception normalement), mais ça existe (pas dans tous les contextes bienheureusement).

                      Là, je vois deux cas possible :
                      - ou bien ils achètent une solution existante, et dans ce cas là, c'est à eux de s'adapter (sinon, c'est que la solution ne leur convient pas)
                      - ou bien c'est un développement sur mesure, et dans ce cas, le choix du SGBD est à prendre en compte dès le départ.

                      (c'est pas à eux de t'imposer la conception normalement)

                      Un choix technologique peut tout à fait faire partie du cahier des charges. Rien de relou la dedans ;) Ils établissent juste des contraintes et c'est à toi ensuite de faire une conception tenant compte de ces contraintes.

                      • [^] # Re: Facile!

                        Posté par . Évalué à 4.

                        Ensuite, cela n'aurait que peu de sens de toutes façons, car là où en programmation séquentielle on va être obligée de faire des boucles, des if, etc… on peut souvent se contenter d'opération ensembliste en SQL (je ne dis pas que c'est toujours le cas hein !).

                        Il n'y a pas de rapport :) Tu as un traitement, tu test ce traitement que ce soit du fonctionnel, du séquentiel, de l'objet, de la machine de turing ou autre.

                        Là, je vois deux cas possible :
                        - ou bien ils achètent une solution existante, et dans ce cas là, c'est à eux de s'adapter (sinon, c'est que la solution ne leur convient pas)
                        - ou bien c'est un développement sur mesure, et dans ce cas, le choix du SGBD est à prendre en compte dès le départ.

                        Il y a beaucoup d'entreprises qui sont entre les deux. Tu achète une solution que tu fais adapter à tes besoins soit par l'éditeur soit par un intégrateur.

                        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                        • [^] # Re: Facile!

                          Posté par (page perso) . Évalué à 1.

                          Il n'y a pas de rapport :) Tu as un traitement, tu test ce traitement que ce soit du fonctionnel, du séquentiel, de l'objet, de la machine de turing ou autre.

                          Je vais au bout de ma pensée, puisque semble-t-il tu ne m'as pas compris (j'admet que je n'ai pas été super clair non plus :p).

                          On teste, je suis d'accord la dessus. Maintenant, c'était au niveau de la complétude. Quand tu as du une boucle avec des if dans des if dans des if, tu te dois de vérifier que toutes les branches sont explorées.

                          Lorsque je disais que souvent on pouvait se contenter d'opération ensembliste en SQL, on peut se passer dans beaucoup de cas des boucles, des conditionnel etc… Au final, il ne reste qu'une seule branche ! Et donc avec un test, tu as ta complétude ;)

                          Il y a beaucoup d'entreprises qui sont entre les deux. Tu achète une solution que tu fais adapter à tes besoins soit par l'éditeur soit par un intégrateur.

                          Adapter oui. Faire des changements profond pour que cela devienne non plus une "évolution" mais une "révolution" non. Ou alors il faut faire un GROS GROS chèque. Mais dès qu'on part sur une "révolution" et non sur une "évolution", il faut se demander si le choix est pertinent (développer une nouvelle solution peut être moins cher et plus adaptée que d'utiliser des solutions existantes que l'on adapte).

                          • [^] # Re: Facile!

                            Posté par . Évalué à 3.

                            Lorsque je disais que souvent on pouvait se contenter d'opération ensembliste en SQL, on peut se passer dans beaucoup de cas des boucles, des conditionnel etc… Au final, il ne reste qu'une seule branche ! Et donc avec un test, tu as ta complétude ;)

                            Tu y crois ou le smiley est là pour préciser que tu troll ? C'est toi qui disait 2 messages plus haut que tu test une interface ? Le fait de ne pas pouvoir mesurer la complétude avec la couverture de code n'indique pas que ta couverture est complète (et c'est le cas avec n'importe quelle paradigme d'ailleurs).

                            Faire des changements profond pour que cela devienne non plus une "évolution" mais une "révolution" non.

                            Une révolution ? Ce que redmine fait de base par exemple ? C'est ton couplage fort qui en fait une révolution.

                            Ou alors il faut faire un GROS GROS chèque.

                            Juste le besoin de vivre ça peut arriver. Tu parle plus haut de l'éditeur qui a sa solution déjà prête type informatique sur étagère. Ça ne se fait pas tout seul et le développement de ta solution peut être soutenu par des clients qui ont des besoins différents.

                            Mais dès qu'on part sur une "révolution" et non sur une "évolution", il faut se demander si le choix est pertinent (développer une nouvelle solution peut être moins cher et plus adaptée que d'utiliser des solutions existantes que l'on adapte).

                            Ce sont des choix d'architecte. Mais tu va vouloir factoriser ton code (via des bibliothèques ou un framework) et… tu va peut être te rendre compte que ce serait cool de factoriser ce qui est dans tes

                            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                            • [^] # Re: Facile!

                              Posté par (page perso) . Évalué à 1. Dernière modification le 10/03/16 à 15:34.

                              Tu y crois ou le smiley est là pour préciser que tu troll ? C'est toi qui disait 2 messages plus haut que tu test une interface ? Le fait de ne pas pouvoir mesurer la complétude avec la couverture de code n'indique pas que ta couverture est complète (et c'est le cas avec n'importe quelle paradigme d'ailleurs).

                              Je troll ;) Je me fou de la complétude lors de mes tests. (Je n'ai pas le temps de le faire et ce n'est pas ma philosophie de faire des tests en connaissant l'implémentation des algos )

                              Une révolution ? Ce que redmine fait de base par exemple ? C'est ton couplage fort qui en fait une révolution.

                              Non. C'est un choix qui a été fait dès la conception. C'est quand on remet en cause un tel choix que cela devient une révolution.

                              Juste le besoin de vivre ça peut arriver. Tu parle plus haut de l'éditeur qui a sa solution déjà prête type informatique sur étagère. Ça ne se fait pas tout seul et le développement de ta solution peut être soutenu par des clients qui ont des besoins différents.

                              Tout à fait. Maintenant, si ta solution est en .Net et que ton client veut du PHP parce qu'il a des compétences en interne, tu fais quoi ? Tu redéveloppes en PHP ? Le choix de la BD, c'est pareil. C'est un choix (celui de se limiter à une seule BD, celui d'en supporter un maximum, etc…).

                              Ce sont des choix d'architecte. Mais tu va vouloir factoriser ton code (via des bibliothèques ou un framework) et… tu va peut être te rendre compte que ce serait cool de factoriser ce qui est dans tes

                              Je crois qu'il manque la fin de la phrase ;)

                              • [^] # Re: Facile!

                                Posté par . Évalué à 3.

                                Je troll ;) Je me fou de la complétude lors de mes tests. (Je n'ai pas le temps de le faire et ce n'est pas ma philosophie de faire des tests en connaissant l'implémentation des algos )

                                J'ai volontairement parlé de complétude et non de couverture pour ne pas emmener le débat sur la couverture de code. La complétude c'est le fait d'avoir tester tous les cas ou du moins les cas aux limites de ton bloc logique. La couverture de code est un outil qui permet d'approximer cette complétude, mais ce n'est pas la seule (l'évaluation de test par mutant en est une autre par exemple).

                                Non. C'est un choix qui a été fait dès la conception. C'est quand on remet en cause un tel choix que cela devient une révolution.

                                ? Tu dis « non » juste par plaisir ? Tu as choisi à la conception (ou après hein on s'en fout) d'avoir un couplage fort avec ta base.

                                Le choix de la BD, c'est pareil. C'est un choix (celui de se limiter à une seule BD, celui d'en supporter un maximum, etc…).

                                Donc ça n'est pas forcément une révolution tel que tu le disais un commentaire plus haut.

                                Je crois qu'il manque la fin de la phrase ;)

                                Il semble en effet, mais vu que tu semble plus intéressé à troller qu'à débattre je laisse ton imagination continuer la phrase dans le sens que tu souhaite.

                                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                                • [^] # Re: Facile!

                                  Posté par (page perso) . Évalué à 1.

                                  J'ai volontairement parlé de complétude et non de couverture pour ne pas emmener le débat sur la couverture de code. La complétude c'est le fait d'avoir tester tous les cas ou du moins les cas aux limites de ton bloc logique. La couverture de code est un outil qui permet d'approximer cette complétude, mais ce n'est pas la seule (l'évaluation de test par mutant en est une autre par exemple).

                                  Alors, effectivement, j'ai compris complétude ici dans le sens couverture de code. Pourquoi ? Car tu parlais de mesure de la complétude. Et comme tu le dis, la couverture de code permet d'approximer la complétude (et je ne connais que ce moyen là). Si ton objectif est de tester tous les cas, que derrière tu testes une procédure stockée ou du code natif ne change absolument rien, et on en revient à la question initiale : où se situe le problème ?

                                  Tu dis « non » juste par plaisir ? Tu as choisi à la conception (ou après hein on s'en fout) d'avoir un couplage fort avec ta base.

                                  Pas du tout. Je ne dis pas non juste par plaisir. Redmine a fait le choix de supporter plusieurs SGBD. C'est une fonctionnalité. Rajouter une fonctionnalité à un logiciel peut demander une révolution. Est-ce plus clair ainsi ?

                                  Donc ça n'est pas forcément une révolution tel que tu le disais un commentaire plus haut.

                                  Mais lis tu ce que j'écris ? Depuis tout à l'heure, je ne dis pas que c'est de changer de BD qui est une révolution, mais de revenir sur un choix qui a été fait à la conception !

                                  Il semble en effet, mais vu que tu semble plus intéressé à troller qu'à débattre je laisse ton imagination continuer la phrase dans le sens que tu souhaite.

                                  Et bien là, je crois que tu as mal interprété mes propos. Même si j'ai glissé un mini troll sur la complétude plus haut, c'est bien le seul (et largement visible à l'aide du smiley en plus). Pour le reste, je suis tout à fait sérieux. Et comme il semblerait que nous avons du mal à nous comprendre parfois, je m'abstiendrais de continuer ta phrase pour éviter de lui donner un sens qu'elle n'avait pas à l'origine.

                                  • [^] # Re: Facile!

                                    Posté par . Évalué à 3.

                                    où se situe le problème ?

                                    https://linuxfr.org/users/msusa/journaux/microsoft-va-porter-sql-server-sur-linux#comment-1647412

                                    Ça impose de créer des tests d'intégration pour quelque chose que je préfère très largement tester de manière unitaire (avoir une boucle de feedback courte et tester tous les cas les plus bizarre sans que ça ne me prenne trop de temps). Même pour un test d'intégration c'est particulièrement lourd parce qu'il faut manager la base de données (créer des bases à la volée ou les nettoyer à la volée).


                                    Est-ce plus clair ainsi ?

                                    • Je te dis que tu peux avoir un besoin de changer de base
                                    • Tu me dis que c'est une révolution qui n'est valable qu'avec un « GROS GROS chèque » (et que tu préférerais peut être même tout réécrire - pour un choix de base de données… -)
                                    • Je t'explique que c'est une révolution parce que tu as un couplage fort avec ta base
                                    • Tu m'explique que c'est ton choix
                                    • Que veux-tu que j'y réponde ? Oui c'est ton choix, j'explique juste qu'utiliser des procédures stockées ça te crée un couplage fort qui peut t'être dommageable. Je vois pas où tu peux vouloir en venir.

                                    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                                    • [^] # Re: Facile!

                                      Posté par (page perso) . Évalué à 1.

                                      Ça impose de créer des tests d'intégration pour quelque chose que je préfère très largement tester de manière unitaire (avoir une boucle de feedback courte et tester tous les cas les plus bizarre sans que ça ne me prenne trop de temps). Même pour un test d'intégration c'est particulièrement lourd parce qu'il faut manager la base de données (créer des bases à la volée ou les nettoyer à la volée).

                                      Je ne sais pas si c'est la fatigue ou quoi, mais je ne comprends pas. Pourquoi, de la nature de la procédure (native ou stockée) dépend le type de test (unitaire ou d'intégration) ? Si tu recodes une procédure native en procédure stockée, le principe de ton test reste le même.


                                      • Tu m'as dit qu'un client pouvait souhaiter utiliser un autre SGBD, pas que j'avais besoin de changé de base ;
                                      • De part le couplage fort, oui, changer de base de données nécessite une révolution. Est-ce que j'ai dit que je préférais tout réécrire ? Non. Relis bien.

                                      Mais dès qu'on part sur une "révolution" et non sur une "évolution", il faut se demander si le choix est pertinent (développer une nouvelle solution peut être moins cher et plus adaptée que d'utiliser des solutions existantes que l'on adapte).

                                      Il faut se poser la question dès qu'il y a une "révolution" (au sens général).

                                      • "Je t'explique que c'est une révolution parce que tu as un couplage fort avec ta base. Et cela peut être dommageable." Et je t'ai aussi montré que le faire autrement pouvait être tout aussi dommageable.

                                      "Mais il pourrait être en positif (j'utilise Postgresql, je peux faire des recherches via des regex, des opérations sur des coordonnées (merci postgis)). Choses qui ne seraient pas possibles en restant généraliste."

                                      Encore une fois, tout est question de choix par rapport à des contraintes initiales. S'il n'y a pas besoin de pouvoir changer de BD, pourquoi se contraindre à le faire et à se limiter aux opérations supportés par toutes bases (CRUD) ? Parce qu'hypothétiquement, dans 5 ans il y en aura besoin ? Il n'y a pas de solutions miracles. Il faut toujours faire des compromis. Maintenant, tu veux savoir où je veux en venir ? Je réponds à ta remarque (trollesque qui plus est) : "Quelque soit le SGBDR, le mec qui me dit qu'il faut faire de la procédure stockée, mérite d'être pendu haut et court."

                                      Depuis le début, je n'arrête pas d'argumenter, de donner des exemples, etc… Je me fais accuser de troll (bon, y'en a un petit, c'est vrai, mais comparé au tien…). Perso, je stoppe là. Je pensais un moment que la discussion était intéressante mais elle est en train de se stériliser à vitesse grand V…

                                      • [^] # Re: Facile!

                                        Posté par . Évalué à 4.

                                        Pourquoi, de la nature de la procédure (native ou stockée) dépend le type de test (unitaire ou d'intégration) ?

                                        Je ne sais pas tester unitairement une procédure stocker (donc exécution uniquement en mémoire et uniquement de la procédure en question). Si tu sais faire c'est cool. Ça fait juste 2 jours que je demande comment on fait.

                                        Tu m'as dit qu'un client pouvait souhaiter utiliser un autre SGBD, pas que j'avais besoin de changé de base ;

                                        Je t'ai montré un exemple de quelqu'un qui aimerait bien ne pas avoir une base en fin de vie sur sa plateforme.

                                        De part le couplage fort, oui, changer de base de données nécessite une révolution. Est-ce que j'ai dit que je préférais tout réécrire ? Non. Relis bien.

                                        Idem relis bien, je n'ai pas dis que tu préférerais. J'ai dis que tu préférerais peut être, je ne vois pas en quoi j'ai dénaturé ton propos.

                                        S'il n'y a pas besoin de pouvoir changer de BD, pourquoi se contraindre à le faire et à se limiter aux opérations supportés par toutes bases (CRUD) ? Parce qu'hypothétiquement, dans 5 ans il y en aura besoin ?

                                        Parce que c'est évitable dans la majorité des cas, que c'est débraillable (tu peut toujours te rendre compte plus tard que c'est pas assez performant et réécrire ton code en procédure stockée) et que ça te coûte chère (en test, en couplage fort, etc). Qu'il y a à mon avis peu de cas où c'est la seule solution. Le couplage fort (en soit) c'est une dette technique (il y en a qui sont inévitables comme le langage (et encore tu peux faire de la génération de code à partir de modèle et d'automate), ça ne se mesure pas (la seule approximation c'est la qualité du code) et quand on te demande de l'encaisser tu déguste. J'ai vus trop de projet souffrir à cause de ça pour le plébisciter comme c'est le cas de beaucoup de monde.

                                        Je réponds à ta remarque (trollesque qui plus est) : "Quelque soit le SGBDR, le mec qui me dit qu'il faut faire de la procédure stockée, mérite d'être pendu haut et court."

                                        Je suis convaincu de ce que je dis. Je le dis de manière un peu abrupte pour susciter le débat. C'est peut être disruptif et ça remet en question des façon de travailler. Je trouve dommage d'apprécier aussi peu la remise en question par certains d'ailleurs, personnellement je considère que si on fait quelque chose plus par habitude qu'autre chose c'est qu'il y a un grave problème (c'est ce qui amène à choisir exchange comme tout le monde, à utiliser Word parce qu'on connaît, à prendre SAP pour pas prendre de risque, etc).

                                        Il y a forcément des gens qui se sentent égratignés, j'explique que ce qu'ils font n'est, à mon avis, pas une bonne façon de travailler. Il y a de l'humain et c'est pour ça que je me fais moinsser. Je le comprends, je peux être un peu plus doux, mais je pense que si j'avais dis :

                                        AMHA les procédures stockées sont rarement la bonne solution

                                        Personne n'aurait réagis, car personne se ne sentirait concerné.

                                        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                    • [^] # Re: Facile!

                      Posté par (page perso) . Évalué à 3.

                      Ça peut aussi avoir son importance en fonction de qui c'est qui fait l'administration du projet. Tu peut avoir une entreprise qui t'explique que leur compétence interne (ou leur presta) c'est la base X, qu'ils ont déjà un cluster et qu'ils maîtrisent parfaitement ça (voir qu'ils ont un partenariat avec l'éditeur de cette base) et que si tu leur impose d'utiliser ta base ça va probablement pas coller.

                      Ça va être pareil avec toutes les technos de ta solution. Tu fais du Windows et ils ne connaissent que Linux (ou inversement) ? ça ne va pas coller.
                      Tu fais du Java et ils ne font que du PHP ? ça ne va pas coller.
                      Tu ne connais que login/password pour l'authentification et ils ne font que du Kerberos ? ça ne va pas coller.
                      Ton appli web ne fonctionne que sur Chrome alors qu'ils sont encore sous IE 6 ? ça ne va pas coller.

                      Bien sûr, dans plein de cas (par exemple Redmine), les accès SQL seront assez simples et ça n'a pas beaucoup d'intérêt d'avoir une forte adhérence à un logiciel en particulier. Pour contre, quand ça a un intérêt, je ne vois pas pourquoi il faudrait s'en passer.
                      Que dire d'ailleurs de Cassandra, MongoDB, … ? Pour le coup, ils ne sont absolument pas remplaçables.

                • [^] # Re: Facile!

                  Posté par . Évalué à 5.

                  D'abord, je veux te rassurer : tu n'es pas en rupture avec ta philosophie "non aux procédures stockées" ; en fait de mon expérience c'est plutôt la masse qui sort de l'école d'ingénieur qui pense comme toi.

                  Sur ces individus, je les classifie in fine en deux catégories.

                  1) Ceux qui n'ont jamais eu à vivre la V2 ou la V3 des projets sur lesquels ils bossaient. Eux continuent de penser que les procédures stockées, c'est une émanation de l'enfer qu'il faut proscrire pour toujours.

                  2) Les autres, qui ont fini par s'en servir lorsque cela faisait du sens.

                  J'ai vu des énormes projets (i.e. > 10 mio €, au moins étalés sur 3 ans) partir avec une équipe d'architectes, pleins de bonnes intentions, choisir tous les frameworks, écrire les briques manquantes, faire une V1. Puis se rendre compte que finalement, il leur fallait 4 dataservers Oracle, du Dataguard, et une dizaine de serveurs Weblogic pour intégrer les 300,000 instructions à traiter quotidiennement.

                  Deux ans plus tard, sur le même projet, au moins un gros traitement sur deux a été écrit (ou réécrit) en procédure stockée.
                  A l'inverse, j'ai vu des applications gérant les mêmes volumes, s'orienter directement vers de la procédure stockée pour les morceaux impliquant des grands jeux de données, se contenter d'un serveur de données banal, un serveur d'application, et traiter les même volumes sans sourciller.

                  Par ailleurs, il y a un point important que tu peux considérer. Si tu utilises du Java ou du C# (le grand classique dans les grosses organisations), ton application est en fait un gros package qui contient une grosse quantité de code. Et quand tu dois livrer en production, pas question de livrer juste la classe que tu as touché ; non, tu dois livrer la totalité. Et passer par tout un processus, bien lourd, bien chiant, et bien risqué.

                  Par contre, toute la couche en base de données, pour livrer un correctif, tu peux relivrer juste ta procédure stockée.

                  Oui, on peut livrer à chaud une classe dans n'importe quel serveur d'app, ou même un conteneur de servlet à la Tomcat. Mais c'est juste généralement pas autorisé ; ou pas fiable (mon dieu, le nombre de fois où j'ai vu en dev mon jboss merder à la suite d'un changement de classe).

                  Dans les mêmes organisations, tu peux relivrer une unique procédure stockée sans toute cette lourdeur. Et paf, la procédure stockée te permet une agilité dont tu ne peux même pas rêver sur la couche Java/C#.

                  • [^] # Re: Facile!

                    Posté par . Évalué à 3.

                    Si ça t'intéresse, je me permet d'ajouter un lien qui montre que je ne suis pas le seul à avoir rencontré ce genre de problème :
                    http://blog.xebia.fr/2016/03/16/perennisez-votre-metier-avec-larchitecture-hexagonale/

                    Sans même aller jusqu'à la description de l'architecture, l'introduction présent exactement les problèmes que j'ai décris plus haut.

                    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                    • [^] # Re: Facile!

                      Posté par (page perso) . Évalué à 2.

                      Article intéressant :) Néanmoins, un article biaisé (en même temps, ils vendent leur service, on ne peut donc pas leur en vouloir).

                      Pourquoi biaisé ? Reprenons, pour faire simple, la conclusion de l'article, et la raison d'être de l'architecture hexagonale, à savoir répondre aux 3 constats suivants :
                      1) des choix techniques précipités ;
                      2) un immobilisme technique ;
                      3) une faible testabilité de la logique métier.

                      Pour le 1), l'architecture hexagonale ne permet pas de s'éviter un (mauvais) choix techniques précipités, mais en limite les conséquences, puisqu'il est plus facile de changer un choix a posteriori. Quoiqu'il en soit, ceci n'est un problème que si le choix initial est mauvais

                      Pour le 2), il est lié au 1). C'est un problème uniquement si le choix initial est mauvais.

                      Pour le 3), je veux bien des explications. Que les tests ne se déroulent pas de la même manière, je le conçois. Que cela soit "moins testable"…

                      Et pour reprendre les "points forts" de cette méthode :
                      A) une testabilité du métier accrue ;
                      B) une pérenisation du métier face aux changements techniques ;
                      C) une capacité à livrer de la valeur rapidement.

                      Pour le A, cf le 1.

                      Pour le B, le problème ne se pose que si il y a un besoin de changement. Cela n'arrive pas tous les jours, et si le choix a été bien fait, il ne se pose simplement pas.

                      Pour le C, rien à voir. Au contraire, j'aurais plutôt tendance à dire que cela ralenti les livraisons !

                      Ensuite, cette "solution miracle" (elle apparait comme telle dans l'article) à un coût qui est totalement passé sous silence :
                      - un coût financier tout d'abord, par le temps supplémentaire nécessaire pour les développements ;
                      - un coût technique, dû au surcoût (processeur, ram, etc…) lié à l'utilisation massive d'adapteurs.

                      Là où je pense que cette approche est pertinente, c'est lorsqu'il y a une multiplication des acteurs en jeu dans un projet fortement modulaire (par exemple un ERP).

                      • [^] # Re: Facile!

                        Posté par . Évalué à 3. Dernière modification le 16/03/16 à 14:44.

                        Tu pars d'une hypothèse « j'ai fais un bon choix dès le départ » et je ne vois pas comment tu peux l'affirmer.

                        Je peux ajouter d'autres ressources de gens qui affirment la même chose : https://www.thoughtworks.com/talks/agile-architecture-rethink-2014 et qui ne font pas parti d'une SS2I (Martin Fowler c'est déjà un peu plus respectable ?)

                        Pour le 3), je veux bien des explications. Que les tests ne se déroulent pas de la même manière, je le conçois. Que cela soit "moins testable"…

                        Je l'ai déjà dis, l'article redis la même chose presque mot pour mot (je ne travail pas chez Xebia) : t'a boucle de feedback est grande, tes tests sont longs (à écrire comme à exécuter), t'a donc tendance à en faire moins,… Je vais pas redire encore une fois tout le tralala. Les tests d'intégration n'ont pas la même complétude que les tests unitaires.

                        Une expérience qui peut être intéressante est de faire du DDD. C'est de ce que je connais la manière la plus efficace de tester la logique métier.

                        Pour le 2), il est lié au 1). C'est un problème uniquement si le choix initial est mauvais.

                        Pas forcément. Ton logiciel évolue ces contraintes aussi donc les technologies que tu utilise n'ont plus forcément la même pertinence. Même sans changer de technologie, ta techno sous-jacente peut évoluer et ce que tu faisais d'une manière à une époque peut avoir était déprécié 5 ans plus tard.

                        Pour le C, rien à voir. Au contraire, j'aurais plutôt tendance à dire que cela ralenti les livraisons !

                        Avoir plus de tests et un feedback rapide, ça ralenti ?

                        un coût financier tout d'abord, par le temps supplémentaire nécessaire pour les développements ;

                        1. je suis pas certains que ça prenne plus de temps
                        2. tu maîtrise mieux ton langage de base que le langage de ton bd (tu écris plus de code avec le premier)
                        3. tu as une boucle de feedback plus rapide (test unitaire vs test d'intégration) donc ça te fais aller plus vite

                        un coût technique, dû au surcoût (processeur, ram, etc…) lié à l'utilisation massive d'adapteurs

                        C'est le choix de la bonne abstraction. Je serais joueur, je t'expliquerais que tu choisi la bonne abstraction au départ et donc que ça va (c'est comme choisir des techno). Comme je ne le suis pas je te dirais qu'avoir des abstractions dirigés par ton besoin métier est vraiment intéressant, parce que la taille de ton adaptateur va dépendre de la pertinence de ta techno sous-jacente. Ça te donne un élément très utile sur comment choisir tes technologies.

                        Je suis tout à fait d'accord ce n'est pas une solution miracle, mais c'est une solution intéressante.

                        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                        • [^] # Re: Facile!

                          Posté par (page perso) . Évalué à 2.

                          Tu pars d'une hypothèse « j'ai fais un bon choix dès le départ » et je ne vois pas comment tu peux l'affirmer.

                          Tu te trompes. Je ne fais pas cette affirmation. Je réponds à la tienne (il faut pouvoir changer), sous-entendant donc que le choix initial est mauvais.

                          Je peux ajouter d'autres ressources de gens qui affirment la même chose : https://www.thoughtworks.com/talks/agile-architecture-rethink-2014 et qui ne font pas parti d'une SS2I (Martin Fowler c'est déjà un peu plus respectable ?)

                          Sans vouloir être offensant : c'est qui Martin Fowler ?

                          Je l'ai déjà dis, l'article redis la même chose presque mot pour mot (je ne travail pas chez Xebia) : t'a boucle de feedback est grande, tes tests sont longs (à écrire comme à exécuter), t'a donc tendance à en faire moins,… Je vais pas redire encore une fois tout le tralala. Les tests d'intégration n'ont pas la même complétude que les tests unitaires.

                          Les tests sont long a exécuter. Oui c'est vrai. A écrire non, car tu aurais du écrire les mêmes de toutes façons. Les tests unitaires n'ont jamais remplacé les tests d'intégration. Et avec les outils qu'on a aujourd'hui, si les tests sont vraiment long et que tu ne veux/peux pas les lancer à chaque fois que tu fais une modification mineur, on peut les faire tourner la nuit. Et tu n'es pas non plus obligé de lancer tous les tests à chaque fois.

                          Pas forcément. Ton logiciel évolue ces contraintes aussi donc les technologies que tu utilise n'ont plus forcément la même pertinence.

                          Et ça ça fait toujours parti des premières conversations que j'ai avec mes clients. Les évolutions, les besoins futurs, etc… Il faut anticiper au maximum. Et je laisse toujours le choix aux clients, c'est eux qui ont le dernier mot. Je présente plusieurs solutions : la "rapide" pas évolutive à la moins rapide (donc plus cher), mais évolutive. Parfois c'est l'un, parfois c'est l'autre.

                          Ca ne garanti pas que le choix est toujours bon. Mais cela restera le choix du client. De mon côté, j'aurais tenu mon rôle de conseiller. Et ça m'est déjà arrivé d'avoir un client qui revient sur ses décisions initiales. Ben au final, ça c'est mal passé (pour un client lourd, on est passé d'"une solution on s'en fou de l'IHM, il faut que se soit fonctionnelle et que tous les postes voient les répercutions en temps réel" à "l'IHM est primordiale, et tant pis si l'information n'est pas partagé en temps réel entre les postes".

                          Mais là, même avec une bonne architecture au départ, n'importe qui aurait eu des soucis.

                          Avoir plus de tests et un feedback rapide, ça ralenti ?

                          Avoir plus de tests, oui. Il faut les écrire !

                          je suis pas certains que ça prenne plus de temps
                          tu maîtrise mieux ton langage de base que le langage de ton bd (tu écris plus de code avec le premier)
                          tu as une boucle de feedback plus rapide (test unitaire vs test d'intégration) donc ça te fais aller plus vite

                          D'une part, tu as plus de code à écrire. D'autre part, il y a un effort de découplage à faire. Et ça, ça peut prendre du temps ;)
                          Pour le langage, ce n'est pas parce que tu n'en as qu'un seul de base que tu vas mieux le maitriser que si tu en avais deux.
                          Et pour ma part, les feedbacks, ce ne sont pas les tests qui me les donnent, mais les utilisateurs.

                          Comme je ne le suis pas je te dirais qu'avoir des abstractions dirigés par ton besoin métier est vraiment intéressant, parce que la taille de ton adaptateur va dépendre de la pertinence de ta techno sous-jacente. Ça te donne un élément très utile sur comment choisir tes technologies.

                          Sauf que tu fais tout cela justement pour ne pas être lié à une technologie sous-jacente. Ainsi, ton choix (pertinent) d'aujourd'hui peut être une véritable plaie quand tu devras changer de techno demain.

                          Je suis tout à fait d'accord ce n'est pas une solution miracle, mais c'est une solution intéressante.

                          Et je n'ai jamais dis le contraire ;)

                          • [^] # Re: Facile!

                            Posté par . Évalué à 3.

                            Tu te trompes. Je ne fais pas cette affirmation. Je réponds à la tienne (il faut pouvoir changer), sous-entendant donc que le choix initial est mauvais.

                            Non, un bon choix à un moment donné n'a pas de raison de le rester.

                            Les tests unitaires n'ont jamais remplacé les tests d'intégration.

                            Oui mais c'est précisément l'inverse dont il est question : tester du fonctionnel via des tests d'intégration. Les tests d'intégrations sont longs par nature, c'est pour cela qu'ils couvrent moins (et aussi parce qu'ils font exploser la combinatoire).

                            Je ne dis pas qu'il ne faut pas faire de test d'intégration, je dis que c'est dommageable d'essayer de tester le métier par des tests d'intégration.

                            Il faut anticiper au maximum.

                            C'est un bon moyen de se planter. Parce que je doute que tu sois meilleur devint que moi. Ton client non plus, lui refourguer cette responsabilité ne change rien au problème (ça change juste la responsabilité). C'est le principe même de l'over-engenering imaginer beaucoup et surtout beaucoup trop.

                            Au contraire réduire ton scope de décision au minimum et remettre à plus tard tout ce qui peut l'être jusqu'à être assez mûre pour choisir. Ce que tu propose est typiquement le cycle en V dans le quel les erreurs sont très chères ! (à tous point de vu)

                            Avoir plus de tests, oui. Il faut les écrire !

                            Ça dépend de ce que tu entends par livrer. Si on entend par là, la livraison où l'utilisateur est satisfait de sa fonctionnalité, les tests ne coûtent rien. Ils ne coûtent rien face au temps que te coûte un bug dans la livraison et que la perte de confiance de l'utilisateur envers ton logiciel.

                            Et pour ma part, les feedbacks, ce ne sont pas les tests qui me les donnent, mais les utilisateurs.

                            Ça n'a rien avoir. Il s'agit lors de ton développement du temps que tu as entre l'écriture d'une ligne et la vérification qu'elle fait ce que veux. C'est le cycle (dans la majorité des cas) :

                            1. écriture
                            2. compilation
                            3. exécution
                            4. retour à l'étape 1

                            Si ton exécution c'est des tests, tu vérifie plus rapide l'ensemble de test cas que. Si tu le fais manuellement, tu n'aura tendance à vérifier que le cas que tu es entrain de traiter (en oubliant éventuellement les cas qui sont impactés) et tu perd du temps à revenir dans l'état qui te correspond. Si tu attends que le client t'envoie un mail, euh… comment dire… :)

                            Sauf que tu fais tout cela justement pour ne pas être lié à une technologie sous-jacente. Ainsi, ton choix (pertinent) d'aujourd'hui peut être une véritable plaie quand tu devras changer de techno demain.

                            Ton métier évolue généralement peu. L'abstraction devrait donc rester pertinente. Cette abstraction n'est pas quelque chose qui est artificiel, elle est dépendante de ton métier. Donc elle ne doit pas être remise en cause par la technologie, mais par le métier (c'est l'idée à travers l'inversion de dépendance). Si ça devient une plaie, c'est soit que tu as mal conçu ton abstraction (ça arrive) soit que tu dois remettre en cause ta techno.

                            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                            • [^] # Re: Facile!

                              Posté par (page perso) . Évalué à 2.

                              Non, un bon choix à un moment donné n'a pas de raison de le rester.

                              Ahhh, enfin ! Depuis le temps que je l'attendais cette réponse :) Un choix est (enfin peut être !) pertinent dans un contexte donné. Ce n'est effectivement pas parce qu'il était bon début qu'il le restera. Si le contexte change… la pertinence de ce choix peut s'en trouver affecté.

                              Oui mais c'est précisément l'inverse dont il est question : tester du fonctionnel via des tests d'intégration. Les tests d'intégrations sont longs par nature, c'est pour cela qu'ils couvrent moins (et aussi parce qu'ils font exploser la combinatoire).

                              Que les tests soient long à cause de la bd qu'il faut mettre dans un état cohérent avant chaque test, c'est un fait (un test peut prendre quelques secondes). Dire qu'ils couvrent moins… avec explosion de la combinatoire… je crois simplement que nous ne sommes pas en train de parler de la même chose. Quand je dis test d'intégration pour tester ma couche métier, je teste l'API de ma couche métier. Pas l'IHM (on est bien d'accord sur ce point ?). Je n'emploi pas le terme "test unitaire" puisque ma couche métier est fortement couplée à la couche de persistence et que j'ai bien compris dans une autre discussion que ce n'était pas unitaire pour toi.

                              C'est un bon moyen de se planter. Parce que je doute que tu sois meilleur devint que moi. Ton client non plus, lui refourguer cette responsabilité ne change rien au problème (ça change juste la responsabilité). C'est le principe même de l'over-engenering imaginer beaucoup et surtout beaucoup trop.

                              Effectivement, je ne suis pas devin. Je vais le dire autrement, cela expliquera mieux ma pensée. Tu as un client, qui veut un logiciel est les modules X, Y et Z (qui ne sont pas indépendant). Dans le temps, tu vas livrer d'abord X, puis 3 mois après Y, et 6 mois après Z. Là où je parle d'anticipation, c'est qu'on connait déjà les besoins. Du coup, si pour implémenter Z, j'ai besoin de revenir sur X, j'essai, dès la réalisation de X, de tenir compte des besoins pour Z.

                              Au contraire réduire ton scope de décision au minimum et remettre à plus tard tout ce qui peut l'être jusqu'à être assez mûre pour choisir. Ce que tu propose est typiquement le cycle en V dans le quel les erreurs sont très chères ! (à tous point de vu)

                              Pas du tout. Ce n'est pas le cycle en V. C'est plutôt une méthode Agile dans la mesure où le client est présent tout du long du processus. Il a une version de test (buggué !) mais valide / invalide très tôt la manière dont les choses se présentent à lui. Cela me permet d'avoir une très bonne réactivité et d'éviter de lui fournir un livrable ne correspondant pas à ses besoins (initiaux, ou parce qu'ils auront changés entre temps, car il se sera rendu compte que ce qu'il pensait être bien en théorie ne l'est pas en pratique par exemple).

                              Ton métier évolue généralement peu. L'abstraction devrait donc rester pertinente. Cette abstraction n'est pas quelque chose qui est artificiel, elle est dépendante de ton métier. Donc elle ne doit pas être remise en cause par la technologie, mais par le métier (c'est l'idée à travers l'inversion de dépendance). Si ça devient une plaie, c'est soit que tu as mal conçu ton abstraction (ça arrive) soit que tu dois remettre en cause ta techno.

                              Le métier évolue généralement peu. On est d'accord. Je réagissais sur ces propos "la taille de ton adaptateur va dépendre de la pertinence de ta techno sous-jacente". Si à un instant donné, l'adaptateur peut être bien conçu (bonne synergie entre le métier et les techno) cela ne sera pas forcément le cas par la suite (et tu le disais toi même plus haut dans ton commentaire "Non, un bon choix à un moment donné n'a pas de raison de le rester.").

                              • [^] # Re: Facile!

                                Posté par . Évalué à 3.

                                avec explosion de la combinatoire… je crois simplement que nous ne sommes pas en train de parler de la même chose.

                                Explosion est peut être fort, mais je suis même pas sûr. Parce que tu va aussi devoir tester l'intéraction entre un bout de ton code métier (celui de la procédure stockée avec le reste du code métier). Un cas d'usage peu impliquer tes 2 parties par exemple.

                                Effectivement, je ne suis pas devin. Je vais le dire autrement, cela expliquera mieux ma pensée.

                                L'idée ce n'est pas d'anticiper, c'est de ne pas se fermer des portes (c'est différent). C'est différent. On ne fait pas quelque chose parce qu'on sait que dans 6 mois il y aura X, on le fait parce qu'il y aura X, X', X" ou rien du tout. On présume le moins possible de ce que sera X et de ce qu'il impliquera, parce que les besoins peuvent changer beaucoup trop entre temps.

                                C'est plutôt une méthode Agile dans la mesure où le client est présent tout du long du processus.

                                (Au passage Martin Fowler est l'un des co-auteur du manifeste agile)
                                Les méthodes agiles expliquent clairement que ton scope correspond à une itération et que tu n'a pas à hésiter à refactorer profondément ton code. Ton scope ce n'est pas un contrat de 18 mois, mais une itération d'un mois par exemple.

                                Si à un instant donné, l'adaptateur peut être bien conçu (bonne synergie entre le métier et les techno) cela ne sera pas forcément le cas par la suite (et tu le disais toi même plus haut dans ton commentaire "Non, un bon choix à un moment donné n'a pas de raison de le rester.").

                                Le job ça va être de trouver la techno qui permet de réduire cette glue, mais tu ne fais pas ça rien. As toi de mettre en balance ce que ça va t'apporter par rapport à ce que ça te coûte (mais ça ne te demande pas de revalider le métier c'est déjà pas mal :) ).

                                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                                • [^] # Re: Facile!

                                  Posté par . Évalué à 2.

                                  Désolé de me (ré)insérer dans cette discussion.

                                  Tu pars du principe (fort louable) que les tests unitaires/d'intégration sont bien faits, bien maintenus, etc.

                                  De tous les projets que j'ai vu, on a cette approche sur les 6 à 12 premiers d'un projet. Puis ça part en sucette. Pas toujours, certes. Mais très souvent. Dès que la pression commence à monter.

                                  Ce qui fait qu'hélas, l'argument "c'est plus facile à tester" perd beaucoup de sa superbe face à "c'est plus facile à livrer en production".

                                  Maintenant, si sur les projets que tu as vu, la couverture de test reste une priorité sans limite de temps, j'applaudis des deux mains et je te souhaite tout le bonheur du monde. Mais vraiment, c'est pas ce que j'ai vu jusqu'ici, et des projets, j'en vois passer beaucoup (environ 30 nouveaux projets par an dans le secteur bancaire, aux alentours de 15 000 jours/homme).

                                  • [^] # Re: Facile!

                                    Posté par . Évalué à 4.

                                    Ce qui fait qu'hélas, l'argument "c'est plus facile à tester" perd beaucoup de sa superbe face à "c'est plus facile à livrer en production".

                                    Je ne suis pas d'accord et je me battrais avec mon chef de projet pour que ce ne soit pas le cas.

                                    Je ne connais pas de projet qui soit à plus de 80% de couverture, mais ça n'empêche pas que s'empêcher de tester son code ne me semble pas du tout être une bonne idée. Classiquement l'équipe de dev sait quel partie est correctement testée et la quelle ne l'est pas et c'est systématiquement quand il y a des tests que les évolutions sont plus rapide. Je ne fais presque plus de refactoring, sans avoir créer de test de cette partie. D’expérience ça crée beaucoup trop facilement de bug autrement.

                                    "c'est plus facile à livrer en production"

                                    Je n'ai pas encore réagi à ça, mais c'est vraiment problème d'organisation plus que d'architecture. Tu bousille tes données aussi bien avec l'un qu'avec l'autre, utiliser cette différence, c'est juste jouer sur l'incompétence de ton client. Il y a des millions de façons pour réduire le temps de mise en production. Il n'y a que la politique comme goulot d'étranglement et pour faire face à ça, je joue sur 2 plans :

                                    • améliorer la confiance en montrant la qualité des tests effectués ;
                                    • modifier la responsabilité en montrant que le problème/bug qu'ils ont en prod est corrigé depuis N temps de notre coté et que la balle n'est plus dans notre camps, qu'il n'est pas besoin de nous en reparler tant qu'ils n'ont pas fait de mise à niveau. Sur le long terme mettre en évidence les temps de cycle, ça a était payant.

                                    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                                    • [^] # Re: Facile!

                                      Posté par . Évalué à 2.

                                      Je pense qu'on est effectivement pas dans le même monde, et ce n'est pas du tout péjoratif : en fait je t'envie.

                                      modifier la responsabilité en montrant que le problème/bug qu'ils ont en prod est corrigé depuis N temps de notre coté et que la balle n'est plus dans notre camps, qu'il n'est pas besoin de nous en reparler tant qu'ils n'ont pas fait de mise à niveau. Sur le long terme mettre en évidence les temps de cycle, ça a était payant.

                                      J'ai d'un côté mon "client" (le métier sponsor de l'application et demandeur d'évolutions) qui voudrait que tout aille très vite, donne son accord à tout pourvu que la réactivité soti là, et de l'autre ma production informatique (typiquement une filiale du groupe dédiée à l'exploitation informatique) qui est accrochée à ses procédures, son respect idéologique à ITIL et surtout à son implémentation locale.

                                      Quand j'ai un bug fonctionnel, que je peux corriger rapidement parce qu'il est dans une procédure stockée, je peux faire la modification et ne livrer que cette procédure stockée. Une fois que le fix est testé, je peux faire une demande de livraison pour ce morceau uniquement, pour lequel on va me donner un accès (temporaire) à la base de production. Je livre vite, mon client est content. Ma production informatique, elle, s'en fout : le périmètre du changement est maîtrisé donc le risque est faible.

                                      Si il est dans la couche Java/JSP/Javascript/… je dois relivrer un EAR complet. Là, c'est l'artillerie lourde, je fais une demande, elle sera prise en compte sous une semaine. Je n'ai pas et je n'aurais jamais accès à la machine hébergeant mon serveur d'app, donc je suis totalement dépendant de ma production pour ça. En fonction de la modification, si en plus il y a un changement de structure de base, je suis obligé d'arrêter l'application, et donc le service, en pleine journée ou attendre le week-end (oui, nos applications tournent 24/5). Par défaut, on ne peut pas arrêter nos applications plus de 15 minutes en journée, sinon les pertes financières peuvent être abyssales.

                                      Je peux montrer tous les tests de la terre, un zoli écran Sonar montrant ma couverture de test unitaire (j'essaye d'être au moins à 50%), mes tests automatiques (un automate simulateur de flux d'entrée/sortie), mon respect des règles de codage, etc. Ca ne change rien ; ma production s'en fout, s'en est toujours foutue et continuera ainsi bien après ma retraite.

                                      Le seul cas où je peux accélérer les choses, c'est en cas d'incident majeur, mais auquel cas je dois justifier de la gravité et de l'impact, faire une escalade hiérarchique pour obtenir 2 ou 3 tampons. Autant dire que si je fais ça trop souvent, je peux mettre tout de suite un terme à ma carrière et partir élever des chèvres dans le Larzac. Donc c'est réservé à la résolution d'incident avec impact, pas juste pour faire plaisir à mon client. Et c'est pensé pour être comme ça, ce n'est pas un effet collatéral.

                                      • [^] # Re: Facile!

                                        Posté par . Évalué à 4.

                                        Ce genre de découpage (que j'ai connu en moins violent dans un sens parce que ce n'était pas ma boite qui faisait l'IT) est juste une abomination (c'est pas contre toi, hein ?). J'ai passé un temps assez insensé à expliquer à des gens dont le boulot consiste à ne pas faire tourner ton application comment l'installer. Outre les temps de cycles incroyables, ça génère énormément d'erreur de la part des exploitants (je pense que tous les exploitants que j'ai rencontré n'avaient rien à faire de comprendre ce qu'ils faisaient).

                                        (je continue de parler de ceux que j'ai rencontré) ceux qui s'occupent de ça ne veulent aucun changement. Ça se protège derrière l'ITIL, mais l'automatisation à la chef/pupet/ansible ils en veulent pas, alors des concepts comme les infrastructures immutables tu te doute bien que ça les dépasse de plusieurs magnitudes.

                                        Si j'avais à revivre ça ce serait pour 3 mois maximum… Je suis jeune je n'ai pas d'engagement, d'attache ou autre. Le marché du travail est florissant. J'ai pas envie de me fader des gens dont le seul but est de m'empêcher de faire mon boulot. Je ne fais pas assez de yoga/tai chi pour endurer ça sereinement :)

                                        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                                    • [^] # Re: Facile!

                                      Posté par (page perso) . Évalué à 2.

                                      Je ne connais pas de projet qui soit à plus de 80% de couverture, mais ça n'empêche pas que s'empêcher de tester son code ne me semble pas du tout être une bonne idée.

                                      Là où un peu de pédagogie est nécessaire est certainement qu'il faut bien expliquer qu'une partie de test et de mise au point est inévitable. Ceci étant quel statut donner à ce travail? Faut-il se contenter des résultats immédiats (ça marche, on livre) et oublier le reste du travail fait ou bien faut-il le sauvegarder, l'incarner, dans des artefacts sous contrôle de version, des tests automatiques? En plus des bénéfices que tu soulignes qui se révèlent payants sur le long terme, souligner que c'est un travail qui va de toute façon être fait et que la vraie question est s'il faut l'organiser pour l'automatiser ou juste l'oublier est un argument qui “touche” parfois.

                                  • [^] # Re: Facile!

                                    Posté par . Évalué à 3.

                                    on a cette approche sur les 6 à 12 premiers d'un projet

                                    Mon optimisme espère que le mot manquant est "mois", mon réalisme tend à croire que c'est en fait "jours"…

                                    • [^] # Re: Facile!

                                      Posté par . Évalué à 2.

                                      Je pensais à "mois", mais je suis certain qu'il est déjà arrivé que ce soit "jours". De toute manière, c'est dès que la pression monte et qu'on commence à bosser dans l'urgence.

          • [^] # Re: Facile!

            Posté par (page perso) . Évalué à 2.

            Quelque soit le SGBDR, le mec qui me dit qu'il faut faire de la procédure stockée, mérite d'être pendu haut et court.

            Là, je pense qu'un bon argumentaire serait le bienvenu, même si on est pas trolldi matin…

            * Ils vendront Usenet^W les boites noires quand on aura fini de les remplir.

        • [^] # Re: Facile!

          Posté par (page perso) . Évalué à 3.

          BULLSHIT ! PostgreSQL sait très bien charger un dump d'une version antérieure dans la toute dernière version.
          Encore faut-il savoir utiliser correctement PostgreSQL.
          Que tu aimes ton SQLServer ; OK, mais merci de ne pas parler de ce que tu ne connais pas.

          Salutations,

          Un DBA PostgreSQL heureux.

          • [^] # Re: Facile!

            Posté par (page perso) . Évalué à 0.

            BULLSHIT ! PostgreSQL sait très bien charger un dump d'une version antérieure dans la toute dernière version.
            Encore faut-il savoir utiliser correctement PostgreSQL.
            Que tu aimes ton SQLServer ; OK, mais merci de ne pas parler de ce que tu ne connais pas.

            C'est bien, tu te permets de me juger, sans même me connaître. Félicitation.

            Je fais un retour d'expérience. Qu'il ne te plaise pas parce qu'il "dénature" TON SGBD favori, c'est ton problème, pas le miens. Avant, j'étais pour du Postgresql. Au bout d'un moment, j'ai fini par tester SQL Server (j'admet). Avec du recul, je préfère SQL Server (c'est mon choix et j'assume).

            • [^] # Re: Facile!

              Posté par (page perso) . Évalué à 0. Dernière modification le 08/03/16 à 17:41.

              C'est bien, tu critiques un outil que tu ne maitrises pas, félicitations !
              A aucun moment je ne te juge, je dis juste que TU juges un SGBD sur une manip non décrite que tu ne semble pas maitriser pour en sortir une conclusion absurde. Donc, oui, tu dénature MON SGBD.
              Et je te confirme, j'utilise PostgreSQL depuis très très longtemps et pas en mode bidouilleur : c'est mon métier.
              Pour moi, tes propos sont juste : BULLSHIT !

              merci de ton attention et bonne route avec ton choix que tu assumes.

              • [^] # Re: Facile!

                Posté par (page perso) . Évalué à 0.

                On n’est pas obligé d’être grossier. Il y a des gens qui moinssent pour ça, qu’on ait raison ou tord d’ailleurs. :-)

                ce commentaire est sous licence cc by 4 et précédentes

                • [^] # Re: Facile!

                  Posté par . Évalué à 7.

                  Sur DLFP, les grossièretés sont moinssées, mais le tord tue.

                  • [^] # Re: Facile!

                    Posté par (page perso) . Évalué à 1.

                    Je t’ai plussé ! /o\

                    ce commentaire est sous licence cc by 4 et précédentes

                  • [^] # Re: Facile!

                    Posté par . Évalué à 1.

                    Non !
                    Sur DLFP:
                    On torD le français à torT et à travers.
                    On tourne en rond comme un torE
                    et on se met des torRs de pression.

                • [^] # Re: Facile!

                  Posté par (page perso) . Évalué à -3.

                  Bullshit c'est grossier ? je ne savais pas : je ne parle pas anglais :)
                  je présente donc mes excuses à bull et shit …

              • [^] # Re: Facile!

                Posté par (page perso) . Évalué à 2.

                C'est bien, tu critiques un outil que tu ne maitrises pas, félicitations !

                Tu pars du principe que j'ai fait ça dans mon coin en bidouillant et hop. Ben non. c'est vrai, je ne suis pas admin bd (c'est pas mon boulot). Mais je l'ai utilisé bien longtemps (plusieurs années). Et quand ce gros problème est survenu, on a fait appelle à un vrai admin bd (ben il s'est cassé les dents aussi).

                La procédure non décrite ? Elle est très simple :
                - création du dump (généré quotidiennement par un cron) : pg_dump -Fc ma_db > backup.bak
                - restauration : pg_restore -Fc backup.bak

                La restauration générait des erreurs. Il a fallu réinstaller la même version de postgresql, générer un dump textuel (à base de requête sql donc), modifier 1 truc ou 2 (là, je ne sais plus, c'est l'expert mandaté qui l'a fait), pour ensuite pouvoir le réimporter dans une version plus récente.

                Tu veux un autre exemple ? Dans le laboratoire où j'ai fait ma thèse, il y a un projet sur des ontologies qui est développé et qui utilise Postgresql. La première version du projet est resté bloquée en 8.4 pour cause d'incompatibilité avec des versions supérieures de Postgresql. Des tests unitaires sont passés dans le rouge. C'est moche, mais je n'ai rien inventé.

                Et quand je fais le bilan, que ce soit moi personnellement ou ceux de mes collègues, le bilan est : on a eu beaucoup moins de soucis avec SQL Server qu'avec Postgresql (et pourtant, on n'utilise pas de choses compliquées comme des fermes de serveur, de la réplication de données, etc…).

                Je ne dis pas que postgresql est un mauvais SGBD. Je dis qu'il n'est pas parfait. La restauration d'un dump est quelque chose qui devrait marcher tout le temps, j'ai vécu une situation où ce n'était pas le cas. J'ai déjà vu des problèmes d'incompatibilités suite à une nouvelle version qui oblige à modifier l'application l'utilisant.

                On a testé SQL Server, et jusqu'à présent, nous n'avons pas eu à souffrir de cela. Lorsque je dois conseiller une solution pérenne pour mes clients, je choisi SQL Server (et pourtant, j'apprécie énormément le libre). SQL Server a lui aussi ses défauts (pas de CREATE TABLE IF EXISTS, ou encore pas de support natives des regex pour n'en citer que deux) et n'est pas parfait non plus. Mais d'après mon expérience, il est plus pérenne. Et c'est le point important pour mes clients.

                Mais comme tu es un expert dans ton domaine, forcément, ce que je dis, c'est des conneries.

                • [^] # Re: Facile!

                  Posté par (page perso) . Évalué à -1.

                  OK, pas de problème !
                  Tu m'expliques juste que les dump de PostgreSQL ne sont pas restaurables et si c'est vrais : c'est un BUG majeur qu'il faut remonter.
                  Je n'ai jamais vu ce cas et pourtant je passe ma vie à coller des dump d'une version à une autre sans aucun problème.
                  Bref … je suis heureux que tu sois heureux avec ton nouvel ami, mais je ne peux pas te laisser dire que PostgreSQL ne sait pas restaurer un dump.
                  En te souhaitant une très bonne journée et une vie plein de bonheur

                  • [^] # Re: Facile!

                    Posté par (page perso) . Évalué à 2.

                    je ne peux pas te laisser dire que PostgreSQL ne sait pas restaurer un dump.

                    Surtout que je n'ai pas dis cela. J'ai dis que j'avais eu UNE fois un problème avec UN dump, qui n'était pas restaurable sur une version ultérieure (mais sur la même, oui). C'est quand même très différent de ce que veux me faire dire (les dumps ne sont pas restaurable) !

                    • [^] # Re: Facile!

                      Posté par (page perso) . Évalué à 4.

                      la pérénité des dumps et la compatibilité descendante (aucun soucis pour charger un dump de SQL Server 2005 sur un SQL Server 2012). Faite la même chose avec un postgresql par exemple… pas sur que cela se fasse sans heurt (avant qu'on me dise que je raconte des cracks : malheureusement testé et approuvé :'( )

                      Heu, c'est pas une façon de généraliser ça ?

                      • [^] # Re: Facile!

                        Posté par (page perso) . Évalué à 0.

                        Si tu y vois une généralisation, c'est un problème de communication. Ce n'était pas du tout ce que je voulais dire ;)

                        La suite de la phrase est d'ailleurs importante pour cela : pas sur que cela se fasse sans heurt (en référence aux deux problèmes mentionnés plus haut). Mon intention aurait été de généraliser que j'aurais plutôt dit "cela ne se fera pas sans heurt".

                      • [^] # Re: Facile!

                        Posté par . Évalué à 2.

                        Ben il a eu UNE fois le probleme donc forcement c'est la faute a PostgreSQL et cela demontre bien que le logiciel libre c'est de la merde.

                        • [^] # Re: Facile!

                          Posté par (page perso) . Évalué à 2.

                          je te plussois en partant du principe que c'est ironique ! :)

                          • [^] # Re: Facile!

                            Posté par (page perso) . Évalué à 3.

                            Là il est ironique mais le souci avec Albert_< c'est qu'en général il dit ça au premier degré mais concernant un produit Microsoft. C'est de l'autodérision involontaire.

      • [^] # Re: Facile!

        Posté par (page perso) . Évalué à 7.

        Quand on est coincé pour des raisons historiques/techniques/politiques avec une base MSSQL server, je vois tout de même un certain nombre d'avantages à passer sous linux… l'automatisation, l'administration, stabilité, capacité a utiliser les grands cloud publics, le cout de l'OS, etc
        Ou juste pour tenir le temps d'une migration vers une autre techno par exemple ?

        Et puis ça fait jamais de mal d'avoir une solution supplémentaire dispo sous linux. Ca renforce sa crédibilité (si il y en avait encore besoin) et sa pénétration.

        • [^] # Re: Facile!

          Posté par . Évalué à 2.

          je vois tout de même un certain nombre d'avantages à passer sous linux… l'automatisation, l'administration, stabilité, capacité a utiliser les grands cloud publics, le cout de l'OS, etc

          On va dire plutôt que tu y vois la possibilité d'utiliser un OS que tu connais plutôt qu'un OS dont tu connais si peu que tu ne sais pas qu'il est stable, totalement automatisable, présent sur tous les clouds grand public …

          • [^] # Re: Facile!

            Posté par . Évalué à 4.

            Mouais, c'est un peu comme les mecs qui essayent de te fourguer du freebsd parce que c'est libre, automatisable blablabla.
            Le fait est que le gros du boulot dans le monde devops se fait pour linux, et si tu veux pas pleurer en voyant "feature truc, supporte sous linux, experimental sous bsd, windows allez vous faire foutre" ajoute dans ansible/puppet/chef, tu vas pas sous windows.
            Et on peut aussi parler de la gestion des licences, que ce soit en dev ou en prod. c'est plus simple de filer une vm linux a tes ingenieurs que de sortir l'artillerie lourd parallels/vmware pour faire tourner windows (parce qe bien evidenment, tes ingenieurs sont sur des macs).

            Linuxfr, le portail francais du logiciel libre et du neo nazisme.

      • [^] # Re: Facile!

        Posté par . Évalué à 4. Dernière modification le 08/03/16 à 14:35.

        Autre chose : quel est l'intérêt de passer sous Linux pour ceux qui utilisent déjà une solution Windows/SQLServeur ? (bon, là j'ai une vague idée…)

        Je crois que ce choix de supporter linux est très orienté cloud étant donné que le choix en terme d'offres dans le nuage est à ma connaissance plus grand et plus économique en terme solutions linux que windows. J''ajouterai qu'il y'a probablement aussi un intérêt marketing à une époque où une solution qui rend un client captif de ses choix passés n'est pas très vendeuse.

  • # Sybase / SAP ASE

    Posté par (page perso) . Évalué à 5.

    MS-SQL Server est issu d’un fork (après rachat) de Sybase, qui est depuis chez SAP, et je crois que leur version tourne toujours sous différents Unix, mais je ne sais pas du tout ce que ça donne. Certains ici connaissent ?

    • [^] # Re: Sybase / SAP ASE

      Posté par . Évalué à 4.

      J'utilise ça tous les jours et ça fonctionne plutôt bien.

      Par contre, pleins de fonctionnalités sont en option (minimal logging, compression), le transac-sql (langage de procédures stockées) évolue très très très lentement. Bref, je bave devant un postgresql.

      L'autre soucis c'est que c'est tellement en perte de vitesse que le support se dégrade : plusieurs semaines pour le correctif d'un bug qui fait crasher le dataserver systématiquement…

  • # manque plus que office

    Posté par . Évalué à 3.

    J'avais toujours dit que si il n'y avait pas le moindre logiciel Microsoft dispo sur linux cela n'etait ni pour une raison de taille de marche ni une raison technique mais une raison politique.

    Voir ce genre d'annonce montre bien que linux est, malgre tous les efforts de MS et des ses afficionados, la et bien la et il ne peut plus etre ignore sous peine de perdre trop de part de marche.

    • [^] # Re: manque plus que office

      Posté par (page perso) . Évalué à 3.

      Ça commence à faire un petit bout de temps que MS ne l'ignore plus. Leur offre cloud Azure propose du linux depuis je ne sais combien de temps.

      De la bouche même du PDG en 2014 : Microsoft Aime Linux.

      • [^] # Re: manque plus que office

        Posté par . Évalué à 3.

        Il y a tout de meme une difference entre propose du linux sur un cloud et développer un logiciel pour linux. Maintenant je ne me fait pas trop d'illusions sur la disponibilité de office sous linux.

  • # Remarque de forme

    Posté par . Évalué à 9.

    Maintenant il ne reste plus qu'à attendre quelles critiques certains vont encore réussir à trouver pour se plaindre de MS […]

    C'est ce qui s'appelle renverser le sens de l'information. Pour continuer à exister de manière significative dans le monde numérique en plein chambardement, où sa domination d'antan fait plus que vaciller, Microsoft a intérêt (j'écrirais bien est forcé mais ce serait biaisé) de porter certains de ses outils sous Linux, cloud oblige. On se demande bien par quelles critiques l'accusation de constituer un cancer pourrait être remplacée. Et cette accusation de cancer n'avait pas été lancée par le pair d'un commentateur mal informé ou peu instruit et à l'expression incertaine de DLFP, mais bien par son dirigeant d'alors.

    Les choses ont bien changé. Plutôt que s'adonner à ce genre d'activités discutables, les nouveaux dirigeants préfèrent œuvrer dans l'intérêt direct de leur compagnie. Leur monde est devenu plus concurrentiel. Se frapper le torse tel un gorille serait désormais considéré comme incongru.

  • # C'est génial

    Posté par . Évalué à 8.

    J'attends impatiemment Internet Explorer sur ChromeOS.

  • # Ce que Bill Gates en pense…

    Posté par . Évalué à 4.

    • [^] # Re: Ce que Bill Gates en pense…

      Posté par . Évalué à 0.

      J'aime à croire que ça lui fait un tout petit peu mal au cul de constater qu'il n'a pas pu créer aussi un monopole dans le monde serveur et mobile.
      Dans le monde serveur, il faut croire qu'on embobine pas un professionnel de l'informatique comme on embobine un utilisateur de bureautique.
      Et dans le monde mobile, il est arrivé trop tard pour pouvoir verrouiller le marché.

      • [^] # Re: Ce que Bill Gates en pense…

        Posté par . Évalué à 4.

        Et dans le monde mobile, il est arrivé trop tard pour pouvoir verrouiller le marché.

        C'est le premier sur le marché avec PalmOS…
        Non ce n'est pas une question de timing (pour une fois chez ms), mais de capacité à sentir le marché (et dans le cas présent à comprendre qu'il fallait s'intéresser au grand public et pas uniquement aux professionnels.

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: Ce que Bill Gates en pense…

          Posté par (page perso) . Évalué à 2.

          C'est le premier sur le marché avec PalmOS…

          Gni ? Quel rapport entre Bill Gates et PalmOS ?

          * Ils vendront Usenet^W les boites noires quand on aura fini de les remplir.

          • [^] # Re: Ce que Bill Gates en pense…

            Posté par . Évalué à 2.

            À l’instar d’autres fabricants de mobiles (Danger, Nokia, etc.) ils se sont associés à Microsoft, pour en mourir brièvement après.
            Il y avait des Treo qui tournaient sous Windows Mobilbleurgh.

            Depending on the time of day, the French go either way.

          • [^] # Re: Ce que Bill Gates en pense…

            Posté par . Évalué à 3. Dernière modification le 10/03/16 à 10:20.

            Ils étaient tous les deux présents sur le marché, en concurrence, avant les acteurs actuels. PocketPC vs PalmOS la guerre en ces temps là non ?

          • [^] # Re: Ce que Bill Gates en pense…

            Posté par . Évalué à 5.

            Windows mobile et PalmOS étaient là bien avant iOS et Android.

            Comme je ne sais pas le quel est arrivé avant et pour éviter les remarques du style « il est pas arrivé premier il y avait X », j'ai voulu en citer un second.

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.