Kolom MySQL umum dan tipe datanya yang sesuai


111

Saya menyiapkan database MySQL yang sangat kecil yang menyimpan, nama depan, nama belakang, email, dan nomor telepon dan saya berjuang untuk menemukan tipe data yang 'sempurna' untuk setiap bidang. Saya tahu tidak ada yang namanya jawaban yang sempurna, tetapi harus ada semacam kesepakatan umum untuk bidang yang umum digunakan seperti ini. Misalnya, saya telah menentukan bahwa nomor telepon AS yang tidak diformat terlalu besar untuk disimpan sebagai int unsigned, setidaknya harus bigint.

Karena saya yakin orang lain mungkin akan menganggap ini berguna, saya tidak ingin membatasi pertanyaan saya hanya pada bidang yang saya sebutkan di atas.

Jenis data apa yang sesuai untuk bidang database umum? Bidang seperti nomor telepon, email, dan alamat?

Jawaban:


71

Seseorang akan memposting jawaban yang jauh lebih baik dari ini, tetapi hanya ingin menegaskan bahwa secara pribadi saya tidak akan pernah menyimpan nomor telepon dalam bidang bilangan bulat apa pun, terutama karena:

  1. Anda tidak perlu melakukan aritmatika apa pun dengannya, dan
  2. Cepat atau lambat seseorang akan mencoba (melakukan sesuatu seperti) memberi tanda kurung di sekitar kode areanya.

Secara umum, saya tampaknya hampir secara eksklusif menggunakan:

  • INT (11) untuk apa pun yang merupakan ID atau referensi ID lain
  • DATETIME untuk stempel waktu
  • VARCHAR (255) untuk apapun yang dijamin kurang dari 255 karakter (judul halaman, nama, dll)
  • TEXT untuk hampir semua hal lainnya.

Tentu saja ada pengecualian, tetapi saya menemukan itu mencakup sebagian besar kemungkinan.


2
Selain itu, bilangan bulat hanya mendukung hingga nilai 2 miliar. Itu 2.000.000.000. Benar-benar tidak cukup tempat ketika Anda ingin menyimpan nomor telepon internasional, lengkap dengan kode negara. Saya bahkan tidak melihat bagaimana Anda dapat menemukan cukup ruang untuk menyimpan nomor seperti 655-405-4055 (6,554,054,055)
Kibbee

29
Ditambah itu salah. Seseorang yang jauh lebih bijaksana daripada saya memberi tahu saya ketika saya memulai bahwa (dengan basis data) hanya karena sesuatu tampak seperti angka tidak berarti itu atau harus diperlakukan seperti itu ...
da5id

14
Menggunakan varchar (255) secara membabi buta adalah ide yang buruk. Setidaknya terapkan beberapa upaya dasar untuk menebak panjangnya.
Morgan Tocker

4
@Morgan Tocker: ini adalah praktik terbaik, apa pun di bawah 255 karakter akan menempati ruang yang sama.
raveren

7
@Raveren: Ini khusus untuk mesin penyimpanan - dan penyimpanan bukan satu-satunya biaya. Penyortiran data dan tabel sementara (mesin memori) akan menggunakan jumlah yang tetap.
Morgan Tocker

44

Berikut adalah beberapa tipe data umum yang saya gunakan (saya tidak terlalu ahli):

| 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       

4
@yentsun - Email sebenarnya hanya 254; baca komentar untuk pertanyaan yang diposting Neil McGuigan
RustyTheBoyRobot

16

Menurut pengalaman saya, field nama depan / nama belakang minimal harus 48 karakter - ada nama dari beberapa negara seperti Malaysia atau India yang sangat panjang dalam bentuk lengkapnya.

Nomor telepon dan kode pos harus selalu Anda perlakukan sebagai teks, bukan angka. Alasan normal yang diberikan adalah bahwa ada kode pos yang dimulai dengan 0, dan di beberapa negara, nomor telepon juga dapat dimulai dengan 0. Tetapi alasan sebenarnya adalah bahwa itu bukan angka - itu adalah pengenal yang kebetulan dibuat-buat digit numerik (dan itu mengabaikan negara seperti Kanada yang memiliki huruf di kode posnya). Jadi simpan di kolom teks.

