Gemeinsame MySQL Felder und ihre entsprechenden Datentypen

stimmen
96

Ich gründe eine sehr kleine MySQL-Datenbank, die speichert, Vorname, Nachname, E-Mail und Telefonnummer und ist kämpfen, um den ‚perfekte‘ Datentyp für jedes Feld zu finden. Ich weiß, dass es nicht so etwas wie eine perfekte Antwort, aber es muss für häufig verwendete Felder wie diese eine Art gemeinsamen Konvention sein. Zum Beispiel habe ich festgestellt, dass eine unformatierte US-Telefonnummer zu groß ist, als unsigned int gespeichert werden kann, muss es mindestens ein Bigint sein.

Weil ich sicher, dass andere Leute wahrscheinlich bin würde dies nützlich finden, nicht ich möchte, dass meine Frage beschränken, um nur die Felder, die ich oben erwähnt.

Welche Datentypen sind für gemeinsame Datenbankfelder? Felder wie Telefonnummer, E-Mail und Adresse?

Veröffentlicht am 10/12/2008 um 01:48
quelle vom benutzer
In anderen Sprachen...                            


5 antworten

stimmen
59

Jemand wird eine viel bessere Antwort als diese schreiben, aber ich wollte nur darauf hinweisen, dass ich persönlich würde nie eine Telefonnummer in jeder Art von Integer-Feld speichern, vor allem, weil:

  1. Sie müssen nicht mit ihm jede Art von Arithmetik zu tun, und
  2. Früher oder später wird jemand wird versuchen, zu (so etwas wie) setzen Klammern um ihre Ortsvorwahl.

Im Allgemeinen jedoch scheinen ich fast ausschließlich auf:

  • INT (11) für alles, was entweder eine ID oder verweist auf eine andere ID ist
  • DATETIME- für Zeitstempel
  • VARCHAR (255) für alles garantiert weniger als 255 Zeichen sein (Seitentitel, Namen, usw.)
  • TEXT für so ziemlich alles andere.

Natürlich gibt es Ausnahmen, aber ich finde, dass die meisten Eventualitäten abdeckt.

Beantwortet am 10/12/2008 um 01:57
quelle vom benutzer

stimmen
25

Hier sind einige gemeinsame Datentypen Ich benutze (ich bin nicht viel von einem Profi obwohl):

| Column           | Data type     | Note
| ---------------- | ------------- | -------------------------------------
| id               | INTEGER       | AUTO_INCREMENT, UNSIGNED                                                          |  
| uuid             | CHAR(36)      | or CHAR(16) binary                                                                |  
| title            | VARCHAR(255)  |                                                                                   |  
| full name        | VARCHAR(70)   |                                                                                   |  
| gender           | TINYINT       | UNSIGNED                                                                          |  
| description      | TINYTEXT      | often may not be enough, use TEXT 
                                     instead          
| post body        | TEXT          |                                                                                   |  
| email            | VARCHAR(255)  |                                                                                   |  
| url              | VARCHAR(2083) | MySQL version < 5.0.3 - use TEXT                                                  |  
| salt             | CHAR(x)       | randomly generated string, usually of 
                                     fixed length (x)    
| digest (md5)     | CHAR(32)      |                                                                                   |  
| phone number     | VARCHAR(20)   |                                                                                   |  
| US zip code      | CHAR(5)       | Use CHAR(10) if you store extended 
                                     codes      
| US/Canada p.code | CHAR(6)       |                                                                                   |  
| file path        | VARCHAR(255)  |                                                                                   |  
| 5-star rating    | DECIMAL(3,2)  | UNSIGNED                                                                          |  
| price            | DECIMAL(10,2) | UNSIGNED                                                                          |  
| date (creation)  | DATE/DATETIME | usually displayed as initial date of 
                                     a post                                       |  
| date (tracking)  | TIMESTAMP     | can be used for tracking changes in a 
                                     post                                        |  
| tags, categories | TINYTEXT      | comma separated values *                                                          |  
| status           | TINYINT(1)    | 1 – published, 0 – unpublished, … You 
                                     can also use ENUM for human-readable 
                                     values
| json data        | JSON          | or LONGTEXT       
Beantwortet am 29/12/2009 um 00:40
quelle vom benutzer

stimmen
14

Nach meiner Erfahrung, Vorname / Name Felder sollten mindestens 48 Zeichen lang sein - es gibt Namen von einigen Ländern wie Malaysia oder Indien, die in ihrer ganzen Form sehr lang sind.

