Các trường MySQL phổ biến và các kiểu dữ liệu thích hợp của chúng

Tôi đang thiết lập một cơ sở dữ liệu MySQL rất nhỏ để lưu trữ tên, họ, email và số điện thoại và đang đấu tranh để tìm loại dữ liệu 'hoàn hảo' cho từng trường. Tôi biết không có cái gọi là một câu trả lời hoàn hảo, nhưng phải có một số loại quy ước chung cho các trường thường được sử dụng như những trường này. Ví dụ: tôi đã xác định rằng một số điện thoại Hoa Kỳ chưa được định dạng quá lớn để được lưu trữ dưới dạng int không dấu, ít nhất nó phải là bigint.

Bởi vì tôi chắc chắn rằng những người khác có thể sẽ thấy điều này hữu ích, tôi không muốn giới hạn câu hỏi của mình chỉ trong các trường mà tôi đã đề cập ở trên.

Những kiểu dữ liệu nào thích hợp cho các trường cơ sở dữ liệu chung? Các trường như số điện thoại, email và địa chỉ?

Ai đó sẽ đăng một câu trả lời hay hơn thế này, nhưng tôi chỉ muốn nói rõ rằng cá nhân tôi sẽ không bao giờ lưu trữ số điện thoại trong bất kỳ loại trường số nguyên nào, chủ yếu là vì:

1. Bạn không cần thực hiện bất kỳ phép số học nào với nó, và
2. Không sớm thì muộn ai đó sẽ cố gắng (làm điều gì đó như) đặt dấu ngoặc quanh mã vùng của họ.

Nói chung, tôi dường như hầu như chỉ sử dụng:

• INT (11) cho bất kỳ thứ gì là ID hoặc tham chiếu đến ID khác
• DATETIME cho dấu thời gian
• VARCHAR (255) cho mọi thứ được đảm bảo dưới 255 ký tự (tiêu đề trang, tên, v.v.)
• TEXT cho khá nhiều thứ khác.

Tất nhiên vẫn có những trường hợp ngoại lệ, nhưng tôi thấy rằng điều đó bao gồm hầu hết các trường hợp.

Dưới đây là một số kiểu dữ liệu phổ biến mà tôi sử dụng (mặc dù tôi không phải là dân chuyên nghiệp):

| 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       

Theo kinh nghiệm của tôi, các trường tên / họ phải có ít nhất 48 ký tự - có những tên từ một số quốc gia như Malaysia hoặc Ấn Độ ở dạng đầy đủ rất dài.

Số điện thoại và mã bưu điện bạn phải luôn coi là văn bản chứ không phải số. Lý do bình thường được đưa ra là có những mã bưu điện bắt đầu bằng 0 và ở một số quốc gia, số điện thoại cũng có thể bắt đầu bằng 0. Nhưng lý do thực sự là chúng không phải là số - chúng là số nhận dạng tình cờ được tạo thành của các chữ số (và đó là bỏ qua các quốc gia như Canada có các chữ cái trong mã bưu điện của họ). Vì vậy, hãy lưu trữ chúng trong một trường văn bản.

Trong MySQL, bạn có thể sử dụng các trường VARCHAR cho loại thông tin này. Mặc dù nghe có vẻ lười biếng nhưng điều đó có nghĩa là bạn không cần phải quá lo lắng về kích thước tối thiểu phù hợp.

Vì bạn sẽ xử lý dữ liệu có độ dài thay đổi (tên, địa chỉ email), nên bạn sẽ muốn sử dụng VARCHAR. Dung lượng mà trường VARCHAR chiếm dụng là [field length]+ 1 byte, độ dài tối đa là 255, vì vậy tôi sẽ không lo lắng quá nhiều về việc cố gắng tìm một kích thước hoàn hảo. Hãy xem những gì bạn tưởng tượng có thể là độ dài dài nhất có thể là, sau đó nhân đôi nó và đặt nó làm giới hạn VARCHAR của bạn. Mà nói...:

Tôi thường đặt các trường email là VARCHAR (100) - tôi chưa tìm ra vấn đề từ đó. Tên tôi đặt thành VARCHAR (50).

Như những người khác đã nói, số điện thoại và mã zip / mã bưu điện thực sự không phải là giá trị số, chúng là chuỗi chứa các chữ số 0-9 (và đôi khi nhiều hơn!), Và do đó bạn nên coi chúng như một chuỗi. VARCHAR (20) phải đủ tốt.

Lưu ý rằng nếu bạn lưu trữ số điện thoại dưới dạng số nguyên, nhiều hệ thống sẽ cho rằng số bắt đầu bằng 0 là số bát phân (cơ số 8)! Do đó, số điện thoại hoàn toàn hợp lệ "0731602412" sẽ được đưa vào cơ sở dữ liệu của bạn dưới dạng số thập phân "124192010" !!

Tôi đang làm điều tương tự, và đây là những gì tôi đã làm.

Tôi đã sử dụng các bảng riêng biệt cho tên, địa chỉ, email và số, mỗi bảng có một cột NameID là khóa ngoại trên mọi thứ ngoại trừ bảng Tên, trên đó là khóa nhóm chính. Tôi đã sử dụng MainName và FirstName thay vì LastName và FirstName để cho phép các mục nhập doanh nghiệp cũng như mục nhập cá nhân, nhưng bạn có thể không cần đến điều đó.

Cột NameID trở thành một chữ cái trong tất cả các bảng vì tôi khá chắc chắn rằng tôi sẽ không tạo nhiều hơn 32000 mục nhập. Hầu hết mọi thứ khác đều là varchar (n) nằm trong khoảng từ 20 đến 200, tùy thuộc vào những gì bạn muốn lưu trữ (Sinh nhật, nhận xét, email, tên thực sự dài). Điều đó thực sự phụ thuộc vào loại nội dung bạn đang lưu trữ.

Bảng Số là nơi tôi đi chệch khỏi đó. Tôi đã thiết lập nó để có năm cột có nhãn NameID, Phone #, CountryCode, Extension và PhoneType. Tôi đã thảo luận về NameID. Số điện thoại là varchar (12) với ràng buộc kiểm tra trông giống như sau: KIỂM TRA (Số điện thoại như '[0-9] [0-9] [0-9] - [0-9] [0-9] [0 -9] - [0-9] [0-9] [0-9] [0-9] '). Điều này đảm bảo rằng chỉ những gì tôi muốn mới được đưa vào cơ sở dữ liệu và dữ liệu vẫn rất nhất quán. Phần mở rộng và mã quốc gia mà tôi gọi là nullable smallints, nhưng chúng có thể là varchar nếu bạn muốn. PhoneType là varchar (20) và không thể null.

Hi vọng điêu nay co ich!