Comment gérer les données de mise à jour dans un schéma de base de données de relations un-à-plusieurs?

Question

Disons que j'ai une base de données similaire à ce qui suit:

Table: People 

id | name | age 
---+------+----- 
1 | dave | 78 

Table: Likes 

id | userid | like 
---+--------+------- 
1 | 1 | apples 
---+--------+------- 
2 | 1 | oranges 
---+--------+------- 
3 | 1 | women 

Quelle serait la meilleure façon de gérer la mise à jour des données daves? À l'heure actuelle, je fais ce qui suit:

Update his age 
UPDATE People SET age = 79 WHERE id = 1; 

Update his likes 
DELETE FROM Likes WHERE userid = 1; 
INSERT INTO LIKES (userid, like) VALUES (1, 'new like'); 
INSERT INTO LIKES (userid, like) VALUES (1, 'another like'); 

supprimer toutes les données des utilisateurs de la table, puis readd leur nouveau genre de choses. Cela semble inefficace. Y a-t-il un meilleur moyen?

Answer 1

Vous pouvez ajouter une nouvelle colonne à Likes en stockant l'âge réel. En faisant cela, vous obtenez une fonctionnalité d'histoire et vous pouvez déterminer ses goûts en demandant ceux qui ont l'âge le plus élevé comme:

SELECT * FROM Likes WHERE userid = 1 AND age = (SELECT MAX(age) FROM Likes WHERE userid = 79 GROUP BY userid); 

Lorsque vous voulez être en mesure de passer outre certains autres vous pourriez également ajouter une colonne « overriden_by » contenant le id du nouveau Like. Cela entraînerait une requête plus simple:

SELECT * FROM Likes WHERE userid = 1 and overriden_by is null; 

Answer 2

Selon le SGBD, vous pouvez utiliser « Merge » « REMPLACER » « INSERT ou REPLACE », la plupart DBMSes prennent en charge cette fonctionnalité, mais la syntaxe varie énormément de sorte que vous devrez RTFM pour savoir comment faire cela avec la base de données que vous utilisez.

Answer 3

Je ne comprends pas pourquoi vous suggérez un lien entre la mise à jour d'un enregistrement dans la table parent et ses dépendances dans la table enfant. Le point d'avoir des tables séparées est précisément que nous pouvons modifier les colonnes non clés dans People sans toucher Likes.

En ce qui concerne la mise à jour Likes, il existe deux transactions commerciales différentes. La première est quand Dave dit: «Je ne voulais pas dire 'oranges' je voulais dire que j'aime l'arrangement floral. Correction d'une erreur utiliserait une mise à jour:

update likes 
set like = 'flower arranging' 
where userid = 1 
and like = 'oranges' 
/

La clause WHERE peut utiliser la colonne LIKES.ID à la place.

L'autre cas est celui où les préférences ont réellement changé. C'est-à-dire, quand Dave dit «Maintenant, j'ai 79 ans, je n'aime plus les femmes, j'ai de nouveaux goûts». Cela peut ressembler à ceci:

delete from likes 
where userid = 1 
and like = 'women' 
/
insert into likes (userid, like) 
values (1, 'dominoes') 
/
insert into likes (userid, like) 
values (1, 'Werthers Orignals') 
/

La différence entre ces deux instructions est principalement celle de la clarté. Nous aurions pu mettre en œuvre la deuxième série de déclarations sous forme de mise à jour et d'insertion unique, mais cela serait trompeur. Garder la distinction entre des changements significatifs dans les données et corriger les erreurs est une discipline utile. Il est particulièrement utile lorsque nous conservons des enregistrements historiques et/ou des modifications d'audit.

Ce qui est définitivement une mauvaise idée est de supprimer tous les enregistrements Likes de Dave, puis de les réinsérer. Votre application devrait être capable de suivre quels enregistrements ont changé.