Salut a tous
 
Je dois faire migrer une datawarhouse et en meme temps l'optimiser.
Pour l'optimiser, je dois tout re-concevoir. Lors de la conception, plusieurs choix se pose et je n'arrive pas a déterminer lesquelles sont les meilleurs.
 
Voici quelques questions que je me pose:  
la base de destination est un SQL server.
 
1: J'ai une table personne contenant 270 000 tuples et beaucoup de champs (24).
Une autre table (utilisation) comporte seulement un champs id_personne (clé etrangere de la table personne) et 6 booleens.
Es ce utile de laisser les deux tables séparées ou vaut il mieux les fusionner sachant que les donnees de la table (utilisation) ne sont utiles que pour 10% des personnes de la table personne ce qui augmenterai encore plus la taille de la table fusionnée
 
2: Es ce qu'un clé primaire composé de type entier avec l'option auto incrmente est plus performant qu'un champs de varchar(8)
 
merci d'avance pour votre aide

1: une possibilité est de les laisser séparées mais tu crée une vue matérialisée qui fusionne les deux tables pour les personnes utiles.
 
2: a mon avis le type entier est mieux que varchar, mais je ne saurais dans quelle proportion.

1/ Un BOOL, logiquement, ça prends 1 bit. Par contre, SQL Server ne sait pas faire un champ de 1 bit, c'est juste le type byte (8 bits) qui est surchargé avec deux valeurs possibles. Donc, ça fera 270 000 * 6 octets de plus, soit 1,6 Mo de plus. C'est donc pas une perte de données importante. En revanche, regarde dans tes requêtes si tu fais des jointures droites pour récupérer les booléens à partir de la table parente. Si c'est le cas, alors il y a une grosse perte de performance par rapport à tout fusionner. Je pense donc que la fusion des deux tables une solution tout à fait envisageable.
 
2/ Tout dépend si le champ est indexé ou non. Si c'est le cas, alors il n'y aura pas de différence significative de perfs significative entre un type entier et un varchar. Choisi donc le type en fonction de ton besoin, l'aspect performance pouvait être mis de côté.
PS: dans ce cas, évite un maximum de faire des CAST(id as number) à tout bout de champ, parceque :
a/ L'index ne sera plus utilisable
b/ La conversion de type est très lente, donc tu vas perdre énormément de temps !

Pour la question 1 je me suis un peu trompé dans la def c'etais 3 bool et 3 date mais cela peut etre optimiser par seulement 3 date. Je pense faire fusionner les deux table pour eviter les jointures
pour la question 2, je pense que je vais recréer un clé (int autoincremante) afin d'etre sur que cela optimise la vitesse meme si c'est peut etre l'equivalent.  
 
Je ne comprend pas bien ce qu'est le cast. Es ce la conversion d'un int en varcahr ?
l'ancienne clé comportais un 4 lettres et 4 chiffres le tout dans un type varchar(8)

oui, le cast permet de faire une conversion.
 
si y'a déjà des ID existants avec des lettres, laisse-les, tu gagneras RIEN en perfs.
En plus, si ton volume de données est important, ton number (pas un int ! tu fais comment quand t'as plus de 65000 lignes ?) sera très certainement plus long que 64 bits de toute façon...
 
Cf. la doc du type "numeric", que tu es obligé d'utiliser sans ton cas... A moins que tu utilises un BIGINT, qui de toute façon fait aussi 64 bits.

je ne me suis pas renseigné sur le type que j'allais utilisé mais quand je parlais de int je rassemble tous les types d'entier, de shortint à bigint.
 

Tu seras obligé de passer par un bigint, puisque c'est le seul à pouvoir contenir 270000 valeurs possibles. Ou alors le NUMERIC, mais à ce moment il sera encore plus énorme.
 
Dans tous les cas, laisse tomber, y'a aucun intérêt à faire ça, ormis péter toute la base et faire râler les utilisateurs qui sont habitués à cet ancienne nommenclature pour les ID.