none
SQL SERVER - Base de données - Méthodologie RRS feed

  • Question

  • Bonjour,

    Pour des raisons évidentes, je souhaiterais dissocier les données de mes procédure stockées et fonctions de manière à bien conserver l'indépendance des données de mes procédures (surtout si elles contiennent des procédures "métier").

    Est on obligé de les placer dans une autre instance de base?

    Je demande ça parce que chez les hébergeurs on est limité souvent à 2 instances.
    Comment organisez vous vos bases SQL SERVER en général?

    François
    mercredi 24 février 2010 18:44

Réponses

  • Bonsoir,

    Pourquoi voulez vous dissocier "géographiquement" vos procédures stockées de vos données ?
    Vos données de manière générale seront toujours indépendantes du code métier que vous implémenterez (fonctions, procédures etc...).

    Je vois 2 problèmes évidents à faire cela :

    - Vous rajoutez un élément physique pour héberger vos procédures ce qui augmente la probabilité d'indisponiblité de vos données. Si l'une ou l'autre de vos instances tombe en panne vos données seront indisponibles d'une manière ou d'une autre.

    - Pour accéder à vos données depuis vos procédures vous allez devoir exécutez des requêtes à transaction distribuée très probablement, ce qui augmente les éventuels problèmes de performance et l'incohérence de vos données

    ++


    MCDBA | MCITP SQL Server 2005 | MCTS SQL Server 2008 | LPI Linux 1
    mercredi 24 février 2010 21:07
    Modérateur

Toutes les réponses

  • Bonjour Fançois,

    Je ne comprends pas exactement ce que tu souhaites faire.

    Pourquoi ne pas conserver tes procedures stockées dans la même base que tes données ?
    Alors y'a dû y avoir un truc qui m'a échappé, parce que manifestement pour toi il y a des raisons évidentes à ne pas faire comme cela, et je ne les vois pas.
    Pourrais-tu m'éclairer là-dessus ?

    Personnellement, quand j'ai des procedures stockées, elles sont dans la même instance de base que les données.

    Cordialement,

    Thomas
    Thomas Aimonetti - C# - Sharplog Engineering - http://www.sharplog.fr
    mercredi 24 février 2010 19:18
  • Bonsoir,

    Pourquoi voulez vous dissocier "géographiquement" vos procédures stockées de vos données ?
    Vos données de manière générale seront toujours indépendantes du code métier que vous implémenterez (fonctions, procédures etc...).

    Je vois 2 problèmes évidents à faire cela :

    - Vous rajoutez un élément physique pour héberger vos procédures ce qui augmente la probabilité d'indisponiblité de vos données. Si l'une ou l'autre de vos instances tombe en panne vos données seront indisponibles d'une manière ou d'une autre.

    - Pour accéder à vos données depuis vos procédures vous allez devoir exécutez des requêtes à transaction distribuée très probablement, ce qui augmente les éventuels problèmes de performance et l'incohérence de vos données

    ++


    MCDBA | MCITP SQL Server 2005 | MCTS SQL Server 2008 | LPI Linux 1
    mercredi 24 février 2010 21:07
    Modérateur
  • Tu as raison Thomas, je vais expliquer pourquoi je pose cette question.

    J'ai, il y a peu, du mettre en production une nouvelle version de ma base de données.
    Pour ceci, j'ai du récupérer les données de la base de production. 
    Mais vu que j'utilise des clés sur des champs numérique avec incrémentation automatique, j'ai finalement opté pour un mise à niveau de la base de production en modifiant le structure des tables et en créant ou en modifiant les procédures stockées et fonctions.

    J'ai trouvé ceci contraignant et risqué donc, je réfléchis à une structure plus adaptée à l'évolutivité des SGBD.

    François

    vendredi 26 février 2010 08:50
  • Bonjour,

     

    Merci Thomas et Mike pour vos réponses.

     

    Kakworg, de votre question je comprends que vous envisages aussi d’autres modalités de séparation entre les données et les procédures que la création de 2 bases de données ?

     

    Cordialement,

    Alex


    Alex Petrescu - MSFT
    mardi 2 mars 2010 14:25
  • Bonjour,

    Je recherche un moyen optimal pour effectuer des maintenances évolutives et correctives sur mes base de données.
    Ce n'est peut être pas une séparation physique.

    Mon soucis arrive lorsque j'ai besoin de modifier mes procédure stockées dans mon environnement de développement.
    Pour ensuite mettre en production, je sui obligé de faire une script pour mettre à jours la base de données en production.
    Et ce n'est pas toujours très simple selon l'architecture des systèmes de mes clients.
    Je voulais avoir votre avis sur ce sujet. Existe 'il des moyen plus sur et plus simple?

    Cdlt,

    François
    mardi 2 mars 2010 18:56