Je développe une application Web qui utilise MS SQL pour diverses données: y compris les utilisateurs, les comptes d'utilisateurs, les licences d'utilisateurs, les prix des licences, les factures.
Je dois enregistrer l'utilisation en temps réel du système par les utilisateurs et l'utiliser pour la facturation mensuelle: par exemple, enregistrer chaque fois qu'un utilisateur obtient une page / URL spécifique et facturer les utilisateurs à la fin du mois en fonction du nombre de pages récupérées.
Dois-je écrire ces événements de journal dans une table de ma base de données MS SQL?
Dois-je écrire ces événements de journal dans un fichier journal non-SQL uniquement ajouté?
Dois-je écrire ces événements de journal dans un fichier journal différent pour chaque utilisateur?
Il ne s'agit pas d'un site Web particulièrement volumineux: par exemple, un maximum de 10 000 utilisateurs effectuant chacun en moyenne 5 événements enregistrables / jour => 50 000 événements / jour = 30 événements / minute = 18 000 000 événements / an.
Je demande parce que l'une ou l'autre option semble viable et je ne vois pas si l'une a un avantage clair.
Les données associées à un événement facturable sont simples, par exemple:
- ID utilisateur (relation de clé étrangère avec la table Users dans SQL)
- Date et l'heure
- URL de la page facturable
Ma propre réponse à cette question est la suivante:
Quelques avantages d'écrire le journal dans une table de base de données:
- Intégrité relationnelle: par exemple, les événements consignés sont associés à des ID utilisateur valides (en définissant l'ID utilisateur comme clé étrangère entre les tables)
- Facile à lire pour la facturation: par exemple
SELECT COUNT GROUP BYpour obtenir un compte du nombre d'événements de journal par utilisateur
Quelques avantages de l'écriture dans un fichier journal:
- Performances plus faciles: SQL est utilisé moins souvent, par exemple uniquement pour les événements de connexion des utilisateurs, et surtout uniquement pour la lecture
- Gestion plus facile: archivage plus facile des anciennes données, par exemple à la fin de l'année, en déplaçant les anciens fichiers journaux au lieu de les supprimer / archiver de la base de données
Veuillez me faire savoir si ma réponse est fausse; ou exagère l'importance de quelque chose; ou a oublié une considération importante.
Et / ou s'il vous plaît laissez-moi savoir quelle est votre réponse, si elle est différente de la mienne.
Réponses:
Étant donné que vous utilisez ces informations à des fins de facturation, je ne vois pas pourquoi vous ne les voudriez pas dans la base de données où elles peuvent être facilement interrogées, agrégées, signalées et jointes à d'autres données.
Je pense également qu'il est beaucoup plus facile de maintenir une table de base de données unique contenant les informations de journal qu'un tas de fichiers journaux distincts. Il en va de même pour votre préoccupation concernant la charge sur le serveur - il existe de bien meilleures façons de gérer cela que de recourir à la conservation des données dans des fichiers plats.
Soit dit en passant, votre troisième option consiste à faire les deux. Utilisez la base de données pour la plupart des besoins, mais conservez le fichier journal à des fins d'audit.
la source