Ortak MySQL alanları ve uygun veri türleri

Adı, soyadı, e-postayı ve telefon numarasını saklayan çok küçük bir MySQL veritabanı kuruyorum ve her alan için 'mükemmel' veri türünü bulmakta zorlanıyorum. Kusursuz cevap diye bir şey olmadığını biliyorum, ancak bunun gibi yaygın olarak kullanılan alanlar için bir tür ortak konvansiyon olmalı. Örneğin, biçimlendirilmemiş bir ABD telefon numarasının imzasız int olarak saklanamayacak kadar büyük olduğunu belirledim, en azından bir bigint olmalıdır.

Diğer insanların bunu faydalı bulacağından emin olduğum için sorumu sadece yukarıda bahsettiğim alanlarla sınırlamak istemiyorum.

Ortak veritabanı alanları için hangi veri türleri uygundur? Telefon numarası, e-posta ve adres gibi alanlar?

Birisi bundan çok daha iyi bir cevap gönderecek, ancak kişisel olarak bir telefon numarasını herhangi bir tam sayı alanına asla saklamayacağımı belirtmek istedim, çünkü esas olarak:

1. Onunla herhangi bir aritmetik işlem yapmanıza gerek yok ve
2. Er ya da geç birisi alan kodunun etrafına parantez koymaya çalışacaktır (buna benzer bir şey yapacaktır).

Genel olarak, neredeyse yalnızca şunu kullanıyorum:

• INT (11) bir kimlik olan veya başka bir kimliğe başvuran herhangi bir şey için
• Zaman damgaları için DATETIME
• 255 karakterin altında olması garanti edilen her şey için (sayfa başlıkları, adlar, vb.) VARCHAR (255)
• Hemen hemen her şey için METİN.

Elbette istisnalar var, ancak bunun çoğu olasılığı kapsadığını görüyorum.

İşte kullandığım bazı yaygın veri türleri (yine de pek profesyonel değilim):

| 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       

Tecrübelerime göre, ad / soyadı alanları en az 48 karakter olmalıdır - Malezya veya Hindistan gibi bazı ülkelerden tam olarak çok uzun adlar vardır.

Telefon numaraları ve posta kodları her zaman numara olarak değil metin olarak değerlendirilmelidir. Verilen normal neden, 0 ile başlayan posta kodlarının bulunması ve bazı ülkelerde telefon numaralarının da 0 ile başlayabilmesidir. Ancak gerçek neden, sayı olmamalarıdır - uydurulmuş tanımlayıcılardır . (ve bu Kanada gibi posta kodlarında harf olan ülkeleri görmezden geliyor). Bu yüzden onları bir metin alanında saklayın.

MySQL'de bu tür bilgiler için VARCHAR alanlarını kullanabilirsiniz. Tembel görünmekle birlikte, doğru minimum boyut konusunda fazla endişelenmenize gerek olmadığı anlamına gelir.

Değişken uzunluktaki verilerle (isimler, e-posta adresleri) ilgileneceğiniz için, o zaman VARCHAR'ı kullanmak isteyeceksiniz. Bir VARCHAR alanı tarafından kaplanan alan miktarı [field length]+ 1 bayt, maksimum uzunluk 255'tir, bu yüzden mükemmel bir boyut bulmaya çalışmak konusunda fazla endişelenmem. En uzun olabileceğini düşündüğünüz uzunluğa bir göz atın, ardından ikiye katlayın ve bunu VARCHAR sınırınız olarak ayarlayın. Bahsedilen...:

Genelde e-posta alanlarını VARCHAR (100) olarak ayarlıyorum - henüz bundan bir sorunla karşılaşmadım. VARCHAR (50) olarak belirlediğim isimler.

Diğerlerinin de söylediği gibi, telefon numaraları ve posta kodları gerçekte sayısal değerler değildir, 0-9 rakamlarını (ve bazen daha fazlasını!) İçeren dizelerdir ve bu nedenle bunları bir dize olarak ele almalısınız. VARCHAR (20) yeterli olmalıdır.

Telefon numaralarını tam sayı olarak saklayacak olsaydınız, birçok sistemin 0 ile başlayan bir sayının sekizlik (8 tabanı) bir sayı olduğunu varsayacağını unutmayın! Bu nedenle, mükemmel bir şekilde geçerli olan telefon numarası "0731602412" veritabanınıza "124192010" ondalık sayı olarak yerleştirilir !!

Ben de aynı şeyi yapıyorum ve işte yaptığım şey.

Ad, adres, e-posta ve numaralar için ayrı tablolar kullandım; her biri, birincil kümelenmiş anahtar olduğu Ad tablosu dışındaki her şeyde yabancı anahtar olan bir Ad Kimliği sütununa sahip. Kişisel girişlerin yanı sıra iş girişlerine de izin vermek için LastName ve FirstName yerine MainName ve FirstName kullandım, ancak buna ihtiyacınız olmayabilir.

NameID sütunu tüm tablolarda küçük bir değer olacak çünkü 32000'den fazla giriş yapmayacağımdan oldukça eminim. Neredeyse diğer her şey, saklamak istediğiniz şeye (Doğum günleri, yorumlar, e-postalar, gerçekten uzun isimler) bağlı olarak 20 ile 200 arasında değişen varchar (n) 'dır. Bu gerçekten ne tür şeyler depoladığınıza bağlıdır.

Numaralar tablosu bundan saptığım yerdir. NameID, Phone #, CountryCode, Extension ve PhoneType etiketli beş sütuna sahip olacak şekilde ayarladım. NameID'yi zaten tartışmıştım. Telefon numarası, şuna benzer bir kontrol kısıtlamasına sahip varchar (12) 'dir: CHECK (Phone # like' [0-9] [0-9] [0-9] - [0-9] [0-9] [0 -9] - [0-9] [0-9] [0-9] [0-9] '). Bu, yalnızca istediğim şeyin veritabanına girmesini ve verilerin çok tutarlı kalmasını sağlar. Nullable smallints olarak adlandırdığım uzantı ve ülke kodları, ancak isterseniz bunlar varchar olabilir. PhoneType varchar (20) ve null olamaz.

Bu yardımcı olur umarım!