Type de données de champ/questions de validation

Question

J'ai peu de questions sur les types de données à utiliser et la façon de définir certains champs de mon site. Mon schéma actuel est en MySQL mais en train de passer à PostregSQL.

1. Première & Nom -> Depuis que je suis multi-lang, toutes les tables support UTF-8, mais dois-je les déclarer comme nvarchar en cas d'un utilisateur entre un nom chinois? Si oui, comment puis-je forcer la validation de champs si elle est configurée pour n'accepter que des alphabets car je présume que ce sont des alphabets anglais et ne valide pas pour des alphabets chinois ou arabes valides? Et je ne pense pas que PostregSQL supporte nvarchar de toute façon?

2. Pour stocker la ligne de temps actuelle -> Exemple Je travaille dans la société A de janvier 2009 à aujourd'hui. Donc je suppose qu'il y aura 3 champ pour ceci: timeline_to, timeline_from, time_line présent où & de mois/année varchars et présent est juste un drapeau pour définir la date actuelle?

3. Mots de passe utilisateur. J'utilise SHA 256 + salage. donc j'ai 2 champs déclarés comme suit:
   password_hash - varchar (64)
   password_salt- varchar (64)
   Est-ce que ce travail si le mot de passe de l'utilisateur doit être compris entre 8 et 32 ​​caractères de long?

4. temps de naissance -> Je dois enregistrer l'heure de naissance de l'application pour calculer quelques valeurs astrologiques. ce qui signifie heure, minute et am/pm. Donc, le mieux est de stocker ces 3 listes de sélection individuelles séparées avec varchar ou d'utiliser un type de données de temps dans le backend et permettre aux utilisateurs d'utiliser la liste de sélection unique dans le front-end? Enfin, pour le mois de naissance et l'année seulement, s'agit-il d'int ou de varchar si je les stocke dans des rangées séparées? Ils ont tous des clés primaires d'int pour les rapports, alors int a plus de sens? ou devrais-je les stocker dans un seul champ comme type de date?

Answer 1

1. Je ne sais pas, jamais eu affaire à beaucoup domaine.

2. Vous pourriez envisager d'autoriser NULL ici et de l'utiliser comme signification spéciale pour Present. Si votre logique d'application voit une date de début non nulle et une date de fin nulle, vous pouvez en déduire cela. Si elles sont toutes deux NULL, aucune information ne peut être déduite. Puisque vous êtes un hachage, vous obtiendrez toujours une chaîne hexadécimale de 256 bits en sortie quelle que soit l'entrée, alors oui, les mots de passe de 8 à 32 caractères fonctionneront tous.

3. Utilisez une DATETIME dans le backend. Vous pouvez faire des choses comme MONTH() pour extraire les parties directement dans votre syntaxe SQL. Bien sûr, vous devrez formater la date juste pour SQL pour l'accepter, mais ce n'est pas trop dur.

4. Encore une fois, tous extractibles avec les fonctions DATETIME dans SQL.

Answer 2

1. NCHAR, NVARCHAR pas.

   • Ne faites jamais rien de variable que vous pouvez rendre fixe; c'est un fardeau supplémentaire d'emballer/décompresser à chaque accès.Ce qui signifie que jamais, jamais utiliser var pour les colonnes indexées, vous aurez un index très lent. L'espace disque est bon marché ces jours-ci.

   • vous avez besoin d'une colonne Language au niveau Person qui vous indique quelle langue utiliser dans vos diverses exigences d'analyse et de validation.

2. Disons que vous avez Person, Employer et Employment tables. Les colonnes dont vous parlez sont en Employment.

   • Vous avez besoin d'une colonne StartDate et d'une colonne EndDate, elles sont le type de données DATETIME.

   • Vous n'avez pas besoin de "présent" dans une colonne séparée. "Présent" est toujours la valeur de la nouvelle ligne Employment, sauf si elle est définie sur quelque chose de différent. Définir une valeur par défaut de la date la plus élevée que la base de données peut gérer, par exemple. 9999-12-31; qui peut être surchargé par une entrée explicite.

3. Non. Vous n'avez besoin que d'une seule colonne CHAR (256). Hank l'a expliqué.

4. Pour tout composant d'une date ou d'une heure, utilisez le type de données DATETIME. C'est ce qui est là pour ça. La base de données le gère de manière cohérente et l'indexe parfaitement. Vous exécutez l'arithmétique DATE, en utilisant db diverses fonctions(). Et vous évitez tous les problèmes de codage comme INTs, etc (pas de dates ou d'heures non autorisées).

5. BirthDateTime est une colonne DATETIME.