MYSQL: une date comme primary key pour un log journalier ?

[php_addict]

bonjour

je me pose une question qui me parait insolite et je me permet une nouvelle fois de vous la soumettre:

je souhaites faire un log journalier, par exemple un log journalier du nombre d'attaques lancées par l'ensemble des joueurs ou tout autre log dont le seul but est d'obtenir un log pour chaque jour

je pensais mettre comme PRIMARY KEY de la table log une date ou le timestamp de l'heure YYYY-MM-00:00

et faire une requête du style

"INSERT INTO log (date,nb) VALUES (:date,:nb ) ON DUPLICATE KEY UPDATE nb = nb + :nb";

ainsi pour récupérer les données journalière c'est un SELECT assez simple, mais si je veux SELECT les données par mois par exemple je ne sais pas si cette structure est très adaptée...

avez vous ce genre de table? comment vous y prenez-vous ? y a t il mieux ou plus pratique que ca (certainement) ? un conseils ?

PS: mon jeu est basé sur le temps local du serveur, time() en php


bonne fin de journée à tous et merci d'avoir pris le temps de lire ceci.

[Myrina]

c'est quand même préférable de mettre un type entier pour la clé primaire.
Et ce n'est pas gênant car tu peux mettre ta colonne date en index unique: le ON DUPLICATE KEY UPDATE fonctionnera également avec les index uniques.

[niahoo]

D'un point de vue conception de base de données c'est tout à fait correct d'utiliser la date comme clé primaire.

En pratique, il faut voir si ta base de données ne galère pas à indexer des dates. Si c'est un timestamp y a pas de problème.

[srm]

Moi je découperais la date en plusieurs champs, un pour l'année, un pour le mois, un pour le jour, tous indexé bien entendu

[php_addict]

Moi je découperais la date en plusieurs champs, un pour l'année, un pour le mois, un pour le jour, tous indexé bien entendu

c'est certainement ce que je vais faire, et pour les index tu ferais comment?

- un index sur 3 colonnes (jour / mois / annee)
- ou 3 index sur une colonne ? (1 index sur jour , 1 index sur mois, 1 index sur annee)

[srm]

3 index

[Argorate]

pourquoi? (j'aime bien avoir des arguments dans les choix de conceptions ^^)

[Roworll]

Ça dépends de la manière dont tu veux traiter tes données.

D'abord, créer un index sur l'année dans ce cas me semble peu judicieux.
Ça va prendre de l'espace disque pour au final une efficacité plus que minime car d'ici quelques années, ton index ne contiendra qu'une poignée de valeurs différentes pour des milliers d'enregistrements.

Même question sur le mois. A quoi servira un index qui au final ne contiendra que 12 valeurs différentes ?
La plupart des moteurs SQL avec un peu de jugeote préfèreront partir sur un table scan pour éviter les lookups incessants entre la table d'index et les données.

Autant indexer sur un format ODBC canonique (YYYY-MM-DD) qui permet bien plus de facilité pour une recherche encadrée (log_date BETWEEN '2011-03-01' AND '2011-03-31').

[srm]

Et donc pendant que tu y es Roworll pourquoi mettre un index sur le jour qui ne va contenir que 31 valeur ?
Essaye donc de mettre aucun index que l'on rigole :p

3 index pourquoi ? Ca mange pas de pain et donne bien plus de flexibilité

Si tu mets 1 index sur les 3, tu es obligé d'interroger dans l'ordre des index, par exemple tu ne peux pas interroger que le jour sans l'année et le mois.
Tu vas me dire à quoi ça servirait ? Bah je sais pas un jour tu auras peut-être besoin d'interroger tous les week-end pour analyser quelque chose.

Et si tu mets un format ODBC canonique comme le suggère Roworll même problème

[niahoo]

ça se tient.

mais ce que je répète toujours c'est qu'il faut optimiser au maximum les performances et la rapidité d'une application quand il faut tenir une certaine charge ou assurer un débit de données soutenu.

Quand il s'agit simplement d'analyser les logs, alors peut-être est-il plus facile de développer des scripts avec un seul champ date (mais peut être que la méthode oxman s'avère plus aisée aussi). Pour trouver les week end plus facilement il faudrait plutot stocker en plus le numéro du jour de la semaine plutot que de disposer du numéro du jour du mois.