Các thực tiễn tốt nhất phổ biến nhất về độ dài và loại dữ liệu trên các trường phổ biến như:
Vân vân....
Câu trả lời:
Tôi có xu hướng rất nghi ngờ về bất kỳ tập hợp thực hành tốt nhất phổ quát nào bởi vì, đối với hầu hết các lĩnh vực này, ma quỷ nằm trong các chi tiết. Chỉ vì thông tin tương đối phổ biến không có nghĩa là ứng dụng của bạn sử dụng dữ liệu theo cách chính xác giống như các ứng dụng khác sử dụng. Điều đó có nghĩa là mô hình dữ liệu của bạn có thể cần phải hơi khác nhau.
STATEbảng và tạo mối quan hệ khóa ngoài giữa bảng STATEvà ADDRESSbảng. Nhưng khả năng xác định các giá trị hợp lệ ngụ ý rằng bạn giới hạn nhóm địa chỉ hợp lệ ít nhất là ở một quốc gia cụ thể. Điều đó tốt cho nhiều trang web nhưng sau đó bạn phải làm một chút công việc để hỗ trợ một quốc gia mới.CITYbảng với các thành phố hợp lệ và mối quan hệ khóa ngoài giữa các bảng CITYvà ADDRESS. Mặt khác, nếu bạn chỉ đang cố gắng giao sản phẩm và bạn không quan tâm nhiều nếu bạn có nhiều phiên bản khác nhau của cùng một thành phố trong bảng của mình, hãy để người dùng nhập văn bản dưới dạng tự do là đủ. Tất nhiên, nếu bạn đang lưu trữ khóa ngoại, bạn sẽ có một khối lượng công việc hợp lý để đảm bảo rằng bạn có tất cả các giá trị hợp lệ. Nhưng có những sản phẩm mà toàn bộ vấn đề là công ty đã thực hiện công việc đó (tức là cơ sở dữ liệu thuế bán hàng).Bạn cũng có thể đoán dựa trên dữ liệu mẫu và đối tượng dự kiến. Nó phụ thuộc vào vị trí của bạn.
Một số lưu ý:
Địa chỉ:
Tên:
Số điện thoại: Mã quốc tế, chiều dài, di động so với nhà, cho phép điện thoại di động chỉ là số
Ngoài các câu trả lời tuyệt vời ở trên, đừng quên chấp nhận các ký tự unicode. Chỉ vì bạn ở Mỹ không có nghĩa là bạn không muốn chấp nhận các ký tự nước ngoài vào các cột của mình.
Điều đó nói rằng, tôi thường đề nghị 50 ký tự cho tên. 320 là quá đủ cho một địa chỉ email (bạn có thể kiểm tra tiêu chuẩn ANSI để chắc chắn). Đối với lỗi địa chỉ về phía thận trọng với 255 ký tự. Mặc dù có thể bạn sẽ không bao giờ cần một địa chỉ lớn như vậy, nhưng bạn có thể bao gồm các dòng C / O và những thứ tương tự. Thành phố nên khá lớn, có một số tên thành phố khá dài ngoài kia. Đối với nhà nước đi với một bảng con, cùng với đất nước. Đối với mã Zip, đừng quên mã bưu chính quốc tế dài hơn mã zip của Hoa Kỳ. Chỉ vì bạn không hỗ trợ quốc tế mà bạn vẫn có thể. Có rất nhiều công dân Hoa Kỳ sống ở các quận khác nhau bao gồm cả quân đội.
Đừng quên rằng tiểu bang nên là tùy chọn vì nhiều quốc gia không có tiểu bang.
Tên ăn mày của tôi đang bị đau khi ngồi trên hàng rào, vì vậy tôi sẽ chỉ đưa ra một số câu trả lời và hy vọng sẽ không bị bỏ phiếu - bị bỏ rơi vào quên lãng. Xin đưa ra lời phê bình mang tính xây dựng.
tối thiểu: 6 (a@g.cn). Hoặc 3 nếu bạn muốn theo dõi địa chỉ email tên miền cục bộ
tối đa: 320 254 (RFC)
Số lượng mã để xác thực một email thực sự điên rồ, vì vậy hãy giả sử nó hợp lệ nếu nó có "@"
Bạn có thể muốn trừu tượng một địa chỉ email là một "phương thức giao tiếp", để bạn có thể dễ dàng liệt kê tất cả các phương thức để giao tiếp với người dùng.
Giới tính có thể thay đổi theo thời gian, vì vậy bạn có thể theo dõi nếu điều đó quan trọng với bạn. Theo dõi http://en.wikipedia.org/wiki/ISO/IEC_5218
NOT_KNOWN(0),
MALE(1),
FEMALE(2),
NOT_APPLICABLE(9);Tôi sẽ đi theo con đường rẻ tiền và bám lấy địa chỉ Bắc Mỹ.
Nó thuận tiện cho các nước trừu tượng, các bộ phận, thành phố và các quận chủ yếu là do thuế. Thuế có thể áp dụng ở nhiều cấp độ, vì vậy nếu bạn có thể chỉ ra mức thuế ở một khu vực địa lý trừu tượng, bạn là vàng.
Địa lý :
id: int
type: {country, division, county, city, indian reservation}
name: varchar(45) [1]
abbreviation: nullable varchar(4)
parent_id: nullable int Địa chỉ :
id: int
postal_area_id: int, references GeographicArea
county_or_city_id: int, references GeographicArea
street_address: varchar(255)
suite: nullable varchar(255) Thêm dòng2 và dòng3 nếu bạn cần.
Xem http://en.wikipedia.org/wiki/Address_(geography)
Bây giờ, một địa chỉ là một địa chỉ. Nhiều người có thể sống tại một địa chỉ và một người có thể có nhiều địa chỉ cùng một lúc và theo thời gian, vì vậy bạn cần một bảng nhiều cho việc đó.
Đảng viên
party_id: int references Party
address_id: int references Address
purpose: {home, work, ...} Thêm một from_datevà nullable to_datenếu theo dõi theo thời gian.
Một bên có thể có nhiều số điện thoại và một số điện thoại có thể được sử dụng bởi nhiều người. Một số điện thoại có thể được sử dụng cho fax, cuộc gọi điện thoại, modem, vv và có thể có phần mở rộng. Những điều này cũng có thể thay đổi theo thời gian.
Số điện thoại
id: int
value: varchar(15) - the max allowed by the ITU Số phút tối thiểu có thể là 3 (đối với "911") hoặc có thể là 7 ("310-4NET", đây là một loại số địa phương đặc biệt không cho phép bạn quay số mã vùng)
Bạn có thể chia mã này thành mã quốc gia, vv nếu cần thiết.
Bạn nên sử dụng tiêu chuẩn http://en.wikipedia.org/wiki/E.164
PartyPhoneSố
party_id: int references Party
phone_number_id references PhoneNumber
extension: nullable varchar(11) - ITU max
purpose: {home, work, fax, modem, ...} Tên là khó khăn. Đây là lý do tại sao:
Một số người có tên hợp pháp chỉ có một từ trong đó http://en.wikipedia.org/wiki/List_of_legally_mononymous_people
Một số người có tên với nhiều từ http://en.wikipedia.org/wiki/Wolfe%2B585,_Senior
Một số người có nhiều tên cùng một lúc (ví dụ, tại trường đại học của tôi có nhiều sinh viên châu Á, nhưng họ thích sử dụng tên "ưa thích" hơn phương Tây)
Đôi khi, bạn cần theo dõi tên của mọi người theo thời gian, chẳng hạn như tên thời con gái và tên đã kết hôn.
Bạn muốn trừu tượng các cá nhân và tổ chức vì nhiều lý do tốt
tạo bảng tiệc (khóa chính id bigserial);
tạo bảng party_name (khóa chính id bigserial, party_id bigint không null tham chiếu bên (id), nhập smallint không null tham chiếu party_name_type (id) --elided, ex "maiden", "Legal");
tạo bảng name_component (khóa chính id bigserial, party_name_id bigint không null tham chiếu party_name (id), nhập smallint không null tham chiếu name_component_type (id), --elided ex "cho" văn bản tên không null);
Từ một góc nhìn hơi khác so với các câu trả lời trước đó và vì có vẻ ổn khi nói về LDAP , RFC 4519 - "Giao thức truy cập thư mục nhẹ (LDAP): Lược đồ cho các ứng dụng người dùng" có thể được quan tâm.
Nó có thể hữu ích nếu ứng dụng của bạn cần được ánh xạ tới một thư mục như vậy. Nếu không, nó có thể không phù hợp với yêu cầu của bạn.
Các định nghĩa này không chỉ là về dữ liệu, chúng còn là về một số toán tử có thể được sử dụng trên các trường. postalAddress, ví dụ là một caseIgnoreListSubstringsMatch. Tôi không khuyên bạn nên tuân thủ nghiêm ngặt lược đồ này, nhưng nhìn vào các nguyên tắc có thể thú vị, đặc biệt là cách bạn có thể phải so sánh tên và địa chỉ trong ứng dụng của mình có thể phù hợp với thiết kế cơ sở dữ liệu của bạn.
Về tên, hãy cân nhắc sử dụng dấu ngoặc kép để bạn không phải thoát khỏi dấu nháy đơn trong tên Ailen hoặc tiếng Ý (ví dụ: O'Hara hoặc D'Amato).
Tôi cũng khuyên bạn nên sử dụng một bộ Biểu thức chính quy tốt để sử dụng, do đó bạn có thể xuất các phần của trường tên của mình (ví dụ: chữ cái đầu tiên, biệt danh, Jr / Sr, v.v.).