Commentaires

  1. Avatar de SQLpro
    • |
    • permalink
    Oui, parce que personnellement je conseille fortement de ne jamais mettre ces extensions aux fichiers SQL Server pour des raisons évidentes de sécurité !

    A +
  2. Avatar de hmira
    • |
    • permalink
    Citation Envoyé par SQLpro
    L'inconvénient est que les extensions .mdf et .ldf (il y a aussi .ndf) ne sont pas institutionnelle et que vous pouvez créer une base avec des noms de fichier comportant n'importe quelle extension...

    A +
    Ta remarque est juste concernant le caractère facultatif, non "institutionnel" des extensions .mdf, .ndf, et .ndf, aussi si tu regardes le détails de la procédure, aucune allusion n'est faite ni à l'extension .mdf, ni à .ldf ni à .ndf.
    La procédure se réfère tout simplement au nom réel du fichier défini au niveau de l'OS, tel qu'il est mentionné dans la vue système master.sys.master_files
    Donc, si par hasard, un fichier de base de données orphelin porte l'extension ".toto" (ce qui est complètement légal) ce dernier sera toute fois mis en exergue par le procédure.
    Pour te dire la vérité, j'ai eu exactement la même réflexion que toi, quand j'ai rédigé cet article, mais, j'ai volontairement, dans le préambule, utilisé les termes .mdf, et .ldf pour cela soit rapidement évocateur pour les développeurs et/ou administrateurs de bases de données, parce que même si cela n'est pas "institutionnel", dans la quasi totalité des cas, on retrouve quand même ces extensions.
    j'aurais dû peut être mentionner que ces extensions n'étaient pas "institutionnelles" et que la procédure est capable de détecter n'importe quel fichier orphelin quelle que soit son extension.
    A+
  3. Avatar de SQLpro
    • |
    • permalink
    L'inconvénient est que les extensions .mdf et .ldf (il y a aussi .ndf) ne sont pas institutionnelle et que vous pouvez créer une base avec des noms de fichier comportant n'importe quelle extension...

    A +
  4. Avatar de hmira
    • |
    • permalink
    Citation Envoyé par BLeguillou
    Problème à la connexion avec Admin:<Nom du serveru>
    je reçois le message d'erreur suivant:
    Les connexions administrateur dédiées ne sont pas prises en charge. (Microsoft.SqlServer.Management.SqlStudio.Explorer)
    Vous obtenez ce message d'erreur lorsque vous essayez de vous connecter directement au Serveur pour ouvrir l'explorateur d'objets.
    Il ne faut surtout pas procéder de la sorte ! Il faut suivre la procédure telle que indiquée dans le § III-1 de l’article :
    Fichier > Nouveau > Requête de moteur de base de données
    A+
  5. Avatar de BLeguillou
    • |
    • permalink
    Problème à la connexion avec Admin:<Nom du serveru>
    je reçois le message d'erreur suivant:
    Les connexions administrateur dédiées ne sont pas prises en charge. (Microsoft.SqlServer.Management.SqlStudio.Explorer)
  6. Avatar de Tidus159
    • |
    • permalink
    Bonjour Hamid,
    tombé par hasard sur ton article intéressant, j'aimerais approfondir la stratégie de mise en place des index.

    Dans ton exemple où l'index n'est pas pris en compte, une personne logique se dirait "bon je vais donc en rajouter un autre (vu que je fais aussi souvent cette restriction)".
    Il crée donc un autre index. Plus tard, une nouvelle colonne apparait ainsi que de nouvelles requêtes, donc la personne ajoute encore un index...

    Mes questions sont donc plutôt généralistes tout en restant pratiques :
    - Quand doit-on véritablement considérer la mise en place d'un index ? (faut-il tester 10 requêtes et comparer les moyenne des temps d'exécution avec-sans index, sur le papier cela semble OK mais en réalité c'est assez long ! La mise en place d'un index pour une seule requête peut-elle être justifiée ?)
    - A partir de quand, trop d'index peut diminuer les performances ? Y-a-t-il des moyens de le savoir ?

    (Bien que je ne sois pas réellement dans l'administration de bd, je m'instruis un peu :-))
    Merci,
    A+,
    Emilien.
    Mis à jour 15/01/2015 à 12h52 par Tidus159
  7. Avatar de hmira
    • |
    • permalink
    Citation Envoyé par dsr57
    Dans le cas d'une clause WHERE avec les colonnes suivantes DateNaissance, Sex ; l'index est utilisé ?
    La réponse est OUI. L'index pourra éventuellement être retenu par l'optimiseur. En fait, ce qui importe, c'est la première colonne de l'index. Dès lors que la première colonne de l'index, en l'occurrence DateNaissance, est utilisée dans la clause WHERE, bien entendu dans une expression SARG, l'index est susceptible d'être utilisé par l'optimiseur de requête. Cela ne veut pas dire qu'il le sera forcément, mais il a toutes ses chances à ce qu'il soit retenu par l'optimiseur.

    A+
  8. Avatar de dsr57
    • |
    • permalink
    Merci pour ce billet qui est intéressant et précis.

    Je me pose une question, dans le billet, tu précises :

    Les clauses WHERE référençant les colonnes suivantes :
    DateNaissance
    ou DateNaissance, SituationMatrimoniale
    ou DateNaissance, SituationMatrimoniale, Sex

    Pourront le cas échéant bénéficier de l'index
    Dans le cas d'une clause WHERE avec les colonnes suivantes DateNaissance, Sex ; l'index est utilisé ?

    Merci par avance, bon dev

    Dsr57. V - Formet.