J'ai un film dans une base de données MySQL. Un film contient des attributs de données qui ne changeront jamais, tels que les suivants:
C'est une seule rangée dans une table.
mais Je veux donner la personnalisation complète de mon utilisateur sur ces informations au cas où quelque chose est incorrect selon eux ou s'il veut simplement modifier la manière dont les données sont affichées d'une manière ou d'une autre. Je me fiche de savoir pourquoi, je veux juste donner à mes utilisateurs une option pour faire ce qu'ils veulent.
Disons que l'utilisateur n ° 1 veut changer le titre pour qu'ils soient "12 singes (étagère 1)" et c'est tout ce qu'ils changent.
et disons que l'utilisateur n ° 2 souhaite changer de DVD en copie numérique à la place.
et disons que l'utilisateur n ° 3 souhaite modifier le titre pour qu'ils soient "douze singes" car c'est le titre alternatif.
etc.
Ma question est, comment puis-je stocker juste que l'on change sur celui-ci pour ce nom d'utilisateur uniquement, sans modifier les données d'origine? Dans une table identique séparée avec tous les champs les mêmes données, à l'exception du champ un ? Ou puis-je simplement stocker un seul changement (titre par exemple) quelque part et reportez-vous aux données Quelle est la bonne façon de concevoir cela, surtout si je dispose de 1000 utilisateurs effectuant des modifications de données personnalisées surtout sur un ou deux champs? film pour le reste?
4 Réponses :
Ma première pensée est, pourquoi voudriez-vous faire cela?
Ma deuxième pensée est d'avoir un personnalisations code> Table de table comme p> +--------+---------+-------------+------------+
| userid | barcode | column_name | custom_val |
+--------+---------+-------------+------------+
Je suis d'accord avec l'approche. Un inconvénient de ceci est que toutes les valeurs Custom_Val devront maintenant être sauvegardées comme des chaînes, même si certaines d'entre elles sont en réalité des entiers, etc.
Vous pourriez avoir Custom_Val_str , personnalisé_val_int , etc., etc. Colonnes.
La partie "Pourquoi" a trait à la mise en œuvre d'une technique de correction de données basée sur l'utilisateur que je travaille. Finalement, je développerai un programme pouvant voir quels utilisateurs change quelles données (et les ratios des modifications, etc.) et mettent en œuvre certains algorithmes qui correctes ou remplissent les données automatiquement. Ceci est particulièrement important pour les films étrangers, les films obscurs, etc. N'ayant pas de données complètes et / ou correctes. Il va aussi au-delà des films aussi ... mais des films sont simplement utilisés comme exemple ici.
@Galz c'est vrai, d'où ma première pensée sur le sujet. ;)
@Barmar qui pourrait être fait, mais je devrais penser que cela deviendrait désordonné assez rapidement.
@Éthanallen serait-il affiché ces valeurs personnalisées à tout le monde ou seulement à l'utilisateur qui les a fait?
@Darwin von corax juste à l'utilisateur qui les a fait.
Ensuite, le stockage des attributs d'affichage comme Strings est moins en cause, sauf si vous souhaitez également permettre aux utilisateurs de rechercher des valeurs personnalisées.
Le seul problème que je peux penser est un synopsis d'un film, qui pourrait être 1000 de caractères de long dans texte . Je suppose que je devais stocker des données texte dans un Personnalisations_LONG POSMINISTER?
au lieu d'une seule ligne pour chaque film, utilisez une table d'attributs-value. Ajoutez ensuite un champ supplémentaire à celui-ci qui spécifie l'utilisateur, qui serait puis une requête pour obtenir le titre ressemblait à: Certains concepteurs de base de données aiment aussi utiliser un 0 pour la valeur par défaut d'origine. Donc, la table ressemble à: attributeID plutôt qu'une chaîne en tant que nom d'attribut et une table séparée qui mesure les noms d'attributs aux identifiants.
Toute la normalisation à l'envers avec un attributeID ? Semble être une jointure supplémentaire inutile?
Je suis d'accord, c'est pourquoi je ne le fais pas. Certaines personnes ne sont que vraiment pédants sur la normalisation.
L'internationalisation est un avantage possible. Vous pouvez facilement remplacer les noms d'attribut avec des valeurs étrangères.
Barmermier - Merci, je n'ai même pas pensé à ça!
L'avantage évident est que vous pouvez modifier l'attribut (nom) à quelque chose de nouveau quand vous le souhaitez à l'avenir. C'est à dire. Vous pouvez changer "Runtime" à "Exécution du temps" par un changement très rapide de seulement 1 petite table au lieu de mettre à jour des milliers de lignes. Il garde les choses propres. Sinon, c'est une excellente solution que je n'aurais pas pensé de probablement!
Je suggère d'avoir {filmid, userid, attribut} comme une clé primaire pour le tableau pour empêcher les données en double.
@Éthanallen & Barmar re "renversement à la normalisation": l'introduction de l'IDS n'est pas une normalisation. La normalisation n'introduit pas de nouveaux noms de colonne. Re "internationalisation": vous pouvez remplacer les valeurs de nom d'attributs (ou tout autre type de valeurs) exactement comme vous pouvez remplacer les valeurs APPETEID. Il existe des raisons d'introduire des identifiants, principalement pour désigner des choses qui n'ont pas déjà de noms, mais sinon lorsqu'ils sont autrement performants (par exemple, l'évitement des cascades ou des entiers étant plus petits que les chaînes) compliquent les schémas et les requêtes.
@Philipxy Je ne sais pas quel est le nom technique, mais vous ne voulez probablement pas que une colonne modifiable soit utilisée comme clé étrangère dans d'autres tables. L'internationalisation n'est qu'une raison pour laquelle vous souhaiterez peut-être modifier la colonne Nom.
@Philipxy, je pense que certains d'entre nous qui ne sont pas des théoriciens de la base de données ont tendance à abuser du mot "normalisation" pour faire référence à des "meilleures pratiques" dans la conception de la base de données.
Si vous avez besoin d'avoir tout le texte en anglais et en français, c'est une «internalisation» («i15n»). Je ne pense pas que c'est ce que vous visez ici. (Si c'est le cas, recommencez et étiquetez-la comme telle; les solutions sont significativement différentes.)
@RickJames Je venais de lui donner comme exemple lorsque quelqu'un pourrait vouloir changer la chaîne unique dans un enregistrement, il est donc préférable de le séparer de la clé primaire. Un autre exemple serait un système de compte d'utilisateur permettant aux utilisateurs de modifier le nom d'utilisateur - à l'aide du nom d'utilisateur car la clé principale rend cela difficile.
@Barmar - Bon point. Et une raison principale de la "normalisation".
Je suggère qu'il n'y a pas de «bon». Mais vous pouvez aimer cela ...
film TABLE reste tel quel. (Je suppose qu'il y a un identifiant .)
- Une autre table,
usermovie avec les mêmes colonnes sauf:
- toutes les colonnes sauf
ID sont null
- Il a une autre colonne:
NON NULL
-
clé primaire (ID, utilisateur)
Lorsqu'un utilisateur modifie quelque chose, utilisez Insérer dans uermovie .. sur la mise à jour de la clé en double. Pour changer quel que soit le champ (s) qu'il veut définir. Notez que iodku insérer une nouvelle ligne si personne n'existe, ou mise à jour la ligne existante (car l'utilisateur modifie une autre colonne). Par exemple, pour remplacer uniquement le "titre" pour identifiant = $ ID, xxx quand un utilisateur veut voir ce qu'il a, xxx < / Pré> Le coalesce Pics tranquillement u.xxx si non null ou m.xxx m.xxx . Cette conception a l'avantage d'être très compact. ( NULLS Près d'un espace.) Si un utilisateur modifie deux fois le "titre" deux fois, seule la dernière version est conservée.
à "Revert" Le titre: xxx (sûr, cela pourrait laisser une ligne de tous nulls , mais le reste du code fonctionne toujours.)
J'aime cette idée, le problème que j'ai, c'est que je dois avoir deux tables en double essentiellement. Ils doivent avoir des noms de colonne correspondants, donc si je veux changer quelque chose (dire desc - varchar (255) à Description - Texte ), alors je dois me souvenir Pour le faire à deux endroits et il n'ya aucun moyen de coupler ces deux colonnes ensemble pour que cela soit fait correctement. Mais je considère aussi bien cette route, ou quelque chose de très similaire.
De plus, vous devez les faire à Sélectionner TIME; La logique commerciale ne vous permet pas de les combiner dans une seule table.
varchar et texte est suffisamment compatible pour que je ne voie pas cela comme un problème. C'est-à-dire que coalesce (u.varchar_col, m.text_col) devrait fonctionner. Ou je manque votre préoccupation?
Re "Si je veux changer quelque chose", c'est spécieux. Tables Partager des colonnes partout sur la place , tout le temps . Ce cas particulier d'une table partageant tous ceux d'un autre n'est plus un "problème". (Utilisez une transaction pour modifier plusieurs tables simultanément) PS Bon choix de bonus. PPS, vous pouvez modifier la réponse que vous acceptez aussi.
Un bon design n'est pas parfait pour toutes les situations. Cependant, il y a un design parfait pour une situation.
Demandez-vous à nouveau: 1) Quel est le but de cette conception et, 2) Comment allez-vous récupérer les données de la conception. P>
Selon Votre question, si un film ne change jamais ses attributs, une table à une rangée plate est parfaite: p>
table: movie_meta id | movie_id | user_id | created | meta | info ---+----------+---------+---------------------+-----------+--------- 1 | 1 | 123 | 2016-01-28 11:22:33 | format_id | 2 2 | 1 | 456 | 2016-01-28 11:55:33 | disc | 3 5 | 1 | 666 | 2016-07-14 12:58:55 | title | å二头傻猴å
Qu'en est-il des films qui ont plusieurs titres? Ce n'est pas seulement "douze singes" contre "12 singes", mais cela pourrait aussi être "L'armée des 12 chantes" ou l'un des autres noms sur La page IMDB . Cette relation une à plusieurs personnes pourrait être importante pour certains ou peut-être pas. Vous êtes également des choses à relier, comme si elles l'ont acheté comme un package de DVD / Blu-ray?
Étant donné que vous connaissez les colonnes que vous remplacez, il n'est pas nécessaire d'utiliser les conceptions EAV (colonnes d'attributs) proposées dans certaines des réponses. Même si les utilisateurs peuvent inventer leurs propres colonnes avant d'utiliser EAV, vous devez démontrer qu'il est supérieur à DML / DDL avec des tables simples.