Discussion :

[M.Max]

Bonjour à tous,

Je suis en train de mettre à jour un programme en vb.net qui gère une bdd sql. Celle-ci est constituée de 250 tables contenant chacune une série temporelle (elle sont mises à jour quotidiennement = 1 enregistrement par date).
Mon problème ai que j'avais créé un champ "ID" (clé primaire) pour pouvoir classer les enregistrements (alors qu'il y a un champ "Date", ne me demandez pas pourquoi j'avais fait ça,...). Donc lorsque j'ai un problème software ou hardware ou autre, je me trouve avec des tables incomplètes. Si je ne peux pas rectifier le tir avant la prochaine MAJ, le champ "ID" s'incrémente automatiquement, quant bien même il me manque un enregistrement pour une date.
Bref, tout ça pour dire que je voudrais virer le champ "ID" pour que la date puisse devenir la clé primaire des tables. Ceci dit, avant de le faire, je voulais être sur de ne pas faire de bêtises : si une date est une clé primaire, et que je fais une requête sql pour aller chercher mes données classées par date, j'obtiendrai bien ma série temporelle chronologiquement ?
Imaginons que le serveur soit down 3 jours, puis que je rectifie les infos seulement 1 semaine plus tard, le simple fait d'envoyer les 3 données manquantes suffira pour retrouver une série temporelle complète ?

Merci de vos lumières, c'est assez simple, mais je voudrais pas massacrer ma bdd !

Maxime.

[elsuket]

Bonjour,

L'ordre en SQL n'existe pas, c'est-à-dire que ni l'ordre des colonnes, ni l'ordre des lignes n'a de sens au niveau de la table.
Il n'a de sens que lorsque vous créez des index.
En effet, une entité dont une occurrence serait représentée par {A,B,C} peut également être représentée par {B,A,C}, {C, B, A}, ... : la valeur du tuple est strictement la même.

Ensuite, comme on ne peut pas prédire quel sera l'ordre dans lequel sera retourné le résultat d'une requête, la clause ORDER BY est nécessaire si l'on souhaite toujours retourner les données ordonnées de la même façon.

En effet, votre requête peut utiliser un jour l'index non-cluster, mais le moteur peut déterminer que, suivant l'évolution de vos données et donc des statistiques de colonnes, cet index n'est plus efficace, et utiliser l'index cluster (implicite à la clé primaire ou à une contrainte d'unicité) ...

Dans votre cas, l'idée de supprimer la colonne de type entier avec la propriété d'auto-incrémentation et de placer la clé primaire de votre table sur la colonne de type DATETIME me semble être bonne, mais il faut voir que vous devrez mettre à jour toutes les références à cette table, ce qui peut être long, autant à coder qu'à exécuter.
Il vous faut voir si cela a un sens dans votre modèle de données

@++

[M.Max]

OK, merci de cette réponse complète et bien expliquée.

Cdt