가능한 중복 :
Are there disadvantages to using a generic varchar(255) for all text-based fields?MySQL : VARCHAR (255) 대신 VARCHAR (20)을 사용해야하는 이유는 무엇입니까?
는 MYSQL에서 당신이 VARCHAR 필드 유형에 대한 길이를 선택할 수 있습니다. 가능한 값은 1-255입니다.
그러나 VARCHAR (20) 대신 VARCHAR (255)를 사용하면 어떤 이점이 있습니까? 내가 아는 한, 항목의 크기는 삽입 된 문자열의 실제 길이에만 의존합니다. 당신은 VARCHAR (255) 필드에 단어 "예"가있는 경우
크기 (바이트) = 길이 +
1 그래서, 그것은 8 바이트있을 것입니다. VARCHAR (20) 필드에 있으면 8 바이트가됩니다. 그 차이점은 무엇입니까?
도와 주시면 감사하겠습니다. 미리 감사드립니다!
체크 아웃 : 당신이 길이 접두사에 대한 또 다른 바이트가 필요합니다 당신의 VARCHAR 255의 크기를 통해 이동하지 않는 한 짧은에서 Reference for Varchar
큰 차이가 없습니다.
길이가 다른 것보다 열에 저장된 데이터에 대한 제약 사항이 더 많음을 나타냅니다. 이것은 본질적으로 열의 최대 저장 크기를 제한합니다. IMHO, 길이는 데이터와 관련하여 이해해야합니다. 사회 보장 번호 (SSN)를 저장하는 경우 실제 보관하는 것이 모두 SSN 인 경우 저장 비용이 들지 않아도 길이를 128로 설정하는 것은 의미가 없습니다.
글쎄, 더 큰 항목을 허용하거나 항목 크기를 제한하려는 경우.
예를 들어, first_name은 VARCHAR 20으로, street_address는 VARCHAR 50으로 가질 수 있습니다. 20은 공간이 충분하지 않을 수 있기 때문입니다. 동시에, 그 값이 얻을 수있는 크기를 제어하고자 할 수 있습니다.
즉, 이론적으로 테이블 (잠재적으로 색인/색인 항목)이 너무 커지지 않도록 특정 값의 최대 한도를 설정했습니다. 이 빨리 SQL 액세스 수 있지만
당신은 단지뿐만 아니라 고정 폭 CHAR을 사용할 수 있지만 VARCHAR 달리 작아 질 수는 CHAR는 (값을 채 웁니다. 데이터베이스 관점 성능에서
을 현명 내가 할
그러나 사용하려는 길이에 대한 많은 결정은 사용자가 필요로하는 데이터 만 받아들이고 시스템을 문서화하려고 시도 할 때 발생한다고 생각합니다.
"CHAR을 사용하면 전체 레코드가 고정 크기 인 경우에만 액세스 속도가 향상됩니다. 즉, 가변 크기의 객체를 사용하는 경우 변수 크기를 모두 조정할 수 있습니다. VARCHAR도 포함 된 테이블에서. " [link] (http://dev.mysql.com/doc/refman/5.0/en/char.html) –
최대 값보다 작은 값을 선택하는 데는 여러 가지 유효한 이유가 있습니다. 성능과 관련이 없습니다. 크기를 설정하면 저장하는 데이터의 유형을 알 수 있으며 마지막 유효성 검사 형식으로 사용할 수도 있습니다.
예를 들어, 영국 우편 번호를 저장하는 경우 8 자만 필요합니다. 이 제한을 설정하면 저장하는 데이터의 유형을 명확히 할 수 있습니다. 255자를 선택하면 문제가 혼동 될뿐입니다.
+1은 명확성과 명료성을 강조합니다. 예를 들어 하나의 점으로 구분 된 쿼드 IP 주소를 저장하는 buf [1024], 새로운 DynamicBuf (1024) 또는 VARCHAR (255)의 사용에 대해서는 질문 할 것입니다. 코더가 자신이 한 일을 알고 있었습니까? – pilcrow
+1 그리고 UK postcode 용 VARCHAR (8)이 성능을 위해 CHAR (8)을 사용한다면 : –
8 문자 우편 번호를 저장하려면 대신 CHAR (8)을 사용해야합니다. 테이블에서 VARCHAR 열의 존재를 피하는 것이 좋습니다. 행의 길이를 가변시키고 테이블에서 더 느리게 검색해야하기 때문입니다. 그러나 고정 길이의 모든 열을 가질 수 없다면 중요하지 않습니다. –
거기에 의미있는 차이가 있습니다 (그리고 그 유일한 차이가 있다고 생각합니다) : varchar (20)에 공백이 아닌 문자 30 개를 채우면 오류가 발생하지만 varchar (255) . 따라서 이것은 주로 추가 제약 조건입니다.
mySQL에 대해서는 잘 모르겠지만 SQL Server에서는 사용 된 총 바이트 수가 실제 레코드에 저장할 수있는 총 바이트 수보다 많도록 필드를 정의 할 수 있습니다. 이것은 나쁜 것입니다. 조만간 한계에 도달 한 행을 가져오고 데이터를 삽입 할 수 없습니다.
행 크기 제한을 고려하여 데이터베이스 구조를 설계하는 것이 훨씬 좋습니다.
또한 예, 사람들은 최대 값이 10 인 필드에 200자를 입력하지 않아도됩니다. 그렇다면 거의 항상 불량 데이터입니다.
당신은 응용 프로그램 수준에서 제한 할 수 있습니다. 그러나 데이터는 하나의 애플리케이션에서 데이터베이스로 전달되지 않습니다. 경우에 따라 여러 응용 프로그램에서 사용하는 경우가 있습니다. 때로는 데이터를 가져오고 때로는 쿼리 창에서 수동으로 고정합니다. 예를 들어 가격에 10 %를 추가하도록 모든 레코드를 업데이트합니다. 이러한 다른 데이터 소스 중 하나라도 응용 프로그램에 적용한 규칙을 모르는 경우 데이터베이스에 불량한 쓸모없는 데이터가 있습니다. 데이터 무결성은 데이터베이스 수준에서 시행되어야합니다 (데이터를 입력하기 전에 확인하지 않아도 됨) 또는 무결성이 없습니다. 게다가 데이터베이스를 설계하기에는 너무 게으른 사람들은 실제로 응용 프로그램에 한계를두기에는 너무 게으르며 데이터 무결성 검사는 전혀 없다는 것이 내 경험이었습니다.
그들은 데이터 무결성이없는 데이터베이스를 의미합니다. 쓸모가 없습니다.
하지만 왜 길이를 20으로 설정해야합니까? 아무런 차이가 없다면 모든 필드에 대해 255로 설정할 수 있습니다. – caw
제 편집 참조 - 좀 더 정교합니다. – OneNerd
감사합니다. 따라서 스토리지 및 성능을 컨버전스하는 데있어 어떤 차이점도 발생하지 않습니다. 하지만 유용 할 수 있습니다. 긴 자국을 막기 위해 끈을 자르고 싶다면. 그러나 PHP 나 다른 언어에서 비슷한 함수로 substr()을 사용했다면 전에도 이것을 얻을 수 있습니다!? – caw