Bonjour,
 
Je fais des moyennes de données par jour et par mois. Le 1er du mois j'ai donc la moyenne du 1er (le jour)  et la moyenne du mois (moyenne faite que sur le 1er jour forcement). Le 2 du mois, je calcule la moyenne du 2 et la je doit recalculé la moyenne du mois (maintenant calculé sur le 1er et le 2 du mois).
 
L'identifiant étant un auto_incrément j'ai crée un index unique sur les champ devant resté unique (dans l'exemple mois et jour) pour faire un replace. Mais voila le champ du jour restera null pour la moyenne du mois et lors de mon replace je me retrouve avec une deuxième ligne pour le mois.
 
Une solution ma été proposé consistant a mettre à la place du null un '-1' pour ces champs mais cette dernière me plaisait moyennement.
 
Je m'adresse donc à vous pour voir si une solution plus appropriée m'est proposée.
 
Merci d'avance.
 

Tu ne vas pas avoir trop le choix
Tu ne peux pas créer deux index unique (un pour jour et un pour moi) sinon plus rien ne va marcher MAIS tu as besoin d'avoir une unicité pour ta moyenne par mois ( sans jour).
La solution de la valeur "bidon" est, AMA, une "bonne" solution (mais j'aurais tendance à mettre 0 plutot que -1).

Une autre serait d'avoir 2 tables de moyenne par jour / par mois

plusieurs solutions pour moi:
 
soit une table avec:
- jour
- type (J/M/A)
- valeur
 
soit deux tables comme dit anapajari
 
soit une table avec
- jour
- valeur moyenne du jour
- valeur moyenne du mois (uniquement pour le 1er du mois)
 
si tes données de base ne sont pas trop importante, partir sur deux vues les attaquants

Merci pour les réponses,
 
je vais surement utiliser la valeur "bidon" mais avec -1 car en plus des mois et jours, je dois gérer les années et les heures ce qui élimine le 0 car utilisé pour l'heure de minuit.
 
Les données de base se comptes en dizaines de millions, c'est pour cela que je pense que la solution avec les vues n'est pas des meilleurs.
 
Encore merci pour les conseils
 

un dernier petit conseil que je te donnerai, je m'occupe d'un datawarehouse donc cela rendre dans ton cadre.
Il y a un élément a prendre en compte lorsque tu fais ce genre de chose, la lisibilité des données, il est généralement moins intéressant d'utiliser des solutions de contournements avec des codes etc, plutot que de dédoubler des colonnes ou lignes etc pour "gagner" de la place,
car l'élément a prendre en compte pour ton gain d'espace est ta table de millions de lignes de base et que ta table de stats sera de toute facon rikiki par rapport a celle la.

++ avec le zéro
et la solution la plus propre est effectivement d'avoir une table supplémentaire, mais c'est aussi la plus lourde, donc pas forcément la meilleure