[optimisation]Access ses tables et ses champs

Suite au fait qu’on me demande un thread sur PdG, le voici :

Je suis en train de bidouiller un compteur, et on m’a dit de changer des choses en cours de route, du coup je dois aussi changer l’organisation de ma/mes table(s).

En effet, avant j’enregistrais les ip des visiteurs pour les compter, donc ces ip me servaient de clés primaires, seulement on m’a demandé de faire des stats par jours, je dois donc rajouter une colonne “jour”.
Problème : si je mets juste une colonne “jour”, je perds ma clé primaire, puisque le même jour peut apparaître plusieurs fois et l’ip aussi.

J’ai donc pensé à deux solutions :

  1. Je met une autre colonne “id” avec un auto-incrémenté, et là j’ai plus de soucis de clé primaire. Par contre ça va me faire des tables énormes avec wattmille champs.
  2. Je fais 2 tables pour traiter un site, par exemple une qui m’indexe les dates et l’autre qui me sort les stats par ip, et je gère le tout avec les bonnes requêtes qui vont bien. Mais du coup je double le nombre de tables de la base (en principe de 11 à 22, peut-être plus).

Ce que j’aimerai savoir, c’est ce qui est le plus optimisé/performant mais aussi le moins chiant à faire.

Si je n’ai pas été assez clair, je reprécise à volonté.

Merci d’avance

Edit : Oui bon en fait je vais pas me faire chier et rajouter un id pour chaque champ, toutefois si vous avez une bonne idée, je suis toujours prenneur.

On pourrait opter pour la solution 2, et je connais pas la gueule de ta base, mais si tu as besoin de gérer une information sur la date, tu ne peux pas la mutualiser ?

Par exemple, tu crées une nouvelle table VISITEUR, unique, qui rassemble la date et l’ip (admettons que la profondeur d’information dont tu as besoin soit le jour). tu crées un index sur les deux champs, et en clé primaire tu rajoutes un champ auto-increment « id ».

Tu modifies ensuite tes 11 tables pour gicler le champ « IP », et tu rajoutes à chaque table un index qui est une clé étrangère sur le champ VISITEUR.id . Ainsi, quand tu rajoutes l’information à une de tes tables, tu vérifies si l’ip et le jour sont présents dans la table visiteur.

Si ils n’y sont pas, tu les rajoutes, récupère l’id et enregistre ton enregistrement statistiques
Si ils y sont, tu récupères simplement l’id.

Ce genre de cas pourrait être géré très simplement par un trigger en écrivant tes requêtes d’insertion de stats, mais je sais plus si Access gère les trigger (y’a une paire d’année que je m’en suis pas servi). Evidemment ça te rajoute un accès table en plus à chaque transaction, mais si c’est bien écrit, ça peut rouler très convenablement.

Au moins tu t’emmerdes pas à rajouter 11 tables en plus :stuck_out_tongue:

Sinon, pour limiter les accès, rajoute un champ date à chacune de tes tables, rajoute une clé primaire en auto-incrémente, et ainsi tu gères chaque table indépendamment sans jointure. Ca limite les transactions, mais ça augmente le volume de ta base.

A toi de voir ce qui te convient le mieux. Charge machine ou volume disque. Je ne connais pas la volumétrie de ta base donc c’est dur de choisir comme ça en aveugle.

J’y pense, tu parles de compteur, ip, et tout le tralala, c’est pour des traces statistiques d’accès à un site ?

Tes stats sont déjà agglomérées et traitées j’espère ? Car enregistrer TOUS les accès pour les traiter ensuite, fear la taille de ta base si tu enregistres beaucoup de visite.

Oui tiens en y pensant : mais pourquoi est ce que j’enregistre les ip ? Ca me sert à rien en fait.
Merci pour tes lumières en tout cas.

Sinon, oui en effet cette base va agglomérer les infos pour les traiter ailleurs, ensuite. Donc “oui”, je F34R la taille de la base.