IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Développement SQL Server Discussion :

Les triggers sous SQL Server !


Sujet :

Développement SQL Server

  1. #21
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 133
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : Mars 2010
    Messages : 10 133
    Points : 38 556
    Points
    38 556
    Billets dans le blog
    9
    Par défaut
    Citation Envoyé par SQLpro Voir le message
    Non votre classement est faux. les études menées en entreprise montre que DB2 est aujourd'hui à la traine (20%). Il a représenté il y a 15/20 ans la plus grosse part de marché. Il a été double par Oracle il y a plus de 10 ans :
    *http://photos1.blogger.com/blogger/6...1600/07814.png
    et a son tour oracle est doublé depuis peu par SQL Server, ceci en terme de nombre d'installation, comme en volume !
    http://reports.informationweek.com/a...chnology-.html
    En ressources c'est encore différent. oracle est devant parce que plus complexe à utiliser et plus complexe à administrer ce qui revient à dire plus cher en TCO et donc plus de monde, de demandes...
    http://db-engines.com/en/ranking
    En part de marché, c'est différent. une licence oracle coute en moyenne 4 fois plus cher que du SQL Server et jusqu'à 25 fois plus cher. C'est pire pour DB2 ! mais du DB2 il ne s'en vend beaucoup moins et c'est encore plus cher qu'Oracle !
    http://www.dadbm.com/wp-content/uplo...enue_share.jpg
    Tous ces classements sont à prendre avec prudence, car selon que l'on mesure le nombre de licences, d'utilisateurs connectés, de téraoctets stockés ou tout autre critère, on a un résultat différent.
    Pour ce qui concerne DB2, il reste de fait le standard du marché, mais uniquement si l'on considère la version DB2 for Z/OS et pour cause, il fait partie de l'offre globale sur le marché captif du mainframe, dont les fournisseurs sont IBM pour le cœur du système SGBD inclus, et Computer Associate pour les outils associés (il y en a quelques autres qui se partagent les miettes)
    Par contre la version DB2 open est effectivement en concurrence avec MS SQL server et autres SGBD ouverts, c'est là que le marché est concurrentiel.

  2. #22
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 763
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 763
    Points : 52 554
    Points
    52 554
    Billets dans le blog
    5
    Par défaut
    Citation Envoyé par escartefigue Voir le message
    Tous ces classements sont à prendre avec prudence, car selon que l'on mesure le nombre de licences, d'utilisateurs connectés, de téraoctets stockés ou tout autre critère, on a un résultat différent.
    Pour ce qui concerne DB2, il reste de fait le standard du marché, mais uniquement si l'on considère la version DB2 for Z/OS et pour cause, il fait partie de l'offre globale sur le marché captif du mainframe, dont les fournisseurs sont IBM pour le cœur du système SGBD inclus, et Computer Associate pour les outils associés (il y en a quelques autres qui se partagent les miettes)
    Par contre la version DB2 open est effectivement en concurrence avec MS SQL server et autres SGBD ouverts, c'est là que le marché est concurrentiel.
    Mais même en mainframe IBM vends de moins en moins, et la plupart des gens préfèrent passer à Linux, même en conservant la solution chez IBM.
    Beaucoup de grosses boîte migrent vers Linux ou dans le cloud en ce moment... Ce que IBM n'ravait pas prévu !
    Mon voisin en Provence est un des gros vendeurs IBM de mainframe EMEA pour de l'hébergement data et à du se mettre au cloud et à Linux alors qu'il est à 2 ans de la retraite...

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  3. #23
    Modérateur

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Janvier 2005
    Messages
    5 826
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Janvier 2005
    Messages : 5 826
    Points : 12 371
    Points
    12 371
    Par défaut
    Bonjour,

    J'aimerai revenir sur quelques éléments :

    L'approche ensembliste est bien plus coûteuse (nécessite de faire des jointures) que de traiter ligne par ligne les insertions (aucune jointure n'est nécessaire).
    Inversement, mais là c'est une autre question, on ne sait pas techniquement parlant comment cela est traité derrière.
    Les moteurs de bases de données relationnelles SQL sont conçus et optimisés pour exécuter des jointures. Par exemple dans SQL Server, il y a 3 algorithmes de jointure.
    Si spécifier des jointures dans un moteur de bases de données relationnel est un problème, alors il faut enlever le R de SGBDR.

    Traiter les lignes une à une est donc un non-sens pour tout SGBDR SQL, et je vous mets au défi de mesurer les temps avec un curseur ou un WHILE dans un trigger, quel que soit le SGBDR.

    Quand on est débutant, et que l'on veut se faire la main en php, il va de soi que c'est MySql qui sera votre première base de données.
    Je ne vois pas en quoi cela va de soi. C'est plutôt une solution de facilité, parce que l'ensemble W/LAMP est livré en bundle, qui plus est gratuit et libre.
    Pour avoir bossé dans plusieurs boîtes web, j'ai vu du Php, du Java, du Delphi (d'ailleurs migré depuis Oracle) et du C# sur du SQL Server.
    Entre un site web marchand et un site web de blogs ou forums ou qui réalise un faible nombre de transactions de paiement, il y a quand même une différence.

    C'est la plus grosse offre sur le web pour pour créer un site d'e-commerce.
    Là encore on parle de "petits" sites; rien à voir par exemple avec ceux que cite SQLPro.

    Il y a quelques années, j'ai rencontré un DBA Oracle qui me disait que son employeur commençait à considérer SQL Server 2005. Dès qu'il a démarré sur cet opus, il a trouvé cela beaucoup plus simple qu'Oracle, simplement pour les sauvegardes (Rman vs. BACKUP DATABASE ou si on a la flème, un plan de maintenance). Petit à petit, son employeur qui a grossi est arrivé à 50-50 en terme de nombre de licences. Aujourd'hui, ils migrent doucement les bases Oracle vers de nouvelles instances SQL Server. Motif invoqué par DSI : côut des licences, quantité de personnel par base de données ... C'est un cas isolé me direz-vous, mais le fait est que c'est un mouvement que l'on observe en France, aux Etats-Unis et en Thaïlande, où Oracle est très bien implanté, notamment dans les banques. Je cite ces trois pays car j'y ai travaillé.

    Par ailleurs je n'ai jamais vu Microsoft faire de la pub pour SQL Server en première page du Washington Post, comme Oracle, qui par ailleurs ne dispose pas d'une plateforme cloud.
    Il suffit enfin de regarder les tests TPC pour voir ce que l'on peut faire avec SQL Server, qui y est très présent, alors que plusieurs éditeurs de SGBDR, dont Oracle, contribuent à cette association.

    @++

  4. #24
    Expert éminent sénior Avatar de Artemus24
    Homme Profil pro
    Agent secret au service du président Ulysses S. Grant !
    Inscrit en
    Février 2011
    Messages
    6 379
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Agent secret au service du président Ulysses S. Grant !
    Secteur : Finance

    Informations forums :
    Inscription : Février 2011
    Messages : 6 379
    Points : 19 060
    Points
    19 060
    Par défaut
    Salut SQPRO.

    Citation Envoyé par SQLPRO
    Il serait beaucoup plus simple et nettement plus efficace de procéder en 2 temps :
    • Créer une fonction de formatage
    • Créer un déclencheur ensembliste utilisant cette fonction
    Oui, entièrement d'accord, sauf que le but de cet exercice est d'apprendre et de manipuler les déclencheurs.

    Citation Envoyé par SQLPRO
    Ce afin d'éviter le curseur qui est stupide car il transforme un comportement ensembliste en comportement itératif et donc pourri les performances !
    Même remarque sur le curseur. C'est juste pour apprendre comment fonctionne SQL Server.
    Je sais que mes exercices ne sont pas conforme à l'usage que j'en fais.

    Citation Envoyé par SQLPRO
    FAUX : ce n'est pas parce qu'il y a erreur que la transaction est annulée.
    Je n'ai jamais dit cela.

    Citation Envoyé par SQLPRO
    Une transaction doit toujours se finaliser par COMMIT ou ROLLBACK.
    Oui, je suis d'accord sur le principe, mais je ne parle pas supprimer cette finalité.
    Vous mettez le "begin transaction au niveau le plus général dans le script, et vous testez le bon fonctionnement d'un ordre en faisant soit un "commit" ou un "rollback" dans le déclencheur.
    Tout ce que je dis, c'est de mettre le "commit" ou le "rollback" au même niveau que le "begin transaction.
    Il n'a jamais été question de les supprimer.

    Citation Envoyé par SQLPRO
    L'erreur sera donc propagée et la transaction reste vivante...
    Je sais très bien que tout démarrage d'une transaction doit à un moment ou une autre se terminer par un "commit" ou un "rollback".
    C'est juste que je ne suis pas d'accord avec vous, sur l'emplacement de cette finalité, ni sur la façon dont vous le gérez. Pourquoi ?
    Je ne voie aucun point de reprises et encore moins un traitement ligne par ligne.
    De ce fait, le traitement ensembliste est du genre : soit tout est validé, soit tout est rejeté.
    Autant le faire à l'extérieur, dans le script après les insert. Cela ne va pas changer le fonctionner du mode transactionnel.

    Citation Envoyé par SQLPRO
    Si tu désire que les performances soient catastrophique c'est comme cela qu'il faut procéder !
    Si vous voulez améliorer les performances, dans ce cas, on ne fait pas un traitement tout ou rien sur la globalité de ce que l'on cherche à charger.
    On fait cela par lots de N lignes. Imaginons un seul instant que le plantage se fasse sur la dernière ligne des 1.000.000 lignes à charger.
    SQL Server va devoir défaire (Rollback) tout ce qui a été traité mais non validé (Commit). Si vous trouvez cela performant, ce n'est pas mon cas.
    Inversement, si vous avez des lots de 10.000 lignes, vous aurez 990.000 lignes qui auront été validés (Commit), mais les 10.000 dernières seront rejetés (Rollback).
    Avec un point de reprise, on ne traite à nouveau que le dernier lot de 10.000 lignes.

    Ce point de reprise ne peut pas se gérer dans un déclencheur ou autre chose, mais au niveau procédurale, dans le script.
    D'où ma remarque de mettre le "commit" ou le "rollback" au même niveau que le "begin transaction.

    Citation Envoyé par SQLPRO
    Ne t'as ton pas appris qu'en cas d'erreur il faut traiter le problème au plus tôt ?
    Oui, je le sais, mais on ne le fait pas n'importe où ! C'est de cela dont je parle !
    La notion de grappe de validité fait que le "rollback" ou le "commit" doivent se faire sur un point de cohérence du traitement.
    Si vous avez deux tables qui sont en relation, vous l'allez pas valider l'une, quand l'autre sera rejeté.
    De ce fait, vous créez un problème d'intégrité dans la base de données !!!

    Citation Envoyé par SQLPRO
    Oui, par ce que le WHILE est théoriquement suffisant pour tout type de boucle.
    C'est une approche minimaliste de la programmation.

    Il existe quatre cas :
    --> la boucle "pour i de 1 à n par-pas-de 1 faire ... fin-faire".
    --> la boucle "répéter ... jusqu'à (condition)".
    --> la boucle "tant que (condition) faire ... fin_faire".
    --> la boucle "itérer ... sortir si (condition) ... fin-itérer".

    Elles ont chacune leur utilité.
    C'est dans ce quatrième cas que l'on retrouve les mots clef "break" (sortir de la boucle) ou "continue" (passer à la prochaine itération).
    Mais comme aujourd'hui, on se permet une certaine permissivité dans les structures dite algorithme, on mélange des notions qui n'ont pas lieu d'être.
    Et tout ça, pour être minimaliste.

    Citation Envoyé par SQLPRO
    De la même manière il n'y a pas de ENDIF de ELSIF qui est totalement inutile !
    Ce qui est source d'erreur ! Par exemple :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    if (@test = 1)
       if (@val = 'oui) set @res = 'ok'
       else set @res = 'ko'
    Il "else va t-il se rapporter au premier ou au second "if" ?
    Ce qui nécessite d'introduire le bloc "begin ... end" afin de clarifier la syntaxe du "if". D'où !
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    if (@test = 1)
    begin
       if (@val = 'oui) set @res = 'ok'
    end
    else set @res = 'ko'
    ou bien
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    if (@test = 1)
    begin
       if (@val = 'oui) set @res = 'ok'
       else set @res = 'ko'
    end
    Encore que le deuxième exemple est incorrecte en terme de définition du périmètre de la variable @val.
    Rien n'indique qu'elle admet que deux valeurs, à savoir "oui" et "non".
    Et que l'on doit nécessairement écraser la valeur existante de @res dans le cas du else que l'on interprète à tort, comme étant l'équivalent du 'non'.

    Citation Envoyé par SQLPRO
    Ceci est extrait d'un mémento SQL Server imprimé en cours de maquetage et qui sera disponible d'ici peu...
    J'aime bien les mémentos car j'ai toujours des problèmes à me souvenir de la syntaxe exacte.

    Citation Envoyé par Artemus24
    Et à quand la version 2016 ?
    Vous n'avez pas répondu à ma question ?
    Je parlais bien sûr de la version express 2016 qui doit être sortie (le 1er juin 2016).

    @+
    Si vous êtes de mon aide, vous pouvez cliquer sur .
    Mon site : http://www.jcz.fr

  5. #25
    Expert éminent sénior Avatar de Artemus24
    Homme Profil pro
    Agent secret au service du président Ulysses S. Grant !
    Inscrit en
    Février 2011
    Messages
    6 379
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Agent secret au service du président Ulysses S. Grant !
    Secteur : Finance

    Informations forums :
    Inscription : Février 2011
    Messages : 6 379
    Points : 19 060
    Points
    19 060
    Par défaut
    Salut elsuket.

    Citation Envoyé par elsuket
    Par exemple dans SQL Server, il y a 3 algorithmes de jointure.
    Pouquoi dans SQL Server ? Est-ce parce que nous nous trouvons dans le forum consacré à SQL Server ?

    A moins de me tromper, ce sont :
    --> nested-loop join,
    --> hash-based join
    --> sort/merge join

    Je disais plus simplement que la jointure est plus coûteuse en terme de performance que de faire un simple accès sans jointure.

    Citation Envoyé par elsuket
    Traiter les lignes une à une est donc un non-sens pour tout SGBDR SQL
    Pourquoi est-ce un non sens ? Vous oublier que la question de la performance est le critère qui détermine les bons choix.

    Citation Envoyé par elsuket
    je vous mets au défi de mesurer les temps avec un curseur ou un WHILE dans un trigger, quel que soit le SGBDR.
    Mais pas rapport à quoi ?

    Si j'ai le choix entre un traitement avec une jointure (donc sur deux tables), et un traitement sur une seule table (du genre curseur), vous affirmez que la jointure est plus performante ?
    Il y a tellement de paramètres qui peuvent infirmer cette idée que je ne comprends pas comment pouvez vous être aussi affirmatif.

    Citation Envoyé par elsuket
    Je ne vois pas en quoi cela va de soi.
    Vous êtes sous windows et vous cherchez à intaller un serveur WEB. Qu'est-ce que vous allez prendre ?
    Dans la plupart des cas, c'est Wamp (Windows, Apache, MySql et PhpMySql) qui est installé.
    Pour EasyPhp, on a le choix entre MySQL, Nginx et PostgreSQL.
    Pour IIS de Microsoft, il n'y a pas de SGBD. C'est juste un serveur web.

    Citation Envoyé par elsuket
    C'est plutôt une solution de facilité
    Nous sommes d'accord, car MySql est installé nativement dans ces packages.
    Et de plus, on trouve aussi chez les hébergeurs MySql et Postgres.
    Donc pourquoi vouloir faire autre chose comme SGBD s'ils ne sont pas disponible chez les hébergeurs ?

    Citation Envoyé par elsuket
    Entre un site web marchand et un site web de blogs ou forums ou qui réalise un faible nombre de transactions de paiement, il y a quand même une différence.
    Oui, il y a une différence. Pourquoi payer si on peut l'avoir gratuitement ?
    Après, si vous voulez la stabilité, la performance, la sécurité, le respect des normes, et bien il faut mettre le prix.
    Mais pour un débutant, ce ne sont pas des critères importants.

    Citation Envoyé par elsuket
    Il y a quelques années, j'ai rencontré un DBA Oracle qui me disait que son employeur commençait à considérer SQL Server 2005. Dès qu'il a démarré sur cet opus, il a trouvé cela beaucoup plus simple qu'Oracle, simplement pour les sauvegardes (Rman vs. BACKUP DATABASE ou si on a la flemme, un plan de maintenance). Petit à petit, son employeur qui a grossi est arrivé à 50-50 en terme de nombre de licences. Aujourd'hui, ils migrent doucement les bases Oracle vers de nouvelles instances SQL Server. Motif invoqué par DSI : coût des licences, quantité de personnel par base de données ... C'est un cas isolé me direz-vous, mais le fait est que c'est un mouvement que l'on observe en France, aux Etats-Unis et en Thaïlande, où Oracle est très bien implanté, notamment dans les banques. Je cite ces trois pays car j'y ai travaillé.
    Votre exemple démontre ce que j'essaye d'affirmer.
    Si vous avez deux offres comparables, l'une chère et l'autre beaucoup moins. Que faites vous ?
    Vous restez fidèle à vos convictions de départ et tant pis si cela plombe votre budget.
    On bien vous prenez celui qui est le plus attractif ?

    Et bien, le débutant, il fait le même choix que le professionnel ! C'est cela qui vous parait bizarre ?

    Ensuite, il y a le coût de la maintenance qui n'est pas négligeable.
    La migration de l'ancien SGBD vers, par exemple, SQL Server. Cela peut poser des problèmes.
    Les compétences professionnelles que l'on trouve sur le marché du travail.
    La rapidité de l'évolution du SGBD par rapport aux nouvelles normes
    Et surtout, est-ce que cela répond aux besoins de mes projets ?

    Si SQL Server a le vent en poupe, ce n'est pas pour rien.
    Car Oracle est vieillissant, et n'a pas la même marche de manœuvre de Microsoft.

    Je ne critique aucun SGBD. Ils ont tous des qualités et des défauts.
    Mais au final, c'est celui qui est le plus adaptatif (comme dans le darwinisme) qui va remporter la victoire.
    La sélection naturel se fait surtout sur les défauts que sur les qualités du produit.

    @+
    Si vous êtes de mon aide, vous pouvez cliquer sur .
    Mon site : http://www.jcz.fr

  6. #26
    Modérateur

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Janvier 2005
    Messages
    5 826
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Janvier 2005
    Messages : 5 826
    Points : 12 371
    Points
    12 371
    Par défaut
    Oui, il y a une différence. Pourquoi payer si on peut l'avoir gratuitement ?
    Après, si vous voulez la stabilité, la performance, la sécurité, le respect des normes, et bien il faut mettre le prix.
    Mais pour un débutant, ce ne sont pas des critères importants.
    SQL Server Express est gratuit. Les hébergeurs ne le mettent à disposition parce que ce n'est pas ce que les développeurs demandent.
    En ce qui concerne la stabilité, les performances, la sécurité, le respect des normes, SQL Server Express n'est pas amoindri du fait de cette édition.

    Donc c'est un choix qui est fait; MySQL pour ne citer que lui n'est pas proche de la norme SQL.
    Côté performance et sécurité, on sait ce qu'il en est par rapport à SQL Server.

    Ce n'est pas un critère important pour un débutant parce que le SQL est enseigné de façon assez légère : en tout cas c'est ce que je trouve.
    Donc on commence à faire du développement sur un ersatz d'SGBDR, et ensuite en entreprise on retrouve un modèle catastrophique avec des tables obèses, inindexable, avec des requêtes horribles. Rares sont les entreprises qui commencent par modéliser la base de données, parce que tout le monde a démarré avec un SGBD pauvre, où on peut mettre trois tables qui ont peu de lignes et cela "satisfait". Quand on demande à voir le modèle, en général on a des yeux ronds; moins souvent le modèle physique, et rarement le modèle conceptuel.

    Pouquoi dans SQL Server ? Est-ce parce que nous nous trouvons dans le forum consacré à SQL Server ?
    Je disais cela parce que je ne connais pas les algorithmes de jointure dans les autres SGBDR.

    Je disais plus simplement que la jointure est plus coûteuse en terme de performance que de faire un simple accès sans jointure. [...]
    Pourquoi est-ce un non sens ? Vous oublier que la question de la performance est le critère qui détermine les bons choix. Mais pas rapport à quoi ?
    [...]
    Si j'ai le choix entre un traitement avec une jointure (donc sur deux tables), et un traitement sur une seule table (du genre curseur), vous affirmez que la jointure est plus performante ?
    Il y a tellement de paramètres qui peuvent infirmer cette idée que je ne comprends pas comment pouvez vous être aussi affirmatif.
    Seriez-vous prêt à affirmer qu'une table avec 200 colonnes vaut mieux à tout type d'accès que la même table correctement modélisée, c'est à dire explosée en plusieurs autres tables ?
    Justement, la modélisation permet d'allier une organisation des données aux performances. Par ailleurs en termes d'intégrité des données, de situations de blocage, ... il n'y a pas photo.
    En ce qui concerne un traitement avec un curseur, je vous renvoie à ce petit test que j'ai fait : le constat est sans appel.
    En ce qui concerne les tables obèses, je vous renvoie vers le billet de SQLPro sur ce sujet.

    Prouvez-nous donc le contraire, mais pas avec 4 lignes qui se battent en duel

    Je suis en train de remodéliser petit bout par petit bout une base de données pour un éditeur de logiciels, où l'on trouve des tables qui comptent jusqu'à 400 colonnes.
    Parfois elles terminent explosées en plus de 20 tables, et comme on le fait petit bout par petit bout, celles que l'on avait déjà crées par normalisation sont intégrées sans difficulté au nouveau modèle. Pour obtenir le même résultat, non seulement les requêtes sont bien plus simples à exprimer (ce sont les Développeurs eux-même qui m'en font part) que ce qu'elle était à l'origine, les index sont bien plus petits et le côut de stockage est bien amoindri, mais surtout, les performances sont bien plus élevées. Si l'on compare les plans d'exécution, sans même tenir compte du coût, là encore après remodélisation, il y a très peu d'optimisation à effectuer : elle est principalement constituée par l'ajout d'index qui couvrent mieux la requête à l'étude.

    D'ailleurs, c'est assez drôle puisque la migration de MySQL à SQL Server avec le même modèle et les mêmes données a été opérée par cet éditeur de logiciels lorsque SQL Server 2005 est sorti.
    Le DSI a continuellement migré toute ses bases de données de MySQL à SQL Server. Pourquoi pensez-vous qu'il a fait ce choix ? En tout cas cela lui a permis de rester jusqu'il y a peu sans DBA

    Donc pourquoi vouloir faire autre chose comme SGBD s'ils ne sont pas disponible chez les hébergeurs ?
    Donc si je ne vous vend qu'un seul produit, vous n'allez pas chercher ailleurs pour voir s'il n'y pas un produit similaire qui vous conviendrait mieux ?

    Si vous avez deux offres comparables, l'une chère et l'autre beaucoup moins. Que faites vous ?
    Vous restez fidèle à vos convictions de départ et tant pis si cela plombe votre budget.
    On bien vous prenez celui qui est le plus attractif ?
    Détrompez vous; que ce soir professionnellement comme lors de mes achats, j'essaie de savoir pourquoi l'un est plus cher que l'autre. Quand on passe de gratuit à payant, il y a nécessairement une différence. Pour avoir aussit fait l'expérience du gratuit ou libre par rapport au payant dans l'entreprise, je n'ai fait qu'un constat : quand le SGBD (R ou pas) est libre, il faut plus de personnel pour le maintenir. Donc on fait des économies sur le prix de la licence qui sont écrasées par le côut de maintenance et le nombre de machines, et ceci sans compter les salaires : il faut bien payer les DBA, quel que soit le SGBD sur lequel ils sont spécialisés . Donc en terme de coût, le plus attractif n'est pas toujours celui que l'on croit.

    Je ne critique aucun SGBD. Ils ont tous des qualités et des défauts.
    Mais au final, c'est celui qui est le plus adaptatif (comme dans le darwinisme) qui va remporter la victoire.
    La sélection naturel se fait surtout sur les défauts que sur les qualités du produit.
    Je crois effectivement que nous sommes d'accord; parfois il est difficile de se comprendre multuellement par écrits interposés.
    C'est bien d'avoir le choix; il est évident que les éléments de la palette permettent de choisir, et le portefeuille pèse lourdement sur ce choix.
    Cela ne change pas que le modèle est fondamental; les comparaisons effectuées par les tests TPC parlent d'eux-même : hardware équivalent, base de données identiques.
    On mesure la durée d'exécution de la charge, avec des métriques hardware, sur plusieurs SGBDR, et on compare. On voit ça ensemble autour de quelques pintes ?

    @++

  7. #27
    Expert éminent sénior Avatar de Artemus24
    Homme Profil pro
    Agent secret au service du président Ulysses S. Grant !
    Inscrit en
    Février 2011
    Messages
    6 379
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Agent secret au service du président Ulysses S. Grant !
    Secteur : Finance

    Informations forums :
    Inscription : Février 2011
    Messages : 6 379
    Points : 19 060
    Points
    19 060
    Par défaut
    Salut elsuket.

    Je comprends surtout que nous ne parlons pas de la même chose.

    Citation Envoyé par elsuket
    Les hébergeurs ne le mettent à disposition parce que ce n'est pas ce que les développeurs demandent.
    Je ne comprends pas trop votre double négation.

    Citation Envoyé par elsuket
    Donc c'est un choix qui est fait;
    A qui appartient ce choix ?
    Est-ce comme je le crois, la direction qui prend la décision de choisir tel ou tel SGBD, la plupart du temps pour des raisons économiques.
    Ou est-ce par nécessité en terme de performance et de coût de la maintenance, que la décision se fait dans l'urgence pour basculer vers un autre SGBD ?
    Selon moi, la décision de ce choix n'est jamais réfléchie en terme d'évolution du projet et encore moins en terme de maintenabilité.

    Citation Envoyé par elsuket
    MySQL pour ne citer que lui n'est pas proche de la norme SQL.
    Est-ce si grave que cela ? Non.
    Ce qui est grave, c'est la vocation de MySql d'être abordable pour les débutants !
    Pour correctement fonctionner, ce SGBD doit être correctement paramétré lors de son installation.
    Mais aussi d'avoir une documentation compréhensible et complète sur ce sujet, ce qui n'est pas le cas, non plus.
    Ce qui implique d'avoir une bonne connaissance de son paramétrage, ce qui est loin d'être le cas avec des débutants.
    A part cela, je le trouve assez souple à l'usage.

    Citation Envoyé par elsuket
    Ce n'est pas un critère important pour un débutant parce que le SQL est enseigné de façon assez légère : en tout cas c'est ce que je trouve.
    Nous sommes d'accord ! On enseigne juste le DML et bien plus rarement le DDL. Alors concernant le paramétrage, et l'administration, c'est une autre histoire.

    Citation Envoyé par elsuket
    Je disais cela parce que je ne connais pas les algorithmes de jointure dans les autres SGBDR.
    En lisant ce pdf, je constate qu'il existe d'autres dénomination :
    https://www.informatik.hu-berlin.de/...s/09_joins.pdf
    Sous DB2 z/os, on parle plutôt de "hybrid (hash) join" et de "block-nested loop".

    Citation Envoyé par elsuket
    Seriez-vous prêt à affirmer qu'une table avec 200 colonnes vaut mieux à tout type d'accès que la même table correctement modélisée, c'est à dire explosée en plusieurs autres tables ?
    Pourquoi abordez vous cette question ? Cela n'a jamais été mon propos.
    Une base de données non modélisée est une absurdité ! Sur le principe, je suis d'accord avec vous.
    Je rappelle que le mieux est l’ennemi du bien. Donc ne jugeons pas sans savoir de quoi il en retourne.

    J'ai déjà vu des absurdités, mais quand j'en parlais au client, il me disais surtout de ne pas toucher car cela lui convenait parfaitement.
    Je rappelle que le client est roi, et c'est lui qui a le dernier mot.
    J'ai même vu un client refuser un projet qui fonctionnait parfaitement, mais dont il n'avait plus la maitrise car cela dépassait sa compétence.

    Citation Envoyé par elsuket
    Justement, la modélisation permet d'allier une organisation des données aux performances.
    C'est une erreur de croire cela ! La modélisation à pour but d'organiser les données fonctionnellement.
    Mais si fonctionnellement cela a un sens, en terme de performance, il est parfois nécessaire de dégrader la modélisation, pour obtenir un meilleur coût.
    Tout le travail de l'administrateur de base de données repose sur :
    --> la performance
    --> l'intégrité des données
    --> la garantie de pouvoir revenir à une situation antérieur en cas de très gros problème.

    Citation Envoyé par elsuket
    Par ailleurs en termes d'intégrité des données, de situations de blocage, ...
    Ce n'est pas la modélisation qui répond à ce genre de problème, mais bien le SGBD.
    Entre autre, un paramétrage correcte, et surtout une bonne compréhension de la façon de gérer les données au sein de la base de données.
    C'est bien à l'administrateur de garantir le fonctionnement du SGBD au sein de ce projet.

    Citation Envoyé par elsuket
    En ce qui concerne un traitement avec un curseur, je vous renvoie à ce petit test que j'ai fait : le constat est sans appel.
    J'ai refais le test. J'ai mis mes résultats dans votre blog.

    Citation Envoyé par elsuket
    Prouvez-nous donc le contraire, mais pas avec 4 lignes qui se battent en duel
    Le contraire de quoi ?

    Je ne suis pas un expert en SQL Server. J'ai repris votre exemple qui ne me convenait pas du tout.
    Il y a un manque de rigueur dans la comparaison que vous faites.
    J'obtiens un résultat six fois meilleur que le votre. A vous de vous justifier sur cette énorme différence !

    Inversement, cela ne change pas la conclusion final. Le curseur est plus long que l'approche ensembliste.

    Mais ce n'est pas de cela que je parlais depuis le début.
    Je n'ai jamais dis que rajouter une surcouche à ce que sait déjà faire en interne SQL Server, sera plus performant !

    Je disais que l'approche ensembliste est plus coûteuse en performance que le parcours séquentiellement d'une table.
    Je n'ai jamais parlé de faire un curseur.

    S'il vous faut une preuve, voici un exemple de ce que j'avance :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    68
    69
    70
    71
    72
    73
    74
    75
    76
    77
    78
    79
    80
    81
    82
    83
    84
    85
    86
    87
    88
    89
    90
    91
    92
    93
    94
    95
    96
    97
    98
    99
    100
    101
    102
    103
    104
    105
    106
    107
    108
    109
    110
    111
    112
    113
    114
    115
    116
    117
    118
    119
    120
    121
    122
    123
    124
    125
    126
    127
    128
    129
    130
    131
    132
    133
    134
    135
    136
    137
    138
    139
    140
    141
    142
    143
    144
    145
    146
    147
    148
    149
    150
    151
    152
    153
    154
    155
    156
    157
    -- ===========
    -- Paramétrage
    -- ===========
     
    SET NOCOUNT ON
     
    -- ==================
    -- Lien vers Database
    -- ==================
     
    use tempdb
     
    Le contexte de la base de données a changé*; il est maintenant 'tempdb'.
     
    -- ==========================
    -- Suppression Table 'devise'
    -- ==========================
     
    IF OBJECT_ID(N'dbo.devise', N'U') IS NOT NULL
        DROP TABLE dbo.devise
     
    Message 3726, niveau 16, état 1, serveur ORION\SQLEXPRESS, ligne 7
    Impossible de supprimer l'objet 'dbo.devise' car il est référencé par une contrainte FOREIGN KEY.
    -- =======================
    -- Création Table 'devise'
    -- =======================
     
    create table dbo.devise (
      devise  integer  identity(1, 1) not null,
      nom     varchar(10)             not null,
      cours   decimal(15,2)           not null,
      constraint pk_devise_id   primary key clustered (devise)
    )
     
    Message 2714, niveau 16, état 6, serveur ORION\SQLEXPRESS, ligne 5
    Il existe déjà un objet nommé 'devise' dans la base de données.
    -- =======================
    -- Insertion dans 'devise'
    -- =======================
     
    insert into devise (nom,cours) values
      ('dem', 1.95583), ('frf', 6.55957), ('grd', 340.750), ('esp', 166.386)
     
    -- ==================
    -- Vidage de 'devise'
    -- ==================
     
    select * from dbo.devise;
     
    devise      nom        cours
    ----------- ---------- -----------------
              1 dem                     1.96
              2 frf                     6.56
              3 grd                   340.75
              4 esp                   166.39
              5 dem                     1.96
              6 frf                     6.56
              7 grd                   340.75
              8 esp                   166.39
     
    -- ========================
    -- Suppression Table 'test'
    -- ========================
     
    IF OBJECT_ID(N'dbo.test', N'U') IS NOT NULL
        DROP TABLE dbo.test
     
    -- =====================
    -- Création Table 'test'
    -- =====================
     
    create table test (
      id       integer  identity(1, 1) not null,
      devise   integer                 not null,
      montant  decimal(15, 2)          not null,
      constraint pk_test_id     primary key clustered (id),
      constraint fk_test_devise foreign key (devise) references dbo.devise (devise) on delete cascade on update cascade
    )
     
    -- ===============================
    -- Suppression Procédure 'remplir'
    -- ===============================
     
    IF OBJECT_ID(N'dbo.remplir', N'P') IS NOT NULL
       DROP PROCEDURE dbo.remplir
     
    -- ============================
    -- création procédure 'remplir'
    -- ============================
     
    create procedure dbo.remplir
      @nbre integer
    as
      declare @j smallint
    begin
      while (@nbre > 0)
      begin
        set @j = 4
     
        while (@j > 0)
            begin
          insert into dbo.test (devise,montant) values (@j, 100000.00)
          set @j = @j - 1
        end
     
        set @nbre = @nbre - 1
      end
    end
     
    -- ==============================
    -- remplissage de la table 'test'
    -- ==============================
     
    execute remplir 250000
     
    -- ============
    -- Requête N° 1
    -- ============
     
    declare @datedeb datetime = cast(current_timestamp as datetime)
     
    update dbo.test
    set montant = case devise when 1 then montant * 1.95583
                              when 2 then montant * 6.55957
                              when 3 then montant * 340.750
                              when 4 then montant * 166.386
                              else 0 end
     
    declare @datefin datetime = cast(current_timestamp as datetime)
     
    select datediff(millisecond, @datedeb, @datefin) as 'temps elaps'
     
    temps elaps
    -----------
           2230
     
    -- ============
    -- Requête N° 2
    -- ============
     
    declare @datedeb datetime = cast(current_timestamp as datetime)
     
    update     dbo.test
    set montant = t.montant * d.cours
    from       dbo.test   as t
    inner join dbo.devise as d
    on d.devise = t.devise
     
    declare @datefin datetime = cast(current_timestamp as datetime)
     
    select datediff(millisecond, @datedeb, @datefin) as 'temps elaps'
     
    temps elaps
    -----------
           9080
     
    Appuyez sur une touche pour continuer...
    Les jointures sont elles plus performantes ? Et bien non !

    Le traitement fait exactement la même chose dans les deux cas. Je traite 1.000.000 de lignes dans la table test.

    Dans le premier cas, le temps elaps est de : 2.230 secondes. C'est le cas du traitement séquentielle de la table.
    Dans le second cas, le temps elaps est de : 9.080 secondes. C'est la jointure sur deux tables.

    Y-a pas photo ! Et vous répondez quoi ?

    Citation Envoyé par elsuket
    Je suis en train de remodéliser petit bout par petit bout une base de données pour un éditeur de logiciels
    A ce niveau de déstructuration de votre base de données, on ne nomme plus cela une re-modélisation.
    C'est plus une refonte total avec migration des données dans un nouveau système, plus performant et plus adapté à cette volumétrie.

    Citation Envoyé par elsuket
    D'ailleurs, c'est assez drôle puisque la migration de MySQL à SQL Server avec le même modèle et les mêmes données a été opérée par cet éditeur de logiciels lorsque SQL Server 2005 est sorti.
    Comportement absurde mais typique de la méconnaissance des SGBD. Chaque SGBD a sa propre façon de fonctionner.
    Ce qui fonctionne chez l'un, peut se voir totalement dégradé en performance chez l'autre.
    Des migrations, j'en ai fait beaucoup et je peux vous assurer que gagner du temps en faisant un copier/coller va vite se faire sentir en performance et en maintenance par la suite.
    Le mieux est de faire une refonte total de la modélisation et de migrer les donner, en tenant compte des nouvelles contraintes.

    Citation Envoyé par elsuket
    Donc en terme de coût, le plus attractif n'est pas toujours celui que l'on croit.
    Comme je l'ai dit précédemment, cela dépend de vos besoins.
    Et si dès le départ, on se trompe dans le dimensionnement de son projet, il ne vaut pas s'étonner d'en payer le prix par la suite :
    --> migration vers un nouveau SGBD
    --> formation en interne des développeurs.
    --> recrutement d'un nouveau DBA

    Citation Envoyé par elsuket
    parfois il est difficile de se comprendre mutuellement par écrits interposés.
    Je crois surtout que j'ai une approche pragmatique et non à tout pris du respect des normes.
    Je ne vais pas dire au client que MySql ne respecte pas les normes et que je ne sais pas comment faire.
    Je dis au client que je vais essayer de trouver la meilleur solution de ce que je connais de la pratique de ce SGBD.
    Sur un autre SGBD, j'aurai une autre réponse, et cela ne me gène pas.
    La norme, c'est juste une béquille qui parfois est très utile pour ne pas trop se casser la tête.

    Donc oui, il est difficile de se comprendre car nous n'avons pas la même expérience de notre métier.
    Quand un client demande quelque chose, je réponds à son attente, même si cela doit déroger du respect des normes.
    Le client, les normes il s'en fout. Tout ce qu'il veut, c'est que cela réponde à son attente.

    Citation Envoyé par elsuket
    Cela ne change pas que le modèle est fondamental;
    Je ne suis pas aussi catégorique que vous.
    Disons que cela vous facilite la vie et vous empêche de bien réfléchir sur les autres solutions qui pourraient exister, en dehors de la normalisation.
    C'est d'ailleurs une des raisons pour laquelle on dégrade un modèle qui au premier abord semble parfait (en théorie).

    Mais si je suis d'accord sur dégrader un modèle, je ne préconise pas pour autant de faire n'importe quoi.

    Citation Envoyé par elsuket
    On voit ça ensemble autour de quelques pintes ?
    Je suis là pour apprendre, et donc me perfectionner !
    Je propose une solution et nous pouvons en débattre sur la pertinence de cette approche.
    C'est ce que je recherche, à savoir les échanges !

    P.S.: mes résultats dans votre blog ne sont pas très lisible. Dois-je les mettre dans ce sujet ?

    @+
    Si vous êtes de mon aide, vous pouvez cliquer sur .
    Mon site : http://www.jcz.fr

  8. #28
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 763
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 763
    Points : 52 554
    Points
    52 554
    Billets dans le blog
    5
    Par défaut
    Citation Envoyé par Artemus24 Voir le message
    C'est juste que je ne suis pas d'accord avec vous, sur l'emplacement de cette finalité, ni sur la façon dont vous le gérez. Pourquoi ?
    Je ne voie aucun point de reprises et encore moins un traitement ligne par ligne.
    De ce fait, le traitement ensembliste est du genre : soit tout est validé, soit tout est rejeté.
    Autant le faire à l'extérieur, dans le script après les insert. Cela ne va pas changer le fonctionner du mode transactionnel.
    Mon dieu !!!!
    Si vous en êtes là c'est que vous n'avez pas compris grand chose aux bases de données relationnelles !!!
    En effet on ne choisit pas de faire un bout de transaction en commençant par le point A ou le point B et pas davantage en finissant par le point Y ou le point Z. On fait une transaction parce qu'il y a nécessité d'une règle métier qui l'impose !
    Je vais vous donner un exemple tiré des exercices que je donnais à mes étudiants des arts et métiers...
    Un voyagiste réalise des "packages" de voyage incluent un vol AR, un séjour à l’hôtel et une location de voiture et pour cela la base dispose de 3 tables pour la gestion des billet d'avions, des séjours hôteliers et des locations de voiture.
    Si l'on considère l'enchaînement suivant du processus :
    1) trouver un vol
    2) trouver le séjour à l’hôtel
    3) trouver une location voiture
    Vous êtes en train de me dire que l'on peut faire juste 1 et 2 ou 2 et 3 avec votre histoire de point de reprise, ce qui est bien évidemment parfaitement idiot !
    Seule la transaction 1) + 2) + 3) est valide.
    Si au cours d'une de ces opérations un erreur est survenue, il me parait logique d'annuler IMMÉDIATEMENT la transaction (qui, beaucoup ne le savent pas, est un "état" de la session). La raison pour laquelle il est important d'agir au plus tôt et sans attendre est que, tant que la transaction n'est pas finalisée par un COMMIT ou un ROLLBACK, des verrous suspendent l'état des données ce qui bloque d'autres utilisateurs...
    C'est un peu comme si à un passage à niveau un train percutait une voiture et le conducteur décidait finalement de ne s'arrêter qu'à la gare suivante !
    Si vous voulez améliorer les performances, dans ce cas, on ne fait pas un traitement tout ou rien sur la globalité de ce que l'on cherche à charger.
    On fait cela par lots de N lignes. Imaginons un seul instant que le plantage se fasse sur la dernière ligne des 1.000.000 lignes à charger.
    SQL Server va devoir défaire (Rollback) tout ce qui a été traité mais non validé (Commit). Si vous trouvez cela performant, ce n'est pas mon cas.
    Inversement, si vous avez des lots de 10.000 lignes, vous aurez 990.000 lignes qui auront été validés (Commit), mais les 10.000 dernières seront rejetés (Rollback).
    Avec un point de reprise, on ne traite à nouveau que le dernier lot de 10.000 lignes.
    Encore une fois on ne choisit pas de faire une transaction ! On la fait par nécessité fonctionnelle ou alors on ne la fait pas !
    Imaginez que ce traitement de 100 000 lignes soit les lignes de débit / crédit des cartes bleu à mettre sur le compte en fin de mois. Imaginez maintenant qu'une seule ligne soit en erreur et annule la transaction. Et imaginez que ce soit la seule ligne en crédit à mettre sur le compte.. Que va t-il se passer ?
    Votre exemple est bien trop théorique... Revenez dans la réalité fonctionnelle !

    [...]

    C'est une approche minimaliste de la programmation.

    Il existe quatre cas :
    --> la boucle "pour i de 1 à n par-pas-de 1 faire ... fin-faire".
    --> la boucle "répéter ... jusqu'à (condition)".
    --> la boucle "tant que (condition) faire ... fin_faire".
    --> la boucle "itérer ... sortir si (condition) ... fin-itérer".
    Elles ont chacune leur utilité.
    La boucle WHILE avec BREAK et CONTINUE permet de faire ces 4 cas de figure... les 3 autres sont donc parfaitement inutiles...

    [...]
    Au sujet du IF

    Ce qui est source d'erreur ! Par exemple :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    if (@test = 1)
       if (@val = 'oui) set @res = 'ok'
       else set @res = 'ko'
    Déjà vous mettez des parenthèses inutiles... Avez vous acheté un stocke en solde et un tel besoin de les écouler ???
    Ensuite avec une bonne indentation les choses sont simples :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    if @test = 1
       if @val = 'oui'
          set @res = 'ok'
       else set @res = 'ko'
    else set @res = 'sais pas !'

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  9. #29
    Modérateur

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Janvier 2005
    Messages
    5 826
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Janvier 2005
    Messages : 5 826
    Points : 12 371
    Points
    12 371
    Par défaut
    Bonjour Artemus,

    J'ai refais le test. J'ai mis mes résultats dans votre blog.
    Non, vous avez fait un test différent qui met à jour une table de 10 lignes ... en boucle.

    Pour correctement fonctionner, ce SGBD doit être correctement paramétré lors de son installation.
    Effectivement.

    Est-ce si grave que cela ? Non.
    C'est votre avis.

    Citation Envoyé par elsuket
    Seriez-vous prêt à affirmer qu'une table avec 200 colonnes vaut mieux à tout type d'accès que la même table correctement modélisée, c'est à dire explosée en plusieurs autres tables ?
    Pourquoi abordez vous cette question ? Cela n'a jamais été mon propos.
    Je disais plus simplement que la jointure est plus coûteuse en terme de performance que de faire un simple accès sans jointure. [...]
    ...

    Citation Envoyé par esuket
    Justement, la modélisation permet d'allier une organisation des données aux performances.
    C'est une erreur de croire cela ! La modélisation à pour but d'organiser les données fonctionnellement.
    Mais si fonctionnellement cela a un sens, en terme de performance, il est parfois nécessaire de dégrader la modélisation, pour obtenir un meilleur coût.
    Tout le travail de l'administrateur de base de données repose sur :
    --> la performance
    --> l'intégrité des données
    --> la garantie de pouvoir revenir à une situation antérieur en cas de très gros problème.
    On ne peut dénormaliser qu'une fois que l'on a dénormalisé, et c'est un cas particulier.
    Dans la liste des tâches de l'administrateur de base de données, vous omettez (mais l'avez-vous fait exprès ?) la modélisation ...

    Citation Envoyé par elsuket
    Par ailleurs en termes d'intégrité des données, de situations de blocage, ...
    Ce n'est pas la modélisation qui répond à ce genre de problème, mais bien le SGBD.
    Entre autre, un paramétrage correcte, et surtout une bonne compréhension de la façon de gérer les données au sein de la base de données.
    C'est bien à l'administrateur de garantir le fonctionnement du SGBD au sein de ce projet.
    Donc vous affirmez qu'on peut tout à faire mettre des tables monolithiques sur tout SGBDR et que ça marchera impeccablement, voire mieux que si l'on avait normalisé la même table.
    Les SGBDR sont construit sur l'hypothèse de bases de données relationnelles SQL proprement modélisées.
    Le SQL descend de l'algèbre relationnelle, donc un modèle mathématique est sous-jacent à l'optimisation ...

    J'ai même vu un client refuser un projet qui fonctionnait parfaitement, mais dont il n'avait plus la maitrise car cela dépassait sa compétence.
    C'est son choix.

    Ou est-ce par nécessité en terme de performance et de coût de la maintenance, que la décision se fait dans l'urgence pour basculer vers un autre SGBD ?
    Selon moi, la décision de ce choix n'est jamais réfléchie en terme d'évolution du projet et encore moins en terme de maintenabilité.
    C'est effectivement selon vous ... MySQL est moins cher à l'achat que SQL Server, non ?

    J'ai repris votre exemple qui ne me convenait pas du tout.
    Il y a un manque de rigueur dans la comparaison que vous faites.
    J'obtiens un résultat six fois meilleur que le votre. A vous de vous justifier sur cette énorme différence !
    Non c'est vous qui ne savez pas lire, et qui par ailleurs mettez à jour en boucle une table qui contient 10 lignes !!!
    Mon test met à jour une table dans laquelle il y a 10, puis 100, puis 1000 lignes, et ainsi de suite suivant les puissances de 10.
    Entre chaque ajout de lignes, on mesure le temps de mise à jour de toutes les lignes de la table. Donc pour le manque de rigueur, il faudra repasser.

    Je disais que l'approche ensembliste est plus coûteuse en performance que le parcours séquentiellement d'une table.
    Je n'ai jamais parlé de faire un curseur.
    C'est pourtant vous qui avez spécifié un curseur dans un trigger.

    Y-a pas photo ! Et vous répondez quoi ?
    Ce résultat vous surprend-il vraiment, Artemus24 ?

    Je crois surtout que j'ai une approche pragmatique et non à tout pris du respect des normes.
    Je n'ai jamais dit qu'il faut normaliser à tout prix.

    Vous avez apparement le syndrôme de la mouche contre la vitre ...

    A ce niveau de déstructuration de votre base de données, on ne nomme plus cela une re-modélisation.
    C'est plus une refonte total avec migration des données dans un nouveau système, plus performant et plus adapté à cette volumétrie.
    Nous préférons plutôt changer des petits morceaux, histoire que tout n'explose pas, et qu'on ne bloque pas l'implémentation d'autres fonctionnalités.
    Vous savez comme moi qu'une migration de données est une tâche très complexe.

    Comportement absurde mais typique de la méconnaissance des SGBD. Chaque SGBD a sa propre façon de fonctionner.
    Ce qui fonctionne chez l'un, peut se voir totalement dégradé en performance chez l'autre.
    On y arrive enfin ... Avez-vous regardé les tests TPC ?

    Des migrations, j'en ai fait beaucoup et je peux vous assurer que gagner du temps en faisant un copier/coller va vite se faire sentir en performance et en maintenance par la suite.
    Effectivement, copier 10 lignes qui se battent en tournoi, c'est faisable. 10 To, peut-être pas.

    Je ne suis pas aussi catégorique que vous.
    Disons que cela vous facilite la vie et vous empêche de bien réfléchir sur les autres solutions qui pourraient exister, en dehors de la normalisation.
    C'est d'ailleurs une des raisons pour laquelle on dégrade un modèle qui au premier abord semble parfait (en théorie).
    Cela oblige justement à penser à ce à quoi la base de données doit répondre. Comme je l'ai déjà dit, pour pouvoir dénormaliser, il faut d'abord avoir normalisé.
    Si le SGBDR n'est pas adapté à la solution, rien n'empêche de passer à une autre qui répondra mieux au besoin. Ce choix ne devrait-il pas être fait avant de modéliser ?

    Je suis là pour apprendre, et donc me perfectionner !
    Je propose une solution et nous pouvons en débattre sur la pertinence de cette approche.
    C'est ce que je recherche, à savoir les échanges !
    ça tombe bien, moi aussi.

    P.S.: mes résultats dans votre blog ne sont pas très lisible. Dois-je les mettre dans ce sujet ?
    Non, c'est bon. Je vous ai répondu hier.

    @++

  10. #30
    Expert éminent sénior Avatar de Artemus24
    Homme Profil pro
    Agent secret au service du président Ulysses S. Grant !
    Inscrit en
    Février 2011
    Messages
    6 379
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Agent secret au service du président Ulysses S. Grant !
    Secteur : Finance

    Informations forums :
    Inscription : Février 2011
    Messages : 6 379
    Points : 19 060
    Points
    19 060
    Par défaut
    Salut à SQLPRO.

    On ne se comprend pas !!!

    Citation Envoyé par SQLPRO
    Vous êtes en train de me dire que l'on peut faire juste 1 et 2 ou 2 et 3 avec votre histoire de point de reprise, ce qui est bien évidemment parfaitement idiot !
    C'est vous qui êtes idiot. Si vous ne comprenez pas ce que je dis, et bien dites le, au lieu de faire des hypothèses sur mon compte qui sont fausses.
    J'ai surtout l'impression que vous ignorez ce que représente un point de reprise sur une validation de masse.

    Citation Envoyé par SQLPRO
    Seule la transaction 1) + 2) + 3) est valide.
    Oui, c'est la bonne façon de faire et c'est ce que je nomme un grappe de données.
    Afin de ne pas se retrouver avec un problème d'intégrité, on valide les trois cas en même temps ou on rejette les trois cas en même temps.
    C'est une validation tout ou rien. Est-ce plus clair ?

    Citation Envoyé par SQLPRO
    Si au cours d'une de ces opérations un erreur est survenue, il me parait logique d'annuler IMMÉDIATEMENT la transaction
    Je me demande encore un fois si vous comprenez bien ce que je dis ??? Je vais vous le répéter :

    Afin de bien structurer votre script et votre déclencheur, on met le "commit" ou le "rollback" au même niveau que le "begin transaction.
    C'est de cela dont je vous parle !!!

    Comme vous le faites dans un déclencheur, ils ne sont pas au même niveau et c'est une source d'erreur dans la compréhension de votre façon de gérer la transaction.
    Et en plus, on ne fait qu'un seul "commit" ou un seul "rollback" pour une transaction donnée.
    Parce que la bonne façon de faire, est de multiplier dans votre traitement ces validations ou ces rejets. Bonjour la maintenance !

    Citation Envoyé par SQLPRO
    (qui, beaucoup ne le savent pas, est un "état" de la session).
    Pour appliquer un "commit" ou le "rollback", les lignes doivent être journalisés au préalable.
    Le mécanisme de la journalisation est le processus normal de la gestion des transactions.
    Qu'est-ce que la session vient faire la dedans ?

    Citation Envoyé par SQLPRO
    La raison pour laquelle il est important d'agir au plus tôt et sans attendre est que, tant que la transaction n'est pas finalisée par un COMMIT ou un ROLLBACK, des verrous suspendent l'état des données ce qui bloque d'autres utilisateurs...
    Comme si je ne le savais pas.

    Mais vous oubliez une chose, c'est que l'on ne fait pas que des interventions ponctuelles sur une base de données, dans un contexte multi-utilisateurs.
    Selon vous, on ne fait jamais de batch la nuit, avec des traitements de masse, dans un contexte mono-utilisateur ?
    Genre, mettre à jour à partir d'un fichier mouvement bancaire des opérations de la journées, tous les comptes des clients qui sont impactés.
    Comme c'est un traitement de masse, on utilise un point de reprise, afin de ne pas tout retraiter si une erreur vient à se produire disons sur la dernière opération.
    C'est pourquoi, on découpe ce traitement par lot plus petit, afin de diminuer la volumétrie lors d'un "commit" ou le "rollback".
    J'ai surtout l'impression que vous ne savez pas de quoi je parle !

    Vous vous focalisez sur l'annulation IMMÉDIATE de la transaction, comme si cela résolvait vos problèmes de performance.
    Dans le traitement de masse, un point de reprise est plus que nécessaire, sinon en cas de plantage, vous êtes obligés de tout recommencer.
    Avez-vous compris ou pas ?

    Citation Envoyé par SQLPRO
    Encore une fois on ne choisit pas de faire une transaction !
    A bon, parce que d'habitude, cela se fait tout seul ???
    Si l'on fait une transaction, c'est pour avoir la possibilité soit de valider, ou soit de rejeter les lignes qui viennent d'être traités.
    Sinon, en cas d'erreur, comment faites vous pour rejeter vos lignes, si vous ne faites pas une transaction ?
    Donc oui, on choisit de faire une transaction, sinon je ne comprends pas votre façon de gérer vos données.

    Citation Envoyé par SQLPRO
    On la fait par nécessité fonctionnelle ou alors on ne la fait pas !
    Que vient faire la fonctionnelle ici ???

    Cela ne vous arrive jamais d'avoir à traiter un fichier qui a été verolé durant un transfert ?
    Le problème de l'intégrité des données concerne la cohérence de votre base de données
    Et c'est un aspect technique et non fonctionnelle.

    Je crois surtout qu'il y a un problème de communication.

    @+
    Si vous êtes de mon aide, vous pouvez cliquer sur .
    Mon site : http://www.jcz.fr

  11. #31
    Expert éminent sénior Avatar de Artemus24
    Homme Profil pro
    Agent secret au service du président Ulysses S. Grant !
    Inscrit en
    Février 2011
    Messages
    6 379
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Agent secret au service du président Ulysses S. Grant !
    Secteur : Finance

    Informations forums :
    Inscription : Février 2011
    Messages : 6 379
    Points : 19 060
    Points
    19 060
    Par défaut
    Salut elsuket.

    Citation Envoyé par elsuket
    On ne peut dénormaliser qu'une fois que l'on a dénormalisé, et c'est un cas particulier.
    Il y a un couac dans votre phrase. Au préalable, la base doit être normalisée avant de pouvoir par la suite la dénormaliser.

    Citation Envoyé par elsuket
    Dans la liste des tâches de l'administrateur de base de données, vous omettez (mais l'avez-vous fait exprès ?) la modélisation ...
    Je ne l'ai pas fait exprès, mais là où je travaillais (sous IBM gros système et sur des grand comptes), la modélisation n'est pas de ressort du DBA mais d'une équipe d'analyste ayant la connaissance fonctionnelle de la banque ou de l'assurance.
    Le DBA s'occupe du passage logique au physique ! Donc ce n'est pas lui qui prend la décision fonctionnelle de l'utilité de telle entités ou de telle relation dans le modèle logique.

    Citation Envoyé par elsuket
    Donc vous affirmez qu'on peut tout à faire mettre des tables monolithiques sur tout SGBDR et que ça marchera impeccablement, voire mieux que si l'on avait normalisé la même table.
    Ou ai-je dis cela ? Et qu'est-ce que vous essayez de me faire dire ???

    La modélisation sert à découper fonctionnellement votre base de données.
    Cela ne résoud en rien les problèmes de performances, qui sont des problèmes techniques !

    Donc d'après vous, plus aucune intervention pour résoudre des problèmes performance n'est nécessaire quand vous avez votre modèle logique des données ?
    Un index ne vous sert à rien, et les jointures encore moins. Est-ce bien cela ?
    On peut même, selon vous, se demander à quoi sert un DBA.

    Citation Envoyé par elsuket
    Le SQL descend de l'algèbre relationnelle, ...
    Oui.

    Citation Envoyé par elsuket
    ... donc un modèle mathématique ...
    oui.

    Citation Envoyé par elsuket
    est sous-jacent à l'optimisation ...
    Non, car l'optimisation est purement technique !

    Si votre modèle logique découpe fonctionnellement vos données, cela n'indique pas comment vous allez faire pour y accéder.

    Citation Envoyé par elsuket
    MySQL est moins cher à l'achat que SQL Server, non ?
    La version SQL Server Express 2014 est gratuite, alors aucun des deux est moins cher.

    Citation Envoyé par elsuket
    Mon test met à jour une table dans laquelle il y a 10, puis 100, puis 1000 lignes, et ainsi de suite suivant les puissances de 10.
    Je ne le voie nulle part dans vos explications !

    Je vais refaire le test, en tenant compte de ces insertions. Mais dans ce cas là, vous comparez quoi avec quoi ?

    Citation Envoyé par elsuket
    Donc pour le manque de rigueur, il faudra repasser.
    On ne met pas des bouts de codes, mais un script intégral où aucune ambiguïté peut faire varier les résultats du test.

    Citation Envoyé par elsuket
    Nous préférons plutôt changer des petits morceaux, histoire que tout n'explose pas, et qu'on ne bloque pas l'implémentation d'autres fonctionnalités.
    Je ne comprends pas bien, mais vous faites vos modifications dans l'existant, c'est-à-dire ce qui est en production ?????

    Citation Envoyé par elsuket
    Vous savez comme moi qu'une migration de données est une tâche très complexe.
    Pas si complexe que cela. De plus, le basculement doit se faire en une seule fois, durant un week-end ou l'on bloque toute intervention sur l'ancien système.
    Mais oui, cela prend du temps pour penser à tout ce qui doit être fait.

    Citation Envoyé par elsuket
    Ce choix ne devrait-il pas être fait avant de modéliser ?
    Il n'existe pas une seul solution pour organiser vos données dans un modèle logique.
    Si la solution que vous proposez est adaptée pour résoudre votre problème fonctionnelle, il se peut qu'elle ne soit pas du tout adapté à des questions de performances.
    Car dans ces deux approches, vous êtes confronté à deux façons de raisonner, soit fonctionnellement, soit techniquement.
    Or la modélisation ne répond qu'à l'aspect fonctionnelle !

    Dans l'approche Merise, il y a aussi le modèle conceptuel des traitements qui est très souvent délaissés.
    On ne s'intéresse à cette approche que si la base de données est créé.

    Dans le meilleur des mondes, si tout devait se faire au moment de la conception, le DBA n'aurait plus rien à faire.

    @+
    Si vous êtes de mon aide, vous pouvez cliquer sur .
    Mon site : http://www.jcz.fr

  12. #32
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 133
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : Mars 2010
    Messages : 10 133
    Points : 38 556
    Points
    38 556
    Billets dans le blog
    9
    Par défaut
    Citation Envoyé par SQLpro Voir le message
    Mais même en mainframe IBM vends de moins en moins, et la plupart des gens préfèrent passer à Linux, même en conservant la solution chez IBM.
    Beaucoup de grosses boîte migrent vers Linux ou dans le cloud en ce moment... Ce que IBM n'ravait pas prévu !
    Mon voisin en Provence est un des gros vendeurs IBM de mainframe EMEA pour de l'hébergement data et à du se mettre au cloud et à Linux alors qu'il est à 2 ans de la retraite...

    A +
    C'est exact, enfin certaines d'entre elles en tout cas, mais il ne faut pas négliger l'inertie du marché Mainframe qui est très conséquente, je ne pense pas que cette archi disparaisse dans un horizon proche.
    Mes condoléances à votre collègue, la reconversion a du être douloureuse

+ Répondre à la discussion
Cette discussion est résolue.
Page 2 sur 2 PremièrePremière 12

Discussions similaires

  1. les declencheurs sous sql server
    Par momedalhouma dans le forum MS SQL Server
    Réponses: 1
    Dernier message: 16/01/2012, 11h52
  2. Tester la performance d'un trigger sous SQL Server 2008
    Par lerieure dans le forum MS SQL Server
    Réponses: 8
    Dernier message: 14/02/2011, 18h04
  3. Réponses: 1
    Dernier message: 22/10/2010, 09h54
  4. problème requète avec les dates sous sql server
    Par fayabones dans le forum Développement
    Réponses: 2
    Dernier message: 04/06/2009, 22h27
  5. Réponses: 20
    Dernier message: 15/05/2009, 14h05

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo