Discussion :

[leilusha]

Bonsoir,
j'utilise comme SQL-server Wampserver (PHPMyAdmin) j'ai créer une table avec un auto_increment id,et après que j'ai insérer trop d'information je me suis rendu compte que j'ai oublier d'insérer d'autres informations au milieu de la table, est ce qu'il y a une méthode pour insérer au milieu de la table sachant que le id (clé) est auto_increment,
PS : j'ai pensé de décalé mes informations insérées depuis la fin de la table et comme ça je crée un espace au milieu de la table c'est une solution oui, mais ça demande beaucoup de travail, est ce qu'il y a une méthode plus optimal? Merci,

Cordialement.

[kevin254kl]

Bonsoir, avec une boucle peut-être?

[CinePhil]

Ouch !

j'utilise comme SQL-server Wampserver (PHPMyAdmin)

SQL Server, c'est le serveur SQL de Microsoft.
phpMyAdmin, c'est un logiciel qui permet de faciliter l'administration et la gestion des bases de données MySQL.

Vous avez donc installé Wampserver qui comprend, comme son nom l'indique, pour Windows (W), Apache (A), MySQL (M) et PHP (P).

j'ai oublier d'insérer d'autres informations au milieu de la table

Une table est comme un sac. Il n'y a pas de début, de milieu, de fin. Si je jette une bille dans un sac qui en contient déjà et que je vous demande de retrouver la bille que je viens d'y jeter, vous serez bien embêté ! Ben une table SQL, c'est pareil. On extrait des informations de la table en posant des conditions dans la partie WHERE d'une requête SQL.

j'ai insérer trop d'information je me suis rendu compte que j'ai oublier d'insérer d'autres informations

Si vous avez oublié d'insérer des lignes dans la table, ben insérez les maintenant. Elles prendront automatiquement les identifiants auto-incrémentés suivants mais on s'en fout car un identifiant n'est qu'une clé technique sans signification. Par exemple, dans la table des utilisateurs de ce forum, que leilusha porte l'identifiant 18524 ou 325789 n'a aucune importance. Quand elle se connecte, pour vérifier si elle a saisi le bon mot de passe, on fait ce genre de requête :

Code :

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

1
2
3
4
SELECT usr_id
FROM te_user_usr
WHERE usr_login = 'leilusha'
    AND usr_password = MD5(':password_saisi')

Si la requête retourne un résultat, c'est que le mot de passe est le bon.

Un identifiant auto-incrémenté sert pour la clé primaire de la table et NE DOIT JAMAIS ÊTRE MODIFIÉ !

[pier.antoine]

Et pour ajouter une précision, évidente pour beaucoup, mais que j'ai eu du mal à saisir à mes début, l'auto incrément permet que chaque ligne ait un identifiant unique. D'où la possibilité d'y mettre une clé primaire.

Enfin, arrêtez moi si je dis une bêtise.
pierre

[Artemus24]

Salut leilusha.

Pour ajouter de nouvelles colonnes à votre table, utilisez la commande ALTER TABLE comme ci-après :

Code :

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

1
2
ALTER TABLE nom_table
ADD nom_colonne type_donnees

Maintenant que vous avez vos nouvelles colonnes, vous devez appliquer un UPDATE, en partant de la clef de votre table.

Code :

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

1
2
3
UPDATE nom_table
SET colonne = expression
WHERE CLEF = valeur

Si vous avez utilisé un auto incrément, vous devez retrouver le même ordre pour effectuer le UPDATE.

Ne sachant pas comment vous avez procédé pour insérer vos premières lignes et comment vous allez faire pour ajouter vos colonnes manquantes, il est difficile de vous répondre correctement.

@+

[Artemus24]

Salut Pier.Antoine.

Et pour ajouter une précision, évidente pour beaucoup, mais que j'ai eu du mal à saisir à mes début, l'auto incrément permet que chaque ligne ait un identifiant unique. D'où la possibilité d'y mettre une clé primaire.

Pour obtenir une clef primaire, vous devez utiliser un identifiant qui sera unique. Pour ce faire, l'auto incrément est une solution.
Mais si dans votre fichier excel, vous avez déjà un identifiant qui rend la ligne unique, il serait plus judicieux de l'utiliser.

Votre identifiant n'a pas obligation d'être sur une seule colonne.
Vous pouvez créer une clef primaire sur plusieurs colonnes. Le tout doit, bien sûr, être unique.

@+

[CinePhil]

Mais si dans votre fichier excel, vous avez déjà un identifiant qui rend la ligne unique, il serait plus judicieux de l'utiliser.

Si l'identifiant des données sources est de type alphanumérique, il vaut mieux ajouter un auto-incrément et s'en servir comme clé primaire de la table. Surtout si le volume de données est important. Oui, je sais, avec un fichier Excel, le volume de données reste limité mais il peut s'agir de plusieurs fichiers Excel à insérer dans la même table.

[pier.antoine]

Bonjour à tous

Et au-delà du volume de données considérées, ne vaut-il pas mieux prendre des habitudes dès le départ? Un identifiant numérique auto-incrémenté, me semble être la meilleure solution pour repérer chaque ligne d'une table.
Même sur des table à 2 lignes, je mets un identifiant numérique.

Pierre

[CinePhil]

Et au-delà du volume de données considérées, ne vaut-il pas mieux prendre des habitudes dès le départ? Un identifiant numérique auto-incrémenté, me semble être la meilleure solution pour repérer chaque ligne d'une table.

Tout à fait !

[Artemus24]

Salut à tous.

ne vaut-il pas mieux prendre des habitudes dès le départ?

Tu voulais certainement dire : "prendre de bonnes habitudes dès le départ ?"

La question que tu soulèves est intéressante, mais l'appliquer dans tous les cas n'est pas très judicieux.
Et cela viendrait en contradiction avec les bonnes habitudes dont tu veux faire l'apologie.

Un identifiant numérique auto-incrémenté, me semble être la meilleure solution pour repérer chaque ligne d'une table.

D'abord as-tu besoin systématiquement d'une colonne auto incrémentée ?
NON, car parfois tu as déjà une ou plusieurs colonnes qui peuvent jouer le rôle d'une clef primaire.
Cette colonne auto incrémentée n'aurait qu'un rôle secondaire, voire inutile, juste pour te rassurer que la ligne soit bien unique dans la table.
Et ensuite, il n'est pas négligeable d'ajouter pour chaque ligne, par exemple une colonne de type INT (= 4 octets).
Sur des millions de lignes, cela augmente la volumétrié de 4 millions d'octets. Est-ce judicieux de procéder ainsi ?

Ensuite, la colonne auto incrémentée est-elle porteuse d'une information liée à cette table ?
La réponse est NON, car elle n'a qu'un rôle technique, celui de donner une clef primaire à ta table. Mais est-ce franchement utile ?

Parfois OUI car il faut bien accéder à cette ligne, d'une manière ou d'une autre quand on n'a pas une clef de substitution.
Mais parfois NON car il faut connaitre le rôle que va jouer cette table dans ta base de données.
L'exemple d'une table ayant le rôle d'un fichier de mouvement n'a pas besoin d'avoir une clef primaire.
Chaque ligne doit être traité séparément, même si des doublons peuvent exister. Et quand la table a été traité, on la remet à vide.

Ensuite, est-il utile d'avoir systématiquement une clef primaire sur une table ? Cela dépend de l'usage que l'on va faire de cette table.

Sur de très grosses tables cela permet d'améliorer les temps d'accès. Mais en général, c'est l'usage d'un index qui permet d'améliorer les performances.

Si le fichier Excel était déjà utilisé dans une application, et que l'on change de support (le stocker dans MySql), pourquoi ne pas utiliser les clef déjà existantes ?
Le support ne change pas les fonctionnalité applicatives, mais le rend plus souple à l'usage.

Croyez-vous que l'usage d'une colonne auto incrémenté soit judicieuse, si en permanence, sur cette table, vous faites des suppressions et des insertions de lignes ?
Je suppose que la nouvelle ligne va s'insérer en augmentant la valeur maximal de l'auto incrément de +1 avant de l'insérer dans la table.
Et que ferez-vous si vous atteignez le maximum du stockage du type utilisé par votre colonne auto incrémenté ?
Vous allez alors pratiquer une réorganisation de cette table qui vous sera coûteuse en temps et sujette à des erreurs, juste pour avoir dès le départ, fait le mauvais choix.