Di MySQL Anda dapat menggunakan kolom VARCHAR untuk jenis informasi ini. Walaupun terdengar malas, itu artinya Anda tidak perlu terlalu khawatir tentang ukuran minimum yang tepat.


Untuk lebih mendukung komentar Anda tentang kode pos, di negara-negara seperti Inggris atau Kanada, kode pos adalah alfanumerik.
Andy Baird

Anda mungkin perlu memperhatikan tentang ukuran minimum yang tepat stackoverflow.com/questions/262238/…
Rohit Banga

@iamrohitbanga Meskipun Anda benar untuk data yang didefinisikan dengan baik, untuk nama VARCHAR(255)masuk akal.
staticsan

9

Karena Anda akan berurusan dengan data dengan panjang variabel (nama, alamat email), maka Anda akan ingin menggunakan VARCHAR. Jumlah ruang yang digunakan oleh bidang VARCHAR adalah [field length]+ 1 byte, hingga panjang maksimal 255, jadi saya tidak akan terlalu khawatir untuk mencoba menemukan ukuran yang sempurna. Lihatlah apa yang menurut Anda mungkin merupakan panjang terpanjang, lalu gandakan dan setel sebagai batas VARCHAR Anda. Yang mengatakan ...:

Saya biasanya mengatur bidang email menjadi VARCHAR (100) - saya belum menemukan masalah dari itu. Nama yang saya setel ke VARCHAR (50).

Seperti yang dikatakan orang lain, nomor telepon dan kode zip / pos sebenarnya bukan nilai numerik, mereka adalah string yang berisi angka 0-9 (dan terkadang lebih!), Dan oleh karena itu Anda harus memperlakukannya sebagai string. VARCHAR (20) seharusnya cukup baik.

Perhatikan bahwa jika Anda menyimpan nomor telepon sebagai bilangan bulat, banyak sistem akan menganggap bahwa angka yang dimulai dengan 0 adalah angka oktal (basis 8)! Oleh karena itu, nomor telepon yang benar-benar valid "0731602412" akan dimasukkan ke dalam database Anda sebagai nomor desimal "124192010" !!


1

Saya melakukan hal yang sama, dan inilah yang saya lakukan.

Saya menggunakan tabel terpisah untuk nama, alamat, email, dan angka, masing-masing dengan kolom NameID yang merupakan kunci asing pada segala hal kecuali tabel Nama, di mana itu adalah kunci cluster utama. Saya menggunakan MainName dan FirstName alih-alih LastName dan FirstName untuk memungkinkan entri bisnis serta entri pribadi, tetapi Anda mungkin tidak membutuhkannya.

Kolom NameID menjadi smallint di semua tabel karena saya cukup yakin saya tidak akan membuat lebih dari 32000 entri. Hampir semuanya adalah varchar (n) mulai dari 20 hingga 200, tergantung pada apa yang ingin Anda simpan (Ulang tahun, komentar, email, nama yang sangat panjang). Itu benar-benar tergantung pada jenis barang yang Anda simpan.

Tabel Angka adalah tempat saya menyimpang dari itu. Saya mengaturnya agar memiliki lima kolom berlabel NameID, Phone #, CountryCode, Extension, dan PhoneType. Saya sudah membahas NameID. Ponsel # adalah varchar (12) dengan batasan centang yang terlihat seperti ini: CHECK (Phone # like '[0-9] [0-9] [0-9] - [0-9] [0-9] [0 -9] - [0-9] [0-9] [0-9] [0-9] '). Ini memastikan bahwa hanya yang saya inginkan yang masuk ke dalam database dan datanya tetap sangat konsisten. Kode ekstensi dan negara yang saya sebut smallints nullable, tetapi itu bisa menjadi varchar jika Anda mau. PhoneType adalah varchar (20) dan bukan nullable.

Semoga ini membantu!

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.