Je suis un peu confus car il existe de nombreux types de variables dans SQL Server (Ntext, Varchar, Nvarchar, etc.), donc peut-être que si vous me donnez les types de données que vous utilisez pour les champs suivants, je comprendrai cela un peu mieux . Si je manque un type de champ commun, veuillez me le faire savoir.
id
Numéro de téléphone
Email
Description (paragraphe de texte)
Nom
SSN
Prix
Date d'expédition
Sexe (m / f)
Discontinué (oui / non)
Quantité
Code postal
5 Réponses :
Voici ce que j'ai utilisé dans le passé
Field -> Data Type ----- --------- Id int Phone # varchar Email varchar Desc varchar Name varchar Ssn varchar Price decimal, money, smallmoney ShipDate datetime Sex bit Discont bit Quantity int ZipCode varchar
J'ai une table nommée de table contenant deux colonnes classid et classe. Je stockais seulement 12 enregistrements dans cette table. E.G: IX, X, XI, XII, BCOM-I, etc. Ma question: Quel type de données me suggérez-vous pour mes colonnes classiques et pourquoi?
@ Kashif - Si vous savez déjà, il n'y aura que 12 articles et que vous savez exactement ce que ces articles vont être, je ne les mettrai probablement pas dans une base de données du tout. Si je devais choisir, je choisirais certainement une colonne INT pour l'ID.
J'ai en fait une base de données d'étudiants. Je lie ma table de classe avec une combinaison ComboBox et garder la classe de colonne dans la table de classe comme membre d'affichage et classid comme valeur memeber. Dans ma table StudentInfo, j'utilise un Classid Classid I.E StudentInfo.classide avec une clé étrangère à la classe.Classid. J'espère maintenant que vous comprenez ma situation
Qu'en est-il de garder la colonne CLASS.CLASSID en tant que octet que l'octet occupe moins de mémoire dans la base de données par rapport à INT? J'ai actuellement son numéro de données numérique (2,0)
ID - int Telephone - varchar(12) email - varchar(size) descripion varchar(max) name -varchar(size) ssn - varchar(11) price - smallmoney (or money if needed) shipdate - date (for sql server 2008, or smalldatetime for pre-2008) discontinued - bit quanity - int zipcode - varchar(10) A lot of folks are going to recommend nvarchar in all cases instead of varchar, but knowing my sites/audience, I don't need to allow for international character sets and don't want to waste the space/speed/resources (minimal I know). If you need to, then substitute nvarchar where appropriate
Je vois tout le monde utilise Varchar pour le SSN, est-ce parce que vous voulez stocker le trait d'union?
Une règle de base que j'ai été enseignée il y a des années (et son bien fonctionné) Un champ de numéro est destiné aux données pouvant avoir une arithmétique. Un numéro de téléphone ou ID (SSN) n'est pas un facteur à un calcul, mais plutôt une chaîne de caractères. Les personnages sont tous numériques mais ce qui n'est pas particulièrement important.
Je discuterais contre une chaîne pour une valeur connue pour toujours être numérique et sera probablement recherchée. Un type d'entier indiquera mieux (et créera également un index plus petit). J'utiliserais également un champ plus long pour le numéro de téléphone pour permettre aux formats internationaux (l'UIT nécessite au moins 16 ans, y compris le premier "+").
Mais si vous autorisez un téléphone international NOS, vous devez peut-être également permettre aux types SSN internationaux, qui ne sont pas entièrement numériques. Par exemple, le numéro de Ni britannique, pas aussi utile que SSN, mais pas non plus uniquement numérique - "AA 99 99 99 A".
Toute "valeur numérique" où les zéros principaux sont importants et non déduits de la longueur doivent être variés, sinon les zéros seront perdus.
Pour @ paulgregory's Point, les SSN et les codes postaux peuvent certainement commencer par un 0 précédent, qui sera perdu si stocké comme int.
ID int or bigint Telephone Number varchar Email varchar Description varchar Name varchar SSN varchar Price money Ship Date datetime or date Sex (m/f) char(1) Discontinued (yes/no) bit Quantity int Zip Code varchar
Une brève recommandation:
Donc, votre arbre de décision pourrait être comme celui-ci:
Est-ce que j'ai besoin de caractères non occidentaux-européens? Si oui -> Utilisez est ma chaîne très courte (<5 caractères) et typiquement la même longueur? Si oui: Utilisez CHAR, sinon Varchar
Ai-je besoin de très énormes volumes de texte? Si tel est le cas, utilisez Varchar (Max), sinon la taille pour correspondre à vos besoins
texte, ntext, image : Tous ces types sont char vs. code> varchar : char est longueur fixe et il s'agira d'entrées de remplissage avec des espaces à la longueur définie . Fonctionne mieux pour les chaînes courtes (<5 caractères), par ex. Les codes, comme la devise (presque toujours 3 caractères), le statut américain (2 caractères), etc. varchar de l'autre main fonctionne mieux pour des chaînes plus longues et ne stocke que autant de caractères que sont insérées / mises à jour. Si vous définissez un varchar (200) et uniquement insérer Noël dans le champ, votre champ occupe 9 caractères (et un peu de frais de surcharge)
nchar / nvarchar : Versions Unicode de ce qui précède; stocke toujours 2 octets par caractères, donc votre champ avec Noël dans son stockage de 9 caractères et utilisera 18 octets pour le faire. Ceux-ci sont nécessaires si vous avez des caractères non occidentaux-européens - tels que cyrillique, arabe, hébreu, asiatique ou d'autres alphabets.
varchar (max) / nvarchar (max) sont les remplaçants du texte et ntext - stocker jusqu'à 2 gbyte ( 2 milliards d'octets) de données - c'est plus de 300 fois le contenu de la guerre de Tolstoi et de la paix - devrait suffire à la
NCHAR / NVARCHAR Types, sinon Char / Varchar
J'ai une table nommée de table contenant deux colonnes classid et classe. Je stockais seulement 12 enregistrements dans cette table. E.G: IX, X, XI, XII, BCOM-I, etc. Ma question: Quel type de données me suggérez-vous pour mes colonnes classiques et pourquoi?
+1, peut-être la peine d'ajout de votre vue sur le choix du choix le plus approprié de décimal / numérique, réel et float.
Si votre demande ciblait un public mondial, je vous recommanderais d'utiliser les types de chaîne Unicode (
NCHAR ,nvarchar ) au lieu des types plus anciens de 8 bits (Char ,varchar ) pour tout ce qui est saisi ou affiché à l'utilisateur.