En conclusion, je dirais qu'il n'y a pas systématiquement des bonnes ou des mauvaises habitudes, mais juste des cas particuliers.
Il convient de réfléchir à la solution la mieux adaptée à l'usage de la table que vous êtes en train de créer.

@+

[pier.antoine]

Bonjour et merci pour votre analyse pour laquelle je suis globalement d'accord.

Ce qui me gène c'est qu'on propose des cas particuliers à des personnes qui ne maîtrise pas les fondements des bases de données. Je pense sincèrement que cela risque de les perturber.

Car, OK, on peut se passer de colonne auto-incrémentée, comme vous l'avez très bien démontré. On peut créer une clé primaire sur plusieurs colonnes.
Mais quand on débute, cela semble du charabia.

Pour ma part, je préfère comprendre le fonctionnement avec des principes simples (chaque ligne a un id unique), pour ensuite, une fois la maîtrise atteinte, passer à des principes un peu plus complexe (clé primaire sur plusieurs colonnes).


Pierre

[Artemus24]

Salut Pier.antoine.

Pourquoi avez-vous besoin de créer une table avec une clef primaire ?
Réponse : pour accéder à la ligne, d'une manière unique.
Donc si cela n'a pas été pensé dès le départ, lors de la construction de votre base de données, il y a une erreur de conception.

C'est cela qui me dérange le plus ! D'où la solution d'ajouter une colonne auto incrémenter pour palier à ce manque.

Est-ce à cause d'une mauvaise compréhension du schéma de la base de données ?
Question : n'y a-t-il pas un administrateur pour expliquer à ce développeur comment est conçu la base de données ?
Si la base a été conçue par un administrateur, comment se fait-il que ce développeur se permet de modifier le schéma ?
Et le cahier des charges, normalement, doit expliquer ce que le développeur doit entreprendre comme développement.

Autre question : y-a-t-il un administrateur de base de données ? Si la réponse est non, c'est bien plus grave.
Comment quelqu'un qui ne maîtrise pas le sujet, peut concevoir une base de données, en répondant à des problématiques de performances et de fonctionnalités.

Ce que vous nommer charabia, en fait, c'est l'arbre qui cache la forêt.

@+

[pier.antoine]

Bonsoir

Nous avons un peu de mal à se comprendre.

Ce que vous dites est vrai, juste. Mais cela nécessite des connaissances théoriques, des apprentissages pratiques.

Oui, dans un monde parfait, il y a des concepteurs, des analystes, des administrateurs, des développeurs...

Mais, dans la réalités, et sur ce forum, beaucoup de personnes ne sont pas professionnels.

Je cite :

Comment quelqu'un qui ne maîtrise pas le sujet, peut concevoir une base de données, en répondant à des problématiques de performances et de fonctionnalités.

Vous faites erreurs !
Ce quelqu'un maîtrise le sujet !!
Il ne maitrise pas par contre la conception de base de données, mais ils en ont une idée, intuitive, empirique.

Et il essaye de concevoir des outils qui va leur faciliter la vie (chez eux, au boulot....).

Le mieux serait de passer par les services adéquat (en interne ou en externe), mais ... ce n'est pas la priorité, il n'y a pas les fonds, ou alors des expériences désastreuses font qu'on n'a pas plus confiance dans ceux du métiers que dans ses propres capacités.

Alors oui, la conception est primordiale, fondamentale. Mais n'est pas accessible facilement.
Beaucoup tâtonnent. Font et défont. Reprennent tout depuis le début.
Pour cela, il me semble important de leur donner de bonnes habitudes dans l'utilisation des outils sql, et petits à petits les amener à la conception.

Ciao!
Pierre

[Artemus24]

Salut pier.antoine.

Nous avons un peu de mal à se comprendre.

Non, je ne crois pas, mais nous ne parlons pas de la même chose. Je parle des professionnels alors que vous parlez des amateurs.

Ce quelqu'un maîtrise le sujet !!

Je répondrais que non. Un sujet, ce n'est pas qu'un aspect de la question posée.
Un sujet, c'est d'abord la fonctionnelle, ensuite la conception avec les choix qui en découlent, puis le développement (langage) et enfin la maintenance.
En un mot, c'est un "tout".

Alors oui, la conception est primordiale, fondamentale. Mais n'est pas accessible facilement.

