나는 이름, 성, 이메일 및 전화 번호를 저장하는 매우 작은 MySQL 데이터베이스를 설정하고 있으며 각 필드에 대한 ‘완벽한’데이터 유형을 찾기 위해 고군분투하고 있습니다. 완벽한 답은 없다는 것을 알고 있지만, 이와 같이 일반적으로 사용되는 분야에는 일종의 공통 관습이 있어야합니다. 예를 들어, 형식이 지정되지 않은 미국 전화 번호는 서명되지 않은 정수로 저장하기에는 너무 크다고 판단했습니다. 최소한 bigint 여야합니다.
다른 사람들이 유용하다고 생각하기 때문에 위에서 언급 한 필드로만 질문을 제한하고 싶지 않습니다.
일반적인 데이터베이스 필드에 적합한 데이터 유형은 무엇입니까? 전화 번호, 이메일, 주소와 같은 필드?
답변
누군가는 이것보다 훨씬 더 나은 답변을 게시 할 것입니다.하지만 개인적으로 어떤 종류의 정수 필드에도 전화 번호를 저장하지 않을 것이라는 점을 강조하고 싶었습니다. 주로 다음과 같은 이유 때문입니다.
- 어떤 종류의 산술도 할 필요가 없습니다.
- 조만간 누군가가 자신의 지역 번호를 괄호로 묶으려고 할 것입니다.
일반적으로 나는 거의 독점적으로 사용하는 것 같습니다.
- ID이거나 다른 ID를 참조하는 모든 항목에 대한 INT (11)
- 타임 스탬프의 경우 DATETIME
- 255 자 (페이지 제목, 이름 등) 미만이 보장되는 모든 항목에 대한 VARCHAR (255)
- 거의 모든 것을위한 텍스트.
물론 예외가 있지만 대부분의 경우에 적용됩니다.
답변
다음은 내가 사용하는 몇 가지 일반적인 데이터 유형입니다 (하지만 프로는 아닙니다).
| 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 답변
내 경험상 이름 / 성 필드는 48 자 이상이어야합니다. 말레이시아 또는 인도와 같은 일부 국가의 이름은 전체 형식이 매우 긴 이름이 있습니다.
전화 번호와 우편 번호는 항상 숫자가 아닌 텍스트로 취급 해야 합니다. 주어진 일반적인 이유는 0으로 시작하는 우편 번호가 있고 일부 국가에서는 전화 번호도 0으로 시작할 수 있기 때문입니다. 그러나 실제 이유는 이들이 숫자 가 아니라 구성되는 식별자 이기 때문입니다. 숫자의 숫자 (우편 번호에 문자가있는 캐나다와 같은 국가는 무시 됨). 따라서 텍스트 필드에 저장하십시오.
MySQL에서는 이러한 유형의 정보에 VARCHAR 필드를 사용할 수 있습니다. 게으른 것처럼 들리지만 올바른 최소 크기에 대해 너무 걱정할 필요가 없음을 의미합니다.
답변
가변 길이 (이름, 이메일 주소)의 데이터를 처리 할 것이기 때문에 VARCHAR을 사용하고 싶을 것입니다. VARCHAR 필드가 차지하는 공간의 양은 [field length]+ 1 바이트, 최대 길이 255이므로 완벽한 크기를 찾는 것에 대해 너무 걱정하지 않습니다. 가장 긴 길이라고 생각한 것을 살펴본 다음 두 배로 늘리고 VARCHAR 제한으로 설정하십시오. 즉 … :
일반적으로 이메일 필드를 VARCHAR (100)로 설정합니다. 아직 문제가 발생하지 않았습니다. VARCHAR (50)로 설정 한 이름.
다른 사람들이 말했듯이 전화 번호와 우편 번호는 실제로 숫자 값이 아니며 숫자 0-9 (때로는 더 많이!)를 포함하는 문자열이므로 문자열로 처리해야합니다. VARCHAR (20)이면 충분합니다.
전화 번호를 정수로 저장하는 경우 많은 시스템에서 0으로 시작하는 숫자가 8 진수 (밑수 8)라고 가정합니다! 따라서 완벽하게 유효한 전화 번호 “0731602412”는 십진수 “124192010”으로 데이터베이스에 저장됩니다 !!
답변
나는 똑같은 일을하고 있으며 여기에 내가 한 일이 있습니다.
이름, 주소, 이메일 및 번호에 대해 별도의 테이블을 사용했으며 각각 기본 클러스터 키인 Name 테이블을 제외한 모든 항목에 대한 외래 키인 NameID 열이 있습니다. 비즈니스 항목과 개인 항목을 허용하기 위해 LastName과 FirstName 대신 MainName과 FirstName을 사용했지만 그럴 필요가 없을 수도 있습니다.
NameID 열은 32000 개 이상의 항목을 만들지 않을 것이기 때문에 모든 테이블에서 smallint가됩니다. 그 밖의 거의 모든 것은 저장하려는 항목 (생일, 댓글, 이메일, 정말 긴 이름)에 따라 20에서 200까지 varchar (n)입니다. 그것은 당신이 어떤 종류의 물건을 저장하고 있는지에 달려 있습니다.
Numbers 테이블은 제가 그것에서 벗어나는 곳입니다. NameID, Phone #, CountryCode, Extension 및 PhoneType 레이블이 지정된 5 개의 열을 갖도록 설정했습니다. 이미 NameID에 대해 논의했습니다. Phone #은 varchar (12)이며 다음과 같은 확인 제약 조건이 있습니다. CHECK (Phone # like ‘[0-9] [0-9] [0-9]-[0-9] [0-9] [0 -9]-[0-9] [0-9] [0-9] [0-9] ‘). 이렇게하면 내가 원하는 것만 데이터베이스에 저장되고 데이터가 매우 일관되게 유지됩니다. 내가 nullable smallints라고 부르는 확장 및 국가 코드이지만 원하는 경우 varchar가 될 수 있습니다. PhoneType은 varchar (20)이며 null을 허용하지 않습니다.
도움이 되었기를 바랍니다!
답변
