Comment stocker et récupérer un grand nombre de données pour une extraction spécifique à la date + récupération de résumé?

Question

cas simplifié:

Stockage

1. Les utilisateurs cliquent sur un lien
2. link_clicks +1 pour chaque clic
3. Super utilisateur définit un paramètre multiplicateur pour chaque clic
4. link_reward (+ 1 * param) pour chaque clic
5. L'ID utilisateur est également enregistré pour chaque clic

Récupération

• Les requêtes doivent être effectuées sur une plage de dates spécifiques (par exemple, « Combien de clic entre 10 et 23 octobre octobre pour l'ID utilisateur = 4 »)
• La plupart des requêtes seront fait, cependant, sur la somme de toutes les dates pour un utilisateur donné

En supposant que la table devient massive, les deux types de requêtes deviendront très lent non?

Comment le gère-t-on? Stocker simultanément dans un tableau détaillé (une ligne par clic par utilisateur et par lien) et dans un tableau récapitulatif (une ligne par utilisateur et par lien)? J'ai entendu parler de "retrousser" les données mais je ne sais pas ce que cela signifie.

Technologies utilisées: MySQL, PHP (et Javascript)

Answer 1

Comment peut-on gérer cela? Stocker simultanément dans un tableau détaillé (une ligne par clic par utilisateur et par lien) et dans un tableau récapitulatif (une ligne par utilisateur et par lien)?

Oui, mais ajoutez une colonne DATETIME afin de pouvoir effectuer la vérification de période mentionnée en (a). Remplissez la colonne DATETIME à l'aide de la fonction NOW() pour obtenir la date actuelle & heure. Quelque chose à l'esprit à propos de l'option (a) est que les critères minimisent les données résumées, donc la performance ne devrait pas être trop importante. En outre, la table des détails ne doit probablement pas être indexée, car les index permettent uniquement d'obtenir les données sur et de ralentir la mise à des données dans une table.

La récompense de super utilisateur doit probablement être une table distincte, mais cela signifie que votre table de détails doit se rapporter au super utilisateur soit par son ID utilisateur ou URL. userid serait un meilleur choix. J'ai entendu parler de "rouler" les données mais je ne sais pas ce que cela signifie. Un principe de base de données est de stocker uniquement ce dont vous avez besoin - les données récapitulatives peuvent être calculées en utilisant des fonctions comme SUM et COUNT. Vous pouvez create a view, qui peut être interrogé comme une table mais il ne stocke aucune donnée.

Answer 2

Facile. :-)

Une table pour les utilisateurs, je l'appelle l'utilisateur.

Une table pour les clics, je l'appellerais ClickEvent.

Une table pour chaque lien distinct, je l'appellerais HyperLink (en évitant le mot « lien » dans le DB)

Le tableau de l'utilisateur, étant donné ce que nous savons (pas beaucoup), n'est pas très matériel à interroger ou à répondre.

Le tableau HyperLink sera l'endroit idéal pour stocker toutes les informations sur chaque lien, les colonnes étant:

• HyperLinkID
• URL
• ClickValue
• RewardMultiplier

(je pense ce que vous avez déclaré affecte la valeur et le multiplicateur à l'entité de liaison, pas à chaque événement de clic, n'est-ce pas?)

La table ClickEvent est au cœur de votre question/réponse. Je lui donnerais des colonnes comme suit:

• ClickEventID, int (PK)
• UserID, int (FK)
• HyperLinkID, int (FK)
• ClickDateTime, datetime
• ComputedEventValue (décimal ou smallmoney)

Vos soucis de vitesse doivent être atténués - ce n'est pas très intense, même avec beaucoup d'activité. Chaque transaction (un clic) est enregistrée dans la table ClickEvent. Chaque événement click insère un nouvel enregistrement et pendant l'insertion, ComputedEventValue est écrit.

Cela semble être l'idée principale de couverture comme je le vois.