A chacun son métier. Le tort est que l'on confie des activités à des personnes qui n'ont pas eu les formations adéquates.
Pourquoi ? Car on veut faire des économies sur le dos de ces personnes !
Et ensuite, on s'étonne ou pire, on ne veut pas comprendre, que l'application ne fonctionne pas bien.
Tant que l'on ne veut pas mettre les moyens ni les bonnes personnes aux bons postes, on aura toujours des problèmes de conceptions et de performances.

Maintenant, la question fondamentale est ce que recherche le demandeur de cette application ?

@+

[SQLpro]

...
D'abord as-tu besoin systématiquement d'une colonne auto incrémentée ?
NON, car parfois tu as déjà une ou plusieurs colonnes qui peuvent jouer le rôle d'une clef primaire.

Malheureusement dans TOUS les SGBDR sans exception, la constitution d'une clef primaire multi colonne dégrade les performances par rapport au rajout d'une clef artificielle de type mono colonne du genre auto incrément... En effet, pour l'optimiseur qui se base sur des statistiques pour prédire les algorithmes à utiliser dans les opérations physiques de jointure (boucle imbriquées, tri fusion, jointure en hash, concaténation...), le calcul de la cardinalité de la jointure (nombre de ligne en jeu) se base sur les statistiques de la première colonne et rarement d'une combinaison de colonnes, qui de toutes les façons donnerait une incertitude d'estimation très grande (combinaisons de statistiques => augmentation de l'incertitude au ²)...

...

Ensuite, la colonne auto incrémentée est-elle porteuse d'une information liée à cette table ?
La réponse est NON, car elle n'a qu'un rôle technique, celui de donner une clef primaire à ta table. Mais est-ce franchement utile ?

Oh que oui ! Tout clef primaire devrait être asémantique. Une clef primaire composite est la plupart du temps prise sur des colonnes sémantique, ce qu'il ne faut jamais faire.... Je vous renvoi vers les multiples écrits de fsmrel qui cite des sources ancienne datant des années 80 mettant en évidence ce problème... Quid par exemple du changement de valeur d'une clef primaire sémantique ???

Parfois OUI car il faut bien accéder à cette ligne, d'une manière ou d'une autre quand on n'a pas une clef de substitution.
Mais parfois NON car il faut connaitre le rôle que va jouer cette table dans ta base de données.
L'exemple d'une table ayant le rôle d'un fichier de mouvement n'a pas besoin d'avoir une clef primaire.

Hélas, votre croyance manque cruellement d'expérience.... Je sort justement de démontrer cette problématique sur une table de 6 milliards de ligne (téléphonie) pour laquelle aucune clef primaire n'avais été mis. Il n'y avait que des ajouts, quelques rares suppressions (une fois par jour) et très peu de lectures (quelques lignes par semaine). La simple pose d'une clef primaire a réduit les temps de réponse des insertions, tout simplement parce que le SGBD n'a plus à parcourir toutes les pages de la table pour trouver un emplacement libre. Il va droit au but dans le sens de l'index !

...

Ensuite, est-il utile d'avoir systématiquement une clef primaire sur une table ? Cela dépend de l'usage que l'on va faire de cette table.

Vous oubliez simplement qu'en matière de BD relationnelle, toute table doit avoir une clef par définition, et les moteurs des SGBDR sont conçus spécialement dans ce sens et non pas pour traiter des tables sans clef.... Et lorsque l'on va a l'encontre d'un système, quel qu'il soit, cela ne peut que marcher moins bien.

Sur de très grosses tables cela permet d'améliorer les temps d'accès. Mais en général, c'est l'usage d'un index qui permet d'améliorer les performances.

Dans tous les SGBDR la pose d'une clef se traduit par un index particulier : UNIQUE et NON NULL. Le simple fait de n'être pas unique ou nullable pose des problèmes pour les index ! par exemple sous Oracle, les index ne sont pas performant pour les NULLs !

....

Croyez-vous que l'usage d'une colonne auto incrémenté soit judicieuse, si en permanence, sur cette table, vous faites des suppressions et des insertions de lignes ?

Dans tous les cas oui ! Prenez au moins le temps d'expérimenter et de teste au lieu d'affirmer des inepties théoriques...

