Discussion :

[Bernardos]

Bonjour,
En fait, la question est autant coté "développement" que coté "Administration".
J'ai un/ des utilisateurs qui veulent pour le besoin d'insertions de données à partir de fichier excel

1. Créer une/des tables provisoires contenant le dit fichier excel, table qui seront supprimées par la suite
2. Créer dans une des tables clés de l'entreprise, un champ provisoire qui sera supprimé par la suite

on part du principe qu'on a qu'un groupfile pour les data

Je suis persuadé que c'est de la connerie de faire ça. le 2 dans tous les cas. le 1 on pourrait imaginer que pas trop si on on a l'occasion de le mettre dans un groupfile différent et pointant sur un autre disque.

J'ai besoin de confronter mon avis et d'avoir l'avis des experts de ce forum. Est-ce que c'est moi qui suis à l'ouest et si non, quels est la liste Exhaustive des impacts négatifs(fragmentations?, statistiques?,) pour le 1 et pour le 2

Moi je dirais
pour le 1.
fragmentation sauf si group file séparé
Créée des io(inutiles) sur la prod

Pour le 2
fragmentation
Crée des io(inutiles) sur la prod

Merci de votre aide

[aieeeuuuuu]

Pour le cas 2, cela va surtout engendrer de la contention, et provoquer la recompilation de toutes les requêtes qui utilisent cette table !!!
je pense qu'il vaut mieux le faire façon partitionnement vertical, en créant une nouvelle table qui reprendra la clef primaire de la table initiale. ainsi on ne touche pas à la table initiale.

Enfin il faudrait en savoir plus sur le pourquoi de tout ça, quel est le contexte, la volumétrie, et surtout le but de l'opération...

[SQLpro]

Bonjour,
En fait, la question est autant coté "développement" que coté "Administration".
J'ai un/ des utilisateurs qui veulent pour le besoin d'insertions de données à partir de fichier excel

1. Créer une/des tables provisoires contenant le dit fichier excel, table qui seront supprimées par la suite
2. Créer dans une des tables clés de l'entreprise, un champ provisoire qui sera supprimé par la suite

on part du principe qu'on a qu'un groupfile pour les data

Je suis persuadé que c'est de la connerie de faire ça.

Pire que ça, c'est parfaitement imbécile !
En effet, une table temporaire devrait être dans la base temporaire QUI NE FONCTIONNE PAS DU TOUT COMME UNE BASE ORDINAIRE.... En effet elle est taillé pour :
1) absorber plus d'accès concurrent (d'ou le fait de créeer de multiple fichier de stockage dedans pour améliorer les performances)
2) les objets ne sont généralement pas physiquement détruit, car il peuvent être réutilisés. Créer un objet coûte cher. Utilisé un objet vide déjà créé coute moins cher... C'est automatique dans SQL Server
3) la journalisation dans une table de production est généralement FULL et dans tempdb elle est SIMPLE, donc moins d'écritures...

Pour une colonne temporaire dans une table c'est encore pire ! En effet, la création de cette colonne requiert un verrou global sur la table ce qui empêche, lecture, écrituer et même acces en référence (toute mise à jour d'une table qui référence la table en cours de modification sera bloquée)...
Alors qu'il serait si simple de faire une jointure de la table avec une table temporaire en 1 à 1...
je ne parle même pas de la fragmentation qui va résulter de l'ajout puis de la suppressions (deux fragmentions différentes...)

le 2 dans tous les cas. le 1 on pourrait imaginer que pas trop si on on a l'occasion de le mettre dans un groupfile différent et pointant sur un autre disque.

J'ai besoin de confronter mon avis et d'avoir l'avis des experts de ce forum. Est-ce que c'est moi qui suis à l'ouest et si non, quels est la liste Exhaustive des impacts négatifs(fragmentations?, statistiques?,) pour le 1 et pour le 2

Moi je dirais
pour le 1.
fragmentation sauf si group file séparé
Créée des io(inutiles) sur la prod

Pour le 2
fragmentation
Crée des io(inutiles) sur la prod

Merci de votre aide

Pourquoi les développeurs ont-ils parfois des idées aussi débiles ?

A +