다음과 같은 공통 필드에서 길이 및 데이터 유형에 대한 가장 일반적인 모범 사례는 무엇입니까?
- 이름
- 성
- 주소
- 이메일
- 섹스
- 상태
- 시티
- 국가
- 전화 번호
기타....
이 질문은 WAYYY입니다. 제거하고 삭제해야합니다.
—
Evan Carroll
다음과 같은 공통 필드에서 길이 및 데이터 유형에 대한 가장 일반적인 모범 사례는 무엇입니까?
기타....
답변:
이 분야의 대부분에서 악마는 세부 사항에 있기 때문에 나는 보편적 인 모범 사례를 매우 의심하는 경향이 있습니다. 정보가 비교적 일반적이기 때문에 응용 프로그램이 다른 응용 프로그램과 동일한 방식으로 데이터를 사용한다는 의미는 아닙니다. 이는 데이터 모델이 약간 다를 수 있음을 의미합니다.
STATE테이블을 생성하고 STATE와 ADDRESS테이블 간에 외래 키 관계를 만드는 것이 좋습니다. 그러나 유효한 값을 식별 할 수 있다는 것은 유효한 주소 집합을 적어도 특정 국가 집합으로 제한하고 있음을 의미합니다. 많은 사이트에는 문제가 없지만 새로운 국가를 지원하기 위해 약간의 노력을 기울여야합니다.CITY유효한 도시 CITY와 ADDRESS테이블 사이의 외래 키 관계가있는 테이블. 반면에, 당신이 제품을 배달하려고하는데 테이블에 같은 도시의 다양한 버전이 있는지에 대해 신경 쓰지 않는다면, 사용자가 자유 형식의 텍스트를 입력하는 것으로 충분합니다. 물론 외래 키를 저장하는 경우 유효한 값을 모두 확보하기 위해 상당한 양의 작업이 필요합니다. 그러나 요점은 회사가 이미 그 작업을 수행 한 제품 (예 : 판매 세 데이터베이스)이 있습니다.샘플 데이터와 예상 대상을 기반으로 추측 할 수도 있습니다 . 위치에 따라 다릅니다.
몇 가지 참고 사항 :
구애:
이름 :
전화 번호 : 국제 코드, 길이, 휴대 전화 대 집, 휴대 전화 만 숫자로 허용
위의 위대한 답변 외에도 유니 코드 문자를 허용하는 것을 잊지 마십시오. 미국에 있다고해서 열에 외국 문자를 허용하고 싶지 않다는 의미는 아닙니다.
즉, 나는 보통 이름으로 50자를 권장합니다. 320은 이메일 주소보다 충분해야합니다 (ANSI 표준을 확인하십시오). 255 자로주의하여 주소 오류가 발생했습니다. 큰 주소가 필요하지는 않지만 C / O 라인과 같은 것들을 포함시킬 수 있습니다. 도시는 꽤 커야하고, 도시 이름이 꽤 길다. 국가의 경우 국가와 동일한 하위 테이블을 사용하십시오. 우편 번호의 경우 미국 우편 번호보다 긴 국제 우편 번호를 잊지 마십시오. 당신이 국제을 지원하지 않기 때문에 당신은 여전히있을 수 있습니다. 군대를 포함하여 다른 카운티에 사는 많은 미국 시민이 있습니다.
많은 국가에 주가 없기 때문에 주가 선택 사항이어야한다는 것을 잊지 마십시오.
내 부랑자가 울타리에 앉으면 아프다. 그래서 나는 약간의 대답을 버리고 망각에 빠지지 않기를 희망한다. 건설적인 비판을 제공하십시오.
최소 : 6 (a@g.cn). 또는 3 로컬 도메인의 이메일 주소를 추적하려는 경우
최대 : (320) 254 (RFC)
이메일의 유효성을 검사하는 코드의 양은 실제로 미쳤으므로 "@"가 있으면 유효한 것으로 가정하겠습니다.
전자 메일 주소를 "통신 방법"으로 추상화하여 사용자와 통신 할 수있는 모든 방법을 쉽게 나열 할 수 있습니다.
성별은 시간이 지남에 따라 변경 될 수 있으므로 중요한 경우이를 추적 할 수 있습니다. http://en.wikipedia.org/wiki/ISO/IEC_5218 팔로우
NOT_KNOWN(0),
MALE(1),
FEMALE(2),
NOT_APPLICABLE(9);
싸구려 나가 북미 주소를 고수하겠습니다.
대부분 세금으로 인해 국가, 부서, 도시 및 카운티를 추상화하는 것이 편리합니다. 세금은 여러 수준으로 적용될 수 있으므로 추상 지리적 영역에서 세율을 지정할 수 있으면 황금색입니다.
지역 :
id: int
type: {country, division, county, city, indian reservation}
name: varchar(45) [1]
abbreviation: nullable varchar(4)
parent_id: nullable int
주소 :
id: int
postal_area_id: int, references GeographicArea
county_or_city_id: int, references GeographicArea
street_address: varchar(255)
suite: nullable varchar(255)
필요한 경우 line2와 line3을 추가하십시오.
http://en.wikipedia.org/wiki/Address_(geography)를 참조하십시오 .
이제 주소는 주소입니다. 여러 사람이 한 주소에 살 수 있고 한 사람이 동시에 여러 주소를 가질 수 있으므로 시간이 지남에 따라 여러 테이블이 필요합니다.
파티 주소
party_id: int references Party
address_id: int references Address
purpose: {home, work, ...}
시간이 지남에 따라 추적하는 경우 from_date및 nullable을 추가하십시오 to_date.
당사자는 여러 전화 번호를 가질 수 있으며 전화 번호는 여러 사람이 사용할 수 있습니다. 전화 번호는 팩스, 전화 통화, 모뎀 등에 사용될 수 있으며 내선 번호를 가질 수 있습니다. 이것들은 모두 시간이 지남에 따라 변할 수 있습니다.
전화 번호
id: int
value: varchar(15) - the max allowed by the ITU
최소값은 3 ( "911"의 경우)이거나 7 일 수 있습니다 ( "310-4NET", 지역 번호를 입력 할 수없는 특수한 종류의 지역 번호 임)
필요한 경우 이것을 국가 코드 등으로 나눌 수 있습니다.
http://en.wikipedia.org/wiki/E.164 표준을 사용해야합니다
PartyPhoneNumber
party_id: int references Party
phone_number_id references PhoneNumber
extension: nullable varchar(11) - ITU max
purpose: {home, work, fax, modem, ...}
이름이 힘들다. 이유는 다음과 같습니다.
어떤 사람들은 한 단어로만 합법적 인 이름을 가지고 있습니다. http://en.wikipedia.org/wiki/List_of_legally_mononymous_people
어떤 사람들은 http://en.wikipedia.org/wiki/Wolfe%2B585,_Senior 라는 단어가 많은 이름을 가지고 있습니다
일부 사람들은 동시에 여러 이름을 가지고 있습니다 (예를 들어, 내 대학에는 많은 아시아 학생들이 있지만 "선호하는"보다 서구화 된 이름을 사용하는 것을 좋아합니다)
때로는 성명이나 결혼 한 성명과 같이 시간이 지남에 따라 사람들의 이름을 추적해야합니다.
다양한 이유로 개인과 조직을 추상화하려고합니다.
테이블 파티 생성 (id bigserial primary key);
테이블 만들기 party_name (id bigserial 기본 키, party_id bigint가 null을 참조하지 않음 party (id), smallint가 null을 참조하지 않음 형식 party_name_type (id)-생략 됨, 예 : "maiden", "legal");
테이블 생성 name_component (id bigserial 기본 키, party_name_id bigint가 null이 아닌 참조 참조 party_name (id), smallint가 null이 아닌 참조 참조 name_component_type (id),- "exvened"이름 텍스트가 null이 아님);
이전 답변보다 약간 다른 관점에서, 그리고 이후 는 LDAP에 대해 얘기하고 확인을 보인다 , RFC 4519 - "의 LDAP (Lightweight Directory Access Protocol) : 스키마 사용자 응용 프로그램 용은" 관심이있을 수 있습니다.
응용 프로그램을 이러한 디렉토리에 매핑해야하는 경우 유용 할 수 있습니다. 그렇지 않으면 요구 사항에 맞지 않을 수 있습니다.
이러한 정의는 단순한 데이터가 아니라 필드에서 사용할 수있는 일부 연산자에 대한 것입니다. postalAddress예를 들어입니다 caseIgnoreListSubstringsMatch. 이 스키마를 엄격하게 준수해야한다는 제안은 아니지만 특히 원칙을 살펴보면 특히 응용 프로그램의 이름과 주소를 비교하여 데이터베이스 디자인과 관련이있는 방법이 흥미로울 수 있습니다.
이름에 대해서는 큰 따옴표를 사용하여 아일랜드어 또는 이탈리아어 이름 (예 : O'Hara 또는 D' Amato)에서 아포스트로피를 피할 필요가 없습니다.
또한 사용할 정규 표현식 세트를 얻는 것이 좋습니다. 따라서 이름 필드의 일부 (예 : 첫 이니셜, 닉네임, Jr / Sr 등)를 출력 할 수 있습니다.