Je suppose que la nouvelle ligne va s'insérer en augmentant la valeur maximal de l'auto incrément de +1 avant de l'insérer dans la table.
Et que ferez-vous si vous atteignez le maximum du stockage du type utilisé par votre colonne auto incrémenté ?
Vous allez alors pratiquer une réorganisation de cette table qui vous sera coûteuse en temps et sujette à des erreurs, juste pour avoir dès le départ, fait le mauvais choix.

Visiblement vous ne maitrisez pas le sujet. Les auto incréments se recyclesnt se réajustent. Il faut simplement savoir le faire !!!! Le type BIGINT permet d'aller de -9223372036854775808 à 9223372036854775807. En insérant 1 milliards de lignes par seconde, vous en arriverez à bout dans 292 ans...

En conclusion, je dirais qu'il n'y a pas systématiquement des bonnes ou des mauvaises habitudes, mais juste des cas particuliers.

Sauf à faire des bases de données non relationenlles dans un SGBD Relationnel (ce qui serait une parfaite imbécilité...) il y a des bonnes pratiques systématiques, et parmi ces bonnes pratiques toute table devrait avoir une clef, la plus petite possible en octets, bien entendu UNIQUE et NOT NULL et surtout asémantique !

Il convient de réfléchir à la solution la mieux adaptée à l'usage de la table que vous êtes en train de créer.

@+

A +

[CinePhil]

Ceci dit, Fred, tu ne préconises tout de même pas d'ajouter un auto-incrément à une table associative ?

[SQLpro]

Cela dépend...
Si la longueur de la clef d'index de la PK est supérieure à la longueur du mot du processeur, c'est plutôt payant.
Autrement dit :
Si table associative composée de 2 colonnes INT et OS 64 bits => 2 int de 32 bits = 64 o => je change rien
Si table associative composée de 3 colonnes INT et OS 64 bits => 3 int de 32 bits = 96 o => alors
1) transformation de la PK en UNIQUE
2) ajout d'une PK auto inc.

A +

[escartefigue]

Je souscrit à l'ensemble des commentaires de SQLPro et j'ajoute
- Outre les perfs moindres, une clef composée de nombreuses colonnes est pénible à utiliser dans les critères de jointures et complexifie inutilement les requêtes
- Une clef composée de nombreuses colonnes rend l'exécution des runstat plus longue
- meme si des tables ont des volumes modestes, des requetes imbriquées de type outer join peuvent vite produire des volumes considérables, et sans index ca devient la catastrophe

[Artemus24]

Salut SQPRO.

Malheureusement dans TOUS les SGBDR sans exception, la constitution d'une clef primaire multi colonne dégrade les performances par rapport au rajout d'une clef artificielle de type mono colonne ...

Je ne dis pas le contraire.

... du genre auto incrément...

Mais pourquoi choisir ce type de colonne ?
Je pense que ce choix est fait systématiquement, par méconnaissance de ce que l'on peut faire. Autrement dit solution de facilité.
Croyez-vous qu'une clef mono colonne se résume à mettre une colonne auto incrémenté ? NON !

En effet, pour l'optimiseur qui se base sur des statistiques pour prédire les algorithmes à utiliser dans les opérations physiques de jointure (boucle imbriquées, tri fusion, jointure en hash, concaténation...), le calcul de la cardinalité de la jointure (nombre de ligne en jeu) se base sur les statistiques de la première colonne et rarement d'une combinaison de colonnes, qui de toutes les façons donnerait une incertitude d'estimation très grande (combinaisons de statistiques => augmentation de l'incertitude au ²)...

Vous entrez dans une autre problématique que celle que je tente de soulever. Croyez-vous que toutes les tables font six milliards de lignes ? Ou que l'on fasse des jointures hyper compliquées ?

Tout clef primaire devrait être asémantique. Une clef primaire composite est la plupart du temps prise sur des colonnes sémantique, ce qu'il ne faut jamais faire....

Vous mélangez deux notions. Je ne parle pas d'une clef construite par l'association de plusieurs colonnes mais d'une clef porteuse d'une information.
Exemple : les comptes bancaires que l'on identifie par le RIB, ou le IBAN sont des identifiants porteuses d'informations.
Donc selon vous, les banques auraient tort de procéder ainsi ?

Quid par exemple du changement de valeur d'une clef primaire sémantique ???

