Comment puis-je générer efficacement des numéros de série uniques pour les changements d'adresse au sein des groupes de personnes dans une base de données ?

Rationalisation du suivi des changements d'adresse avec les numéros de série de base de données

La gestion des changements d'adresse au sein d'une base de données nécessite souvent une table d'historique pour enregistrer chaque modification. Ce tableau comprend généralement un identifiant de personne, un numéro de séquence pour chaque changement d'adresse, un horodatage et l'adresse précédente. Cependant, l'incrémentation automatique du numéro de séquence par personne peut s'avérer étonnamment complexe.

Simplifier l'approche : éviter les contraintes d'incrémentation automatique

Au lieu d'utiliser des séquences ou des contraintes à auto-incrémentation, qui conduisent souvent à des solutions alambiquées, une méthode plus simple implique une colonne série standard (auto-incrémentation) ou IDENTITY :

<code class="language-sql">CREATE TABLE address_history (
  address_history_id serial PRIMARY KEY,
  person_id INT NOT NULL REFERENCES people(id),
  created_at TIMESTAMP WITHOUT TIME ZONE NOT NULL DEFAULT CURRENT_TIMESTAMP,
  previous_address TEXT
);</code>

Génération de numéros de série avec des fonctions de fenêtre

Avec cette structure de tableau, les fonctions de fenêtre offrent une solution élégante pour générer des numéros séquentiels pour chaque personne sans espaces :

<code class="language-sql">CREATE VIEW address_history_nr AS
SELECT *, ROW_NUMBER() OVER (PARTITION BY person_id ORDER BY address_history_id) AS adr_nr
FROM address_history;</code>

Cette vue remplace directement la table d'origine, fournissant les numéros de série souhaités (adr_nr) dans vos requêtes.

Optimisation du modèle de données pour plus d'efficacité

Pour des performances optimales, envisagez ces améliorations du modèle de données :

• Utilisez TIMESTAMP WITHOUT TIME ZONE (ou TIMESTAMP WITH TIME ZONE) pour un suivi précis du temps au lieu de DATETIME.
• Réduire le stockage des données ; le champ previous_address est suffisant, éliminant le besoin de colonnes address et original_address séparées. Cela réduit l'espace de stockage et améliore la vitesse des requêtes.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!