Actuellement, ma table des utilisateurs a les champs ci-dessous
Je ne sais pas si je devrais mettre les champs d'adresse d'une autre table. J'ai entendu dire que je briserai 3nf si je ne le fais pas si je ne peux pas comprendre pourquoi. Quelqu'un peut-il s'il vous plaît expliquer?
5 Réponses :
Le point est que si vous imaginez avoir deux adresses pour le même utilisateur à l'avenir, vous devez vous scinder maintenant et avoir une table d'adresses avec un FK pointant sur la table des utilisateurs.
P.s. Votre table manque une identité pour être utilisée comme PK, quelque chose comme ID ou ID utilisateur, appelez-le comme vous le souhaitez ...
@Enzero: N'utilisez pas le nom d'utilisateur comme clé primaire - les personnes devraient pouvoir la modifier comme elles l'aiment.
Je ne suis jamais allé à un site qui vous permet de changer votre nom d'utilisateur en dehors du fait qu'il ne sonne pas logique.
mais n'étant pas d'incrémentation automatique, ne vous aide pas si vous voulez trier en dernier inséré ... C'est très subjectif que je sais, personnellement, j'aime avoir une identité de données dans toutes les tables, donc je peux toujours vérifier quels enregistrements ont été ajoutés. Enfin et parfois, j'ai aussi une date d'heure à me dire quand ...
Dans le cas de la table des utilisateurs, pourquoi voudriez-je avoir été ajouté en dernier ou lorsque vous utilisez la plupart des cas, j'utilise des INTS comme des identificateurs, mais dans ce cas, je pense que l'utilisateur devrait suffire.
@Enzero: Stackexchange fait ..;) INT prend moins d'espace que Varchar, ce qui signifie que la jointure / la recherche / etc. sur elle fonctionnera mieux.
S'il vous plaît priez dites comment parce que je ne sais pas comment je sais que vous ne pouvez changer votre nom d'affichage que
@Enzero: Quelle est la différence?
Vous vous battez contre le bon design sans raison. Les identités ou l'incrément automatique ne doivent même pas être réglées dans les inserts, vous pouvez les ignorer à l'insertion et vous avez tellement d'avantages à ce que cela ... comme autre vous dit, rejoignez-vous et donc sur ...
Tant que chaque utilisateur a une adresse et chaque adresse appartient à un utilisateur, elle devrait aller dans la même table (une relation de 1 à 1). Toutefois, si les utilisateurs ne sont pas tenus de saisir des adresses (une relation facultative), une table séparée serait appropriée. De plus, dans le cas étrange que de nombreux utilisateurs partagent la même adresse (par exemple, ils sont des condamnés dans la même prison), vous avez une relation de 1 à plusieurs, auquel cas une table séparée serait la voie à suivre. Modifier: Et oui, comme une personne a souligné dans les commentaires, si les utilisateurs ont une adresse multiple (1 à plusieurs l'inverse), il devrait également y avoir des tables séparées.
En les ajoutant à la table séparée, vous aurez un moment plus facile à développer votre application si vous décidez de choisir plus tard. J'ai généralement une table utilisateur simple avec user_id ou ID, nom_nom ,.name, nom_nom, mot de passe, créé_at et mise à jour_at. J'ai alors une table de profil avec les autres informations.
C'est vraiment toute la préférence.
Il y a plusieurs points qui ne sont définitivement pas 3nf; et des questions douteuses en plus:
Si la réponse à l'une de ces questions est oui, alors cela indique un problème avec 3NF dans cette zone. La raison de 3NF est d'éliminer la duplication des données; S'assurer que les mises à jour, les insertions et les suppressions laissent les données sous forme cohérente; et de minimiser le stockage des données - en particulier, il n'est pas nécessaire de stocker des données comme "non encore connues / inconnues / null".
En plus des questions posées ici, il y a aussi la question de savoir ce qui constitue la clé primaire de votre table - je suppose que c'est quelque chose à voir avec l'utilisateur, mais que le nom et les autres informations que vous donnez sont peu susceptibles d'être uniques , alors ne suffira pas comme une pk. (Si vous pensez que le nom de famille Plus est unique, vous suggérez que vous n'aurez jamais plus d'un John Smith?)
EDIT: À la lumière d'informations complémentaires que certains champs sont facultatifs, je vous suggère de séparer les champs optionnels en différentes tables et d'établir des liens 1-1 entre les nouvelles tables et la table d'utilisateurs. Ce lien serait établi en créant une clé étrangère dans le nouveau tableau faisant référence à la clé principale de la table des utilisateurs. Comme vous le dites, aucun des champs ne peut avoir de valeurs multiples, il est peu probable qu'il vous donne des problèmes à l'heure actuelle. Si toutefois, l'un de ces changements, alors ne les divisez pas vous donnera des problèmes dans la mise à niveau de l'application et des données pour prendre en charge l'application. Vous devez toujours répondre à la principale question clé.
Ok alors laissez-moi répertorier l'adresse ANS 1.Only 1 adresse, 2.Optional, 3. hone I espoir pas, 4. seulement 1,5. Facultatif, 6. seulement 1,7. Facultatif, 8. non, 9. Obligatoire, 10 est par rapport à l'adhésion que combien de billets peuvent être achetés gratuitement pour chaque spectacle, 11. est un nombre de choses à dire jusqu'à l'être bloqué, 12. A ne peut être bloqué qu'une fois à la fois
Adresse de la ville Région de pays Telno Mobno devrait être dans une autre table alors devrais-je aussi diviser les autres champs?
J'irais pour une région d'adresse de la ville comme une seule table; et Telno, Mobno comme un autre.
"Si la réponse à l'une de ces questions est oui, alors cela indique un problème avec 3NF dans cette zone." 3nf a à voir avec des dépendances transitives. Il n'a rien à voir sur le point de savoir si l'OP souhaite stocker une ou plusieurs adresses par utilisateur, si un utilisateur dispose de plusieurs numéros de téléphone ou si un utilisateur dispose de plusieurs adresses électroniques.
@CATCALL - Je suis tout à fait d'accord - les indicateurs que j'ai énuméré étaient tous des points d'identification des dépendances transitives potentielles - je ne voulais pas entrer dans une définition approfondie de 3NF ni égarée trop loin des directives simples en fonction des champs donnés. Cela aurait probablement été plus précis de dire "Cela suggère qu'il pourrait y avoir ..." plutôt que "cela indique ...".
Je suis confondu avec "la raison de 3nf est de ... Pour minimiser le stockage des données - en particulier, il n'est pas nécessaire de stocker des données comme" non encore connues / inconnues / null "". Je n'ai jamais entendu dire une exigence pour 3nf
Tout comme le point que je pense aider quelqu'un dans cette question, j'ai une fois une situation où je mets des adresses dans les tables de l'utilisateur / du site / de la société / etc. parce que je pensais, pourquoi aurais-je besoin de plus d'une adresse pour eux? Ensuite, après avoir terminé tout ce qu'il a été porté à mon attention par un autre service que nous avions besoin de la possibilité d'enregistrer à la fois une adresse de livraison et une adresse de facturation.
La morale de l'histoire est une exigence fréquente, donc si vous pensez que vous jamais peut enregistrer les adresses de facturation et , ou peut penser à tout Autre type d'adresse que vous souhaitez enregistrer pour un utilisateur, aller de l'avant et le mettre dans une table séparée.
Dans l'âge d'aujourd'hui, je pense que les numéros de téléphone sont un certitude aussi pour être stockés dans une table séparée. Tout le monde a des numéros de téléphone portable, des numéros domestiques, des numéros de travail, des numéros de fax, etc., et même si vous ne prévoyez que de demander une personne, les gens vont toujours mettre deux sur le terrain et les séparer par un demi-côon (croyez-moi). Juste quelque chose d'autre à considérer dans votre conception de base de données.
Que se passe-t-il si un utilisateur a plusieurs adresses (ou plusieurs numéros de téléphone mobile, à ce sujet)? Permettez-vous cela?
Que se passe-t-il si vous voulez stocker une adresse pour autre chose qu'un utilisateur?
Sur une note séparée, parlez-moi du champ Mot de passe. C'est juste un hasch, non?
Le mot de passe est MD5 et un utilisateur dispose d'un mobile et n'a pas besoin de plus d'une adresse, il s'agit d'un système de réservation de théâtre en ligne pour que vous sachiez simplement. Je ne peux pas penser à une raison de stocker une adresse pour autre chose que tu peux me donner quelques suggestions de Razlebe
Glad le hachée de mot de passe, mais sachez que MD5 est un mauvais choix pour cela.
comment venir? Je ne pensais pas que ce serait si mal
Lisez le lien Wikipedia dans mon commentaire, puis Google pour "MD5 compromis". SHA-2 est une alternative généralement acceptée (et SHA-3, quand il est prêt ).
Ok vous avez un point là-bas alors que dois-je utiliser alors SHA1 ou autre chose?
N'utilisez pas SHA-1. Utilisez une des options SHA-2 et n'oubliez pas d'ajouter sel .
Je me souviens de sel dans mon diplôme comment l'utilisez-vous à nouveau et merci pour les informations jusqu'à présent sur la cryptographie
Examinez les liens de mes commentaires et examinez les nombreux articles en ligne sur le sujet. Le débordement de pile a un Bunch , aussi. De plus, si vous dirigez un commentaire à quelqu'un d'autre, n'oubliez pas de préfixer le commentaire avec le signe 'at' et leur nom (comme dans,
@enzero ). Si vous ne faites pas cela, je ne reçois pas la petite lumière rouge meignant un commentaire. Voir certains des commentaires ci-dessous pour des exemples.@Michael Patrotta Merci pour votre aide vérifiera les articles que vous avez spécifiés même si ce n'est que pour une thèse et ne nécessiterait pas beaucoup de sécurité, mais cela pourrait m'aider dans ma marque si merci
La discussion sur la sécurité sur le champ de mot de passe est complètement hors de la question de la question