N'importe quoi ! Depuis quand la valeur d'une clef primaire doit-elle changer ?
Si c'est le cas (ce qui est peu probable), votre clef est mal choisie et nécessite de revoir la conception de votre base de données.
La valeur d'une clef ne doit jamais changer au cours de la vie d'une ligne. C'est une condition primordiale au bon fonctionnement d'une base de données.
Voilà un exemple de votre méconnaissance du sujet.

Et au cas où cela arriverait, on fait quoi ? On fait une migration de la base de données qui passe à une nouvelle version, ainsi que les scripts qui sont associés.
C'est une démarche très lourde à faire et nécessite du temps et des moyens. Mais je suppose que vous n'êtes pas coutumier de ces migrations. D'ailleurs en avez-vous déjà faite au moins une ?

Je sors justement de démontrer cette problématique sur une table de 6 milliards de ligne (téléphonie) pour laquelle aucune clef primaire n'avait été mise. Il n'y avait que des ajouts, quelques rares suppressions (une fois par jour) et très peu de lectures (quelques lignes par semaine). La simple pose d'une clef primaire a réduit les temps de réponse des insertions, tout simplement parce que le SGBD n'a plus à parcourir toutes les pages de la table pour trouver un emplacement libre. Il va droit au but dans le sens de l'index !

Mais qui aurait l'idée de construire une table sans clef primaire, ni index sur une volumétrie de six milliards de lignes ?
Et qui aurait l'idée de laisser une table se dégrader sans faire de temps en temps une réorganisation afin de maintenir les performances à un niveau acceptable ?

Le seul argument que vous ayez, est de prendre une exception qui vient étayer vos propos ???

toute table doit avoir une clef par définition

J'ai surtout l'impression que vous ne savez pas ce qu'est une base de données ayant l'organisation relationnelles ?
Ni pourquoi elle est venue supplanter l'organisation de type hiérarchique ou réseau ?
Si vous dites que c'est pour mettre des tables en relation, que croyez-vous que les autres organisations faisaient ?
Question performance l'organisation réseau supplante largement le relationnelle.

les moteurs des SGBDR sont conçus spécialement dans ce sens et non pas pour traiter des tables sans clef

Vous confondez organisation et performance !

Et lorsque l'on va à l'encontre d'un système, quel qu'il soit, cela ne peut que marcher moins bien.

Il faudrait encore savoir comment cela fonctionne.

une clef se traduit par un index particulier : UNIQUE et NON NULL

Est-ce votre définition de la clef primaire ? Ne croyez-vous pas que cela soit redondant avec l'index ?
Et que fait la clef primaire, que ne fait justement pas l'index ? Je vous laisse chercher.

Prenez au moins le temps d'expérimenter et de teste au lieu d'affirmer des inepties théoriques...

Autre exemple de votre méconnaissance du sujet.
En utilisant une clef auto indexée, une nouvelle ligne vient systématiquement s'insérer en fin de table.
Tandis que la suppression de la ligne laisse l'espace de cette ligne innocupé.
Et c'est quoi le problème ? Réponse ci-après.

Visiblement vous ne maitrisez pas le sujet.

Je suppose que vous n'avez jamais entendu parler de la réorganisation de vos tables, juste pour maintenir celle-ci dans une performance acceptable.
Mais dans tous vos arguments, nul part vous aborder cette question de la réorganisation qui est pourtant primordiale quand on est un administrateur.
Ah oui, vous êtes prof. Ca explique tout.

@+

[escartefigue]

On peut sans doute reprocher à SQLpro d'être souvent franc du collier, voire franchement discourtois, mais pas de méconnaitre les bases de données ;-)

Par ailleurs comme je l'ai mentionné plus haut, il n'est pas nécessaire d'avoir des milliards de lignes dans des tables pour rencontrer des perfs déplorables

Répondre dans l'absolu sur une stratégie n'est bien sur qu'indicatif, le contexte local peut parfois mettre des bémols à ce qui est le plus souvent vrai.

Pour ma part, ayant plus de 10 ans d'experience dans les projets de migration et de convergence d'entreprises dans le monde mainframe et distribué, c'est à dire des projets qui concernent plusieurs dizaines de bases de données comportant des tables avec des centaines de millions de lignes voir plusieurs milliards, à transporter en un week end pour ne pas interrompre les métiers, je confirme les préconisations de SQL-Pro