J'ai récemment été introduit dans la nouvelle fonctionnalité d'accès 2007 qui est des champs multivalassés. Ma première impression est que c'est une mauvaise idée d'utiliser plusieurs valeurs dans un seul champ. Traditionnellement, si vous souhaitez autoriser un enregistrement à avoir plusieurs valeurs pour un champ, vous créeriez deux autres tables et liez-les avec des clés étrangères. Cela permet d'interroger facilement et garantit que les valeurs dupliquées font référence au même article. Garder des listes dans une cellule semble être une violation de l'objectif des bases de données.
Y a-t-il de bonnes utilisations pour ces champs qui ne me font pas me sentir sale?
8 Réponses :
Un grand segment du marché de l'accès est non-développeur, mais des utilisateurs techniques. Ils pourraient ne pas comprendre la valeur de la normalisation, mais ils peuvent avoir quelque chose à travailler. Ils ont juste besoin de quelque chose de facile et c'est mieux qu'un champ de texte libre où les gens de type, où vous espérez tous de taper la même chose.
Comme ils en apprennent plus, ils pourraient commencer à utiliser d'autres tables et clés étrangères. Mais parfois, un champ à grande estimation est assez bon.
Comme 640k et 2 chiffres pour stocker l'année;)
L'idée de champs multiples était de prendre en charge la création facile d'objets de rapport / interface, en outre, on peut créer un formulaire qui affiche des catégories pour un problème. Au lieu de faire un travail intense, Dieu vous interdit de rejoindre, c'était censé plus simple à stocker:
Mécanique, électrique
comme une valeur dans un champ plutôt que
mécanique Électrique
Personnellement, je ne l'aime pas et supposons que ce type de champ a été créé pour un personnel non technique comme les comptables :) (juste rigoler). Pas sérieusement, n'utilisez pas cela à moins que vous ne créez un outil idiot qui rarement que quiconque utilisera et rarement quelqu'un aura jamais à exploiter.
Le moyen approprié de gérer cela est des jointures, pas de duplicate et aucune valeur multiple à l'intérieur des colonnes (c'est tout 3NF de toute façon).
Une autre raison pour laquelle cela a été créé était de prendre en charge les valeurs multiples à l'intérieur d'une liste SharePoint.
jon
Dites simplement non!
Si vous apprenez SQL, apprenez la bonne façon et normaliser vos tables. Si vous connaissez la conception de la base de données, faites-le correctement. Toutes les fonctionnalités ne doivent pas être utilisées.
Voir:
DataTypes multiples considérés comme nocifs: quelle dangereuse peut-elle être un type de données ?
J'ai eu une longue discussion avec Suraj Poozhiyil, le programme d'accès Manager ... à la fois suraj et je suis d'accord de tout coeur que les développeurs ne font pas besoin d'utiliser des champs multi-valeurs. Les gens qui comprennent les bases de données ont déjà un bon moyen de Mettre en œuvre beaucoup de relations et gagneront aucun avantage des champs multi-valeurs.
Alors, mon conseil clair et certain à Les développeurs ne doivent pas utiliser multi-évaluations des champs. Ils n'ont rien à nous offrir Sauf douleur potentielle.
Alors pourquoi les ont-ils créés? Il est clair qu'ils utilisent dans le monde réel, il y a toute une base de données, unidata et univers, qui sont construites autour d'eux.
@Noah: Un rapide Google me dit que ceux-ci sont basés sur le choix et non SQL. Si je comprends bien, choisir la syntaxe (opérateurs, etc.) requise pour interroger des données multivaluées, l'accès / Jet / Ace ne le fait pas. Pas vraiment mon champ, pour être honnête (j'ai utilisé Intersystems Caché mais seulement via sa passerelle SQL - qui est excellent - et pas les trucs à oreillons). Je suis plus heureux avec 5nf :)
ne pas vraiment répondre à la question ici, mais les lecteurs voudront peut-être noter qu'il existe une industrie de niche entière autour de l'idée de Bases de données multiples :
Ces bases de données diffèrent d'un base de données relationnelle en ce qu'ils ont caractéristiques qui soutiennent et encouragent l'utilisation d'attributs ayant une liste de valeurs plutôt que tous les attributs avoir une valeur unique
Étant donné que, dans ce cas, le moteur de base de données a des extensions de la langue de requête pour s'adapter à la nature multidimensionnelle de ses tableaux (que je suppose que l'accès ne signifie probablement pas), ce n'est pas vraiment comparable à des champs multivalassés dans l'accès. Mais un parallèle intéressant dans tous les cas (pour quiconque n'a pas encore entendu parler de bases de données multimalisé).
Je n'aime vraiment pas les champs multi-valeurs. Peut-être qu'ils l'ont fait pour faciliter l'interface avec d'autres systèmes multi-valeurs tels que le système ancien Pick / Unidata. Je parie qu'il est amusant à améliorer une base de données d'accès avec une utilisation intensive de cette nouvelle fonctionnalité sur SQL Server.
Sa seule raison d'être dans ACE est la compatibilité avec SharePoint. Les données sont réellement accessibles via des joints et il serait assez facile d'écrire du VBA pour l'écrire à des tables réelles N: n. Bien sûr, cela pourrait très bien être que le SSMA d'accès 4.2 comprend des champs MV et les augmente tout simplement bien. Si vous êtes intéressé, je pourrais lui donner une balle et découvrir, comme je l'ai à la fois A2007 et le SSMA 4.2 installé.
@ David-W-Fenton: "Sa seule raison d'être dans ACE est la compatibilité avec SharePoint" - ... Pourtant, l'équipe d'accès favorise son utilisation générale dans Access E.G. Cela ne mentionne pas SharePoint une fois: Office.Microsoft.com/en-us/access-help/...
Les matériaux marketing ne révèlent pas très souvent toute la vérité.
Si les outils comprennent comment gérer les champs MV, la hausse de la hausse devrait être bien et si elles ne peuvent pas être utilisées, il s'agit simplement de plus de travail. J'ai eu des conversions difficiles d'accès à SQL Server dans le passé et que cette fonctionnalité me donne envie d'anticiper la difficulté supplémentaire. Je pourrais le tester aussi, mais j'attendrai et voyez si le besoin se pose jamais. Merci quand même.
Les champs multivalassés peuvent facilement vous éviter de créer une nouvelle table et une nouvelle relation.
soda -> types
Pourquoi ai-je besoin d'une nouvelle table juste pour dire que Pepsi est habituel, régime et plus.
Je souhaite qu'ils nous permettent de donner des colonnes de champs multivalués, alors ils seraient comme une table, mais avec beaucoup moins de travail
Necro-post ... Je pense que la question aurait dû être révisée lorsque le fil a commencé à commencer, mais je ne passerai pas le processus d'édition maintenant.
La question est "Les champs multivalassés une bonne idée?"
La vraie question à laquelle on aurait dû être posé est "champs multivalos dans la BDBMS une bonne idée?"
Comme d'autres l'ont noté, il existe un modèle complet MVDBMS Soutenir des champs multi-valorisés. Je suis un expert dans ce domaine et je travaille avec le modèle depuis plus de 30 ans. Bien sûr, c'est une bonne idée à mon avis et aux autres qui utilisent la plate-forme tous les jours. Et oui, Caché a non seulement un grand modèle multidimensionnel lui-même, mais il prend également en charge le modèle MVDBMS. Donc, à cet égard, la réponse à la question est oui.
mais pour une SGBDM et spécifiquement MS Access La réponse n'est presque certainement pas parce que ni le modèle RDBMS ni cette plate-forme ne supporte intrinsèquement le concept.
La réponse acceptée est correcte, imo, car elle ne répond pas seulement à la question posée, elle répond à la question qui était destinée à être posée. Mais pour être méticuleux, pour la question exacte posée, la réponse acceptée est incorrecte.
Je crois que la vraie réponse est "Ce n'est qu'une bonne idée si la plate-forme DBMS le supporte, oui pour MVDBMS et peut-être d'autres plates-formes NOSQL, non pour les SGDB."