Discussion :

[carjo]

Bonjour,

Dans l'aide MSDN pour SQL Server 2005, il est mentionné que nous ne pouvons effectuer de répartition de tables qu'à l'intérieur d'une seule BD:

Référence: http://msdn.microsoft.com/fr-fr/libr...7(SQL.90).aspx

Même remarque pour SQL Server 2008.

Les données des tables et des index partitionnés sont divisées en unités qui peuvent être réparties sur plusieurs groupes de fichiers d'une base de données. Les données sont partitionnées horizontalement, de sorte que les groupes de lignes sont mappés à des partitions individuelles. La table ou l'index est traité en tant qu'entité logique unique lorsque des requêtes ou des mises à jour sont effectuées sur les données. Toutes les partitions d'un index ou d'une table unique doivent résider dans la même base de données.

À part la solution manuelle ou semi-manuelle, existe-t-il une façon d'implémenter une architecture nous permettant de fractionner une table sur plusieurs base de données distinctes et peut être même sur plusieurs serveurs distincts ?

Quelqu'un a-t-il déjà expérimenté une telle solution ?

Merci.

[SQLpro]

À part la solution manuelle ou semi-manuelle, existe-t-il une façon d'implémenter une architecture nous permettant de fractionner une table sur plusieurs base de données distinctes et peut être même sur plusieurs serveurs distincts ?

Cette solution "pseudo manuelle" est en fait à élaborer manuellement mais reste transparente une fois mise ua point :
1) définir les critères de partitionnement sur une colonne NOT NULL
2) sur chaque base de données mettre en place une contrainte CHECK sur cette colonne de partitionnement en faisant attention qu'il n'y ait aucun chevauchement
3) implémenter pour la table partitionnée un lot de 3 triggers INSTEAD OF

Exemple :
Soit la table T_COMPTA_CPT (CPT_ID PK, CPT_DATE DATETIME, CPT_OPERATION....)

1) sur base 1

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
ALTER TABLE T_COMPTA_CPT
   ADD CONSTRAINT CK_PARTITION CHECK (CPT_DATE < '20090101')

2) sur base 2

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
ALTER TABLE T_COMPTA_CPT
   ADD CONSTRAINT CK_PARTITION CHECK (CPT_DATE >= '20090101')

3) trigger INSERT :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
CREATE TRIGGER E_II_CPT
ON T_COMPTA_CPT 
INSTEAD OF INSERT
AS
INSERT INTO Base1..T_COMPTA_CPT
SELECT * FROM inserted WHERE CPT_DATE < '20090101'
INSERT INTO Base2..T_COMPTA_CPT
SELECT * FROM inserted WHERE CPT_DATE >= '20090101'

etc....

[carjo]

Merci beaucoup pour votre réponse.

3) implémenter pour la table partitionnée un lot de 3 triggers INSTEAD OF

Q1: par les 3 triggers entendez-vous les l'implémentation de trigger pour les actions: INSERT, UPDATE et DELETE (si ceci s'applique) ?

Q2: est-il plus prudent d'implémenter également un trigger AFTER ou ceci risque-t-il d'alourdir le système davantage ?

Merci.

[SQLpro]

Q1: par les 3 triggers entendez-vous les l'implémentation de trigger pour les actions: INSERT, UPDATE et DELETE (si ceci s'applique) ?

Oui.

Q2: est-il plus prudent d'implémenter également un trigger AFTER ou ceci risque-t-il d'alourdir le système davantage ?

Un tel trigger n'a pas de sens dans cette mécanique.

A +

[carjo]

Merci pour l'info.

Sur http://msdn.microsoft.com/fr-fr/libr...(SQL.90).aspx:

Les déclencheurs INSTEAD OF UPDATE et DELETE ne sont pas autorisés sur des tables qui sont des cibles de contraintes d'intégrité référentielle en cascade.

Nous devrons effectuer des mises à jours régulièrement sur les tables partitionnées. Dans ce cas, est-il approprié d'utiliser un trigger AFTER ?

Sinon, quelle serait la meilleure façon de contrôler les mises à jours dans un tel contexte ?

Merci.

[SQLpro]

il n'est jamais conseillé d'utiliser le mode CASCADE dans les IRD. Préférez le SET NULL ou SET DEFAULT. Travaillez avec des vues (en principe on ne doit jamais attaquer les base de données directement avec des tables on devrait toujours passer par des vues...). Utilisez des batch de nuit pour nettoyer vos tables.

A +

[carjo]

D'accord.

Mais la question demeure: si on élimine la contrainte en cascade, est-il approprié d'utiliser un trigger AFTER pour les mises à jour dans ce contexte ?

Merci.

[carjo]

Est-ce que le fait de mettre en oeuvre une telle architecture en SQL Server 2000 plutôt qu'un SQL Server 2005 peut avoir certain(s) désavantage(s) ? Si oui, quels seraient-ils ?

Merci.