J'ai un formulaire web avec environ 15 cases à cocher que les utilisateurs peuvent cocher 0 ou toutes les 15 cases et toute quantité entre les deux. La base de données qui stockera les données de formulaire est MySQL, mais les rapports seront générés à partir des données de MS Access à l'aide d'une connexion MySQL ODBC. Je vois trois options pour gérer cela.Comment normal mes données checkbox pour le stockage dans la base de données
La façon dont la feuille de calcul:
Demandez une table avec une colonne booléenne pour chaque case à cocher et une zone de texte pour "Autres"
La façon Normalisé:
deux tables, une avec les données de formulaire autres que l'info case à cocher. Puis une deuxième table contenant le FK des données de formulaire et la valeur de la case à cocher dans une relation un à plusieurs. Gérez l'insertion des valeurs de case à cocher séparément de l'insertion des données de formulaire avec une certaine boucle lorsque le formulaire est traité.
La façon courte:
Avoir une table avec un champ de texte pour les données de cases à cocher. Lors du traitement du formulaire, concaténez les valeurs de la case à cocher en une chaîne séparée par des virgules et placez-la dans le champ de texte avec les autres données.
Tant le chemin d'accès et la façon courte sont alléchants en raison de la facilité avec laquelle ils peuvent être utilisés pour générer des rapports, la façon dont court en particulier. Malheureusement, alors que je préfère la manière normalisée, personne dans mon organisation qui développe les parties Access ne sait comment générer des rapports qui utilisent correctement les données normalisées, du moins pas proprement. Le mode d'accès et le mode court peuvent être problématiques lors du filtrage par valeurs de case à cocher (le mode d'accès le plus souvent).
Comment dois-je procéder dans ce cas? Si je vais dans la voie normalisée, je devrai aussi prendre la responsabilité de développer un outil pour générer des rapports, ce qui pourrait faire quelques pas et être un peu un problème politique. Je m'en tiens à ce qu'ils utilisent déjà (The Access way) en augmentant ma charge de travail immédiate et en m'achetant un tas de problèmes de programmation sur toute la ligne, mais en évitant toute politique de bureau. Ou la façon hybride qui coûte un peu de programmation maintenant et quelques ennuis plus tard, a seulement quelques obstacles dans les autres membres du projet?
L'approche dénormalisée n'est * pas * la voie d'accès du tout. L'accès ne vous interdit en aucun cas d'utiliser les structures de table appropriées. Veuillez le changer pour lire "la manière de calcul", puisque c'est une manière plus sensible de le décrire. Je vote la question vers le bas pour employer cette expression et enlèverai mon downvote si vous le modifiez pour résoudre ce problème. –
La raison pour laquelle je l'ai défini comme étant le "chemin d'accès" puisque c'est généralement l'endroit où voir ce modèle, puisque c'est le moyen le plus simple de faire fonctionner correctement les formulaires sans codage. Merci de l'avoir changé cependant, il semble que ce soit une description plus juste. –