Telefonnummern und Postleitzahlen Sie sollten immer als Text behandeln, keine Zahlen. Der normale Grund gegeben ist , dass es Postleitzahlen , die mit 0, und in einigen Ländern beginnen, Telefonnummern können auch mit 0. Aber der wahre Grund ist , beginnen , dass sie nicht sind Zahlen - sie sind Kennungen , die aus zufällig werden von numerischen Ziffern (und das ist Ländern wie Kanada zu ignorieren , die Buchstaben in ihren Postleitzahlen haben). So speichern sie in einem Textfeld.

In MySQL können Sie VARCHAR Felder für diese Art von Informationen verwenden. Während es faul klingt, es heißt, Sie müssen nicht allzu besorgt über die richtige Mindestgröße.

Beantwortet am 10/12/2008 um 02:01
quelle vom benutzer

stimmen
8

Da Sie mit Daten einer variablen Länge (Namen, E - Mail - Adressen) zu tun haben werden, dann würden Sie VARCHAR verwenden werden wollen. Die Menge an Speicherplatz von einem VARCHAR Feld aufgenommen ist [field length]+ 1 Bytes, bis max Länge 255, also würde mir keine Sorgen zu viel zu versuchen , eine perfekte Größe zu finden. Werfen Sie einen Blick auf das, was Sie sich vorstellen könnte die längste Länge sein könnte sein, dann verdoppeln und festgelegt , dass als VARCHAR Grenze. Das gesagt...:

I in der Regel gesetzt E-Mail-Felder VARCHAR (100) zu sein - ich habe nicht kommen mit einem Problem aus, dass noch. Namen, die ich auf VARCHAR (50).

Wie die anderen gesagt haben, Telefonnummern und zip / Postleitzahlen sind nicht wirklich numerische Werte, sie sind Strings die Ziffern 0-9 enthalten (und manchmal mehr!), Und deshalb sollten Sie sie als String behandeln. VARCHAR (20) sollte auch ausreichend sein.

Beachten Sie, dass, wenn Sie Telefonnummern als ganze Zahlen speichern sind, werden viele Systeme davon ausgehen, dass eine Zahl mit 0 beginnt eine Oktal (Basis 8) Nummer! Daher wäre die absolut gültige Telefonnummer „0731602412“ setzt in Ihre Datenbank als Dezimalzahl „124192010“ erhalten !!

Beantwortet am 10/12/2008 um 02:08
quelle vom benutzer

stimmen
1

Ich mache über die gleiche Sache, und hier ist, was ich tat.

Ich benutzen getrennte Tabellen für Namen, Adresse, E-Mail und Zahlen, die jeweils mit einer NameID Spalte, die ein Fremdschlüssel auf allem außer der Name-Tabelle ist, auf das es die primären gruppierten Schlüssel. Ich benutzen MainName und Vornamen statt Nachnamen und Vornamen für Geschäftseinträge sowie persönliche Einträge zu ermöglichen, Sie können jedoch keine Notwendigkeit dafür.

Die NameID Spalte erhält einen smallint in allen Tabellen zu sein, weil ich ziemlich sicher bin, dass ich nicht mehr als 32.000 Einträge machen. Fast alles andere ist im Bereich varchar (n) von 20 bis 200, je nachdem, was Sie wollen, speichern (Geburtstage, Kommentare, E-Mails, wirklich lange Namen). Das ist wirklich davon abhängig, welche Art von Zeug Sie speichern.

Die Zahlen Tabelle ist, wo ich von dem abweichen. Ich stelle es fünf Spalten haben bis markierte NameID, Telefon #, Countrycode, Erweiterung und Phone. Ich besprach bereits NameID. Telefon # ist varchar (12) mit einer Check-Einschränkung suchen etwas wie folgt aus: CHECK (Telefon # wie ‚[0-9] [0-9] [0-9] - [0-9] [0-9] [0 -9] - [0-9] [0-9] [0-9] [0-9]). Dadurch wird sichergestellt, dass nur das, was ich will macht es in die Datenbank und die Daten bleiben sehr konstant. Die Erweiterung und Ländercodes I genannt nullable smallints, aber die varchar sein könnte, wenn man wollte. Phone ist varchar (20) und ist nicht auf NULL festlegbare.

Hoffe das hilft!

Beantwortet am 26/02/2010 um 06:13
quelle vom benutzer

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more