Tôi đang thiết kế một bảng cơ sở dữ liệu và một lần nữa tự hỏi mình cùng một câu hỏi ngu ngốc: Trường tên đầu tiên phải dài bao nhiêu?
Có ai có một danh sách độ dài hợp lý cho các trường phổ biến nhất , chẳng hạn như tên, họ và địa chỉ email không?
Tôi đang thiết kế một bảng cơ sở dữ liệu và một lần nữa tự hỏi mình cùng một câu hỏi ngu ngốc: Trường tên đầu tiên phải dài bao nhiêu?
Có ai có một danh sách độ dài hợp lý cho các trường phổ biến nhất , chẳng hạn như tên, họ và địa chỉ email không?
Câu trả lời:
Khuyến nghị của W3C:
Nếu thiết kế một biểu mẫu hoặc cơ sở dữ liệu sẽ chấp nhận tên từ những người có nhiều nền tảng khác nhau, bạn nên tự hỏi liệu bạn có thực sự cần phải có các trường riêng cho tên và họ của họ không.
Hãy nhớ rằng tên trong một số nền văn hóa có thể dài hơn rất nhiều so với tên của bạn. ... Tránh hạn chế kích thước lĩnh vực cho tên trong cơ sở dữ liệu của bạn . Cụ thể, đừng cho rằng một tên tiếng Nhật gồm bốn ký tự trong UTF-8 sẽ phù hợp với bốn byte - bạn có thể thực sự cần 12.
Đối với các trường cơ sở dữ liệu, VARCHAR(255)
là một lựa chọn mặc định an toàn, trừ khi bạn thực sự có thể đưa ra một lý do chính đáng để sử dụng một cái gì đó khác. Đối với các ứng dụng web thông thường, hiệu suất sẽ không phải là vấn đề. Đừng tối ưu hóa sớm.
Tôi vừa truy vấn cơ sở dữ liệu của mình với hàng triệu khách hàng ở Hoa Kỳ.
Độ dài tên tối đa là 46. Tôi đi với 50. (Tất nhiên, chỉ có 500 trong số đó trên 25 tuổi và tất cả đều là trường hợp nhập dữ liệu dẫn đến thêm rác trong lĩnh vực đó.)
Tên cuối cùng giống với tên.
Địa chỉ email tối đa là 62 ký tự. Hầu hết những cái dài hơn thực sự là danh sách các địa chỉ email được phân tách bằng dấu chấm phẩy.
Địa chỉ đường phố đạt tối đa 95 ký tự. Những cái dài đều hợp lệ.
Chiều dài thành phố tối đa là 35.
Đây phải là một sự lan truyền thống kê tốt cho những người ở Mỹ. Nếu bạn có nội địa hóa để xem xét, các con số có thể thay đổi đáng kể.
Danh mục Tiêu chuẩn Dữ liệu của Chính phủ Vương quốc Anh chi tiết các tiêu chuẩn của Vương quốc Anh cho loại điều này. Nó gợi ý 35 ký tự cho mỗi Tên đã cho và Tên gia đình hoặc 70 ký tự cho một trường để giữ Tên đầy đủ và 255 ký tự cho một địa chỉ email. Trong số những thứ khác ..
Min Max
Hostname 1 255
Domain Name 4 253
Email Address 7 254
Email Address [1] 3 254
Telephone Number 10 15
Telephone Number [2] 3 26
HTTP(S) URL w domain name 11 2083
URL [3] 6 2083
Postal Code [4] 2 11
IP Address (incl ipv6) 7 45
Longitude numeric 9,6
Latitude numeric 8,6
Money[5] numeric 19,4
[1] Allow local domains or TLD-only domains
[2] Allow short numbers like 911 and extensions like 16045551212x12345
[3] Allow local domains, tv:// scheme
[4] http://en.wikipedia.org/wiki/List_of_postal_codes. Use max 12 if storing dash or space
[5] http://stackoverflow.com/questions/224462/storing-money-in-a-decimal-column-what-precision-and-scale
Tên cá nhân là Polynym (tên có nhiều thành phần có thể sắp xếp ), Mononymous (tên chỉ có một thành phần) hoặc Pictonym (tên được đại diện bởi một hình ảnh - điều này tồn tại do những người như Prince).
Một người có thể có nhiều tên, đóng vai trò, chẳng hạn như PHÁP LÝ, HÔN NHÂN, MAIDEN, ƯU TIÊN, SOBRIQUET, PSEUDONYM, v.v. Bạn có thể có các quy tắc kinh doanh, chẳng hạn như "một người chỉ có thể có một tên hợp pháp tại một thời điểm, nhưng nhiều bút danh tại một thời điểm".
Vài ví dụ:
names: [
{
type:"POLYNYM",
role:"LEGAL",
given:"George",
middle:"Herman",
moniker:"Babe",
surname:"Ruth",
generation:"JUNIOR"
},
{
type:"MONONYM",
role:"SOBRIQUET",
mononym:"The Bambino" /* mononyms can be more than one word, but only one component */
},
{
type:"MONONYM",
role:"SOBRIQUET",
mononym:"The Sultan of Swat"
}
]
hoặc là
names: [
{
type:"POLYNYM",
role:"PREFERRED",
given:"Malcolm",
surname:"X"
},
{
type:"POLYNYM",
role:"BIRTH",
given:"Malcolm",
surname:"Little"
},
{
type:"POLYNYM",
role:"LEGAL",
given:"Malik",
surname:"El-Shabazz"
}
]
hoặc là
names:[
{
type:"POLYNYM",
role:"LEGAL",
given:"Prince",
middle:"Rogers",
surname:"Nelson"
},
{
type:"MONONYM",
role:"SOBRIQUET",
mononym:"Prince"
},
{
type:"PICTONYM",
role:"LEGAL",
url:"http://upload.wikimedia.org/wikipedia/en/thumb/a/af/Prince_logo.svg/130px-Prince_logo.svg.png"
}
]
hoặc là
names:[
{
type:"POLYNYM",
role:"LEGAL",
given:"Juan Pablo",
surname:"Fernández de Calderón",
secondarySurname:"García-Iglesias" /* hispanic people often have two surnames. it can be impolite to use the wrong one. Portuguese and Spaniards differ as to which surname is important */
}
]
Đặt tên, tên đệm, họ có thể là nhiều từ như "Billy Bob" Thornton
, hoặc Ralph "Vaughn Williams"
.
Tôi sẽ nói với lỗi ở phía cao. Vì có thể bạn sẽ sử dụng varchar, nên bất kỳ không gian bổ sung nào bạn cho phép sẽ không thực sự sử dụng hết bất kỳ dung lượng bổ sung nào trừ khi có ai đó cần nó. Tôi sẽ nói về tên (đầu tiên hoặc cuối cùng), đi ít nhất 50 ký tự và cho địa chỉ email, làm cho nó ít nhất 128. Có một số địa chỉ email thực sự dài ngoài đó.
Một điều khác mà tôi muốn làm là truy cập vào Lipsum.com và yêu cầu nó tạo ra một số văn bản. Bằng cách đó bạn có thể có được một ý tưởng tốt về việc 100 byte trông như thế nào.
[N]Varchar
kích thước làm tuy nhiên, ảnh hưởng đến chỉ mục của bạn.
Tôi gần như luôn luôn sử dụng sức mạnh bằng 2 trừ khi có lý do chính đáng để không, chẳng hạn như giao diện đối diện với khách hàng trong đó một số khác có ý nghĩa đặc biệt với khách hàng.
Nếu bạn tuân theo sức mạnh của 2, nó sẽ giữ cho bạn trong một tập hợp kích thước phổ biến giới hạn, bản thân nó là một điều tốt, và nó giúp bạn dễ dàng đoán được kích thước của các vật thể không xác định mà bạn có thể gặp phải. Tôi thấy một số lượng khá lớn những người khác làm điều này, và có một cái gì đó thẩm mỹ về nó. Nó thường mang lại cho tôi cảm giác tốt khi tôi nhìn thấy điều này, nó có nghĩa là nhà thiết kế đã suy nghĩ như một kỹ sư hoặc nhà toán học. Mặc dù tôi có thể lo ngại nếu chỉ sử dụng số nguyên tố. :)
Tôi muốn tìm ra điều tương tự và Tiêu chuẩn dữ liệu của Chính phủ Anh được đề cập trong câu trả lời được chấp nhận nghe có vẻ lý tưởng. Tuy nhiên, không ai trong số này dường như còn tồn tại nữa - sau khi tìm kiếm mở rộng, tôi đã tìm thấy nó trong một kho lưu trữ ở đây: http://webarchive.nationalarchives.gov.uk/+/http://www.cabinetoffice.gov.uk/govtalk/ lược đồ / e-gif / datastiterias.aspx . Cần tải xuống zip, giải nén nó và sau đó mở default.htmlm trong thư mục html.
Đây có thể hữu ích cho một ai đó;
youtube max channel length = 20
facebook max name length = 50
twitter max handle length = 15
email max length = 255
http://www.interoadvisory.com/2015/08/6-areas-inside-of-linkedin-with-character-limits/
+------------+---------------+---------------------------------+
| Field | Length (Char) | Description |
+------------+---------------+---------------------------------+
|firstname | 35 | |
|lastname | 35 | |
|email | 255 | |
|url | 60+ | According to server and browser |
|city | 45 | |
|address | 90 | |
+------------+---------------+---------------------------------+
Chỉnh sửa : Đã thêm một số khoảng cách
Chỉ cần nhìn qua kho lưu trữ email của tôi, có một số tên "đầu tiên" khá dài (tất nhiên ý nghĩa đầu tiên là biến đổi theo văn hóa). Một ví dụ là Krishnamurthy - dài 13 chữ cái. Một dự đoán tốt có thể là 20 đến 25 chữ cái dựa trên điều này. Email sẽ dài hơn nhiều vì bạn có thể có Firstname.lastname@somedomain.com. Ngoài ra, gmail và một số chương trình thư khác cho phép bạn sử dụng Firstname.lastname+sometag@somedomain.com trong đó "đôi khi" là bất cứ điều gì bạn muốn đặt ở đó để bạn có thể sử dụng nó để sắp xếp email đến. Tôi thường xuyên chạy vào các biểu mẫu web không cho phép tôi nhập địa chỉ email đầy đủ của mình mà không xem xét bất kỳ thẻ nào. Vì vậy, nếu bạn cần một trường email cố định, có thể là khoảng 25,25+15@20.3 trong các ký tự cho tổng số 90 ký tự (nếu tôi thực hiện đúng phép toán của mình!).
Tôi thường đi với:
Firstname : 30 chars
LastName : 30 chars
Email : 50 chars
Địa chỉ : 200 ký tự
Nếu tôi lo lắng về các trường dài cho tên, đôi khi tôi cũng có thể đi với 50 cho các trường tên, vì không gian lưu trữ hiếm khi là một vấn đề ngày nay.
Nếu bạn cần xem xét nội địa hóa (đối với những người trong chúng tôi bên ngoài Hoa Kỳ!) Và điều đó là có thể trong môi trường của bạn, tôi đề nghị:
Xác định loại dữ liệu cho từng thành phần của tên - LƯU Ý: một số nền văn hóa có nhiều hơn hai tên! Sau đó, có một loại cho tên đầy đủ,
Sau đó nội địa hóa trở nên đơn giản (theo như tên có liên quan).
Áp dụng tương tự cho các địa chỉ, BTW - các định dạng khác nhau!