URL에 대한 최적의 데이터베이스 필드 유형
MySQL 테이블에 URL을 저장해야 합니다.길이가 불분명한 URL을 보유하는 필드를 정의하기 위한 베스트 프랙티스는 무엇입니까?
- http://dev.mysql.com/doc/refman/5.0/en/char.html
VARCHAR 열의 값은 가변 길이의 문자열입니다.길이는 MySQL 5.0.3 이전 버전에서는 0 ~255, 5.0.3 이후 버전에서는 0 ~65,535 의 값으로 지정할 수 있습니다.MySQL 5.0.3 이후 VARCHAR의 유효 최대 길이는 최대 행 크기(65,535 바이트, 모든 열에서 공유) 및 사용되는 문자 세트에 따라 달라집니다.
- 그래서...
< MySQL 5.0.3 TEXT 사용
또는
>= MySQL 5.0.3 VARCHAR(2083) 사용
VARCHAR(512)
(또는 유사한)이면 충분합니다.단, 문제의 URL의 최대 길이를 잘 모르기 때문에 직접 로 이동해 보겠습니다.TEXT
이로 인해 발생하는 위험은 물론 다음과 같은 이유로 인한 효율성 손실입니다.CLOB
다음과 같은 단순한 문자열 데이터형보다 훨씬 느립니다.VARCHAR
.
varchar(max)
SQL Server 2005의 경우
varchar(65535)
MySQL 5.0.3 이후용
이로 인해 필요에 따라 스토리지가 할당되며 성능에 영향을 미치지 않습니다.
이는 실제로 사용 사례에 따라 다르지만(아래 참조), 저장 시TEXT
퍼포먼스에 문제가 있어, 큰 문제가 있다.VARCHAR
대부분의 경우엔 과잉 살상으로 들리죠
내 접근법: 관대하지만 지나치게 크지 않은 사용VARCHAR
길이(예:VARCHAR(500)
또는 더 큰 URL을 필요로 하는 사용자에게 다음과 같은 URL 단축자를 사용하도록 권장합니다.safe.mn
.
Twitter의 어프로치: UX를 사용하기 위해서는 지나치게 긴 URL에 자동 URL 단축기를 제공하고 링크의 "display version"을 끝에 줄임표가 있는 URL 조각으로 저장합니다(예:http://stackoverflow.com/q/219569/1235702
로 표시됩니다.stackoverflow.com/q/21956...
단축된 URL에 링크합니다.http://ex.ampl/e1234
)
주의사항 및 주의사항
- 물론 Twitter의 어프로치가 더 좋지만, 제 앱의 요구는 URL 단축기를 추천하는 것으로 충분했습니다.
- URL 단축기에는 보안상의 우려와 같은 단점이 있습니다.제 경우 URL이 공개되지 않고 많이 사용되지 않기 때문에 큰 위험은 없습니다.그러나, 이것은 분명히 모두에게 효과가 있는 것은 아닙니다.safe.mn는 많은 스팸과 피싱 URL을 차단하는 것처럼 보이지만, 저는 여전히 주의를 권장합니다.
- 사용자에게 URL 단축자를 사용하도록 강요하지 마십시오.대부분의 경우(적어도 내 앱의 경우) 500자 정도면 대부분의 사용자가 사용하는 용도로 충분합니다.지나치게 긴 링크에 대해서만 URL 단축기를 사용하거나 권장하십시오.
URL을 사용하는 빈도와 실제로 길이를 바인딩해야 하는지 여부에 따라 TEXT 또는 VARCHAR 열 중 하나를 선택할 수 있습니다.
다음과 같은 경우 micawittman이 제안하는 대로 maxlength > = 2,083의 VARCHAR을 사용합니다.
- 쿼리당 많은 URL을 사용합니다(TEXT 열과 달리 VARCHAR은 행과 함께 인라인에 저장됩니다).
- URL이 행 제한 65,535바이트를 초과하지 않을 것이라고 확신합니다.
다음과 같은 경우 TEXTEXT
- URL이 실제로 65,535 바이트 행 제한을 위반할 수 있습니다.
- 쿼리는 여러 URL을 동시에 선택하거나 업데이트하지 않습니다(또는 자주 업데이트하지 않습니다).이는 TEXT 열이 포인터를 인라인 상태로 유지하며 참조된 데이터를 검색하는 데 수반되는 랜덤 액세스에 문제가 있을 수 있기 때문입니다.
ASCII 문자 부호화와 함께 VARCHAR을 사용해야 합니다.URL 은 퍼센트 부호화 되어 국제 도메인명은 punycode 를 사용하기 때문에, ASCII 로 보존할 수 있습니다.UTF8보다 훨씬 적은 공간을 사용합니다.
VARCHAR(512) CHARACTER SET 'ascii' COLLATE 'ascii_general_ci' NOT NULL
대부분의 브라우저에서는 대량의 데이터를 URL에 저장할 수 있기 때문에 많은 것들이 매우 큰 URL을 생성하게 됩니다.따라서 URL의 도메인 부분보다 더 많은 것을 말하는 경우에는 VARCHAR/CHAR이 제한되므로 TEXT 열을 사용해야 합니다.
다른 브라우저는 모르겠지만 IE7은 HTTP GET 조작에 2083자 제한이 있습니다.더 낮은 제한이 있는 브라우저가 없다면 2083보다 더 많은 문자가 필요한 이유를 알 수 없습니다.
varchar(max)를 사용하는 것이 좋습니다. 이는 (크기의 관점에서)varchar (65535)
이렇게 하면 더 큰 웹 주소도 저장되고 공간도 절약됩니다.
최대 지정자는 varchar, nvarchar 및 varbinary 데이터 유형의 스토리지 기능을 확장합니다.varchar(max), nvarchar(max) 및 varbinary(max)는 집합적으로 큰 값의 데이터 유형이라고 불립니다.큰 값의 데이터 유형을 사용하여 최대 2^31-1바이트의 데이터를 저장할 수 있습니다.
TechNet에서 대용량 데이터 유형 사용에 대한 이 기사를 참조하십시오.
대부분의 웹 서버에는 URL 길이 제한이 있습니다(따라서 "URI too long" 오류 코드가 있습니다). 즉, 실제적인 상한 사이즈가 있습니다.가장 많이 사용되는 웹 서버에 대한 기본 길이 제한을 찾은 후 가장 큰 웹 서버를 필드의 최대 크기로 사용합니다. 이 크기는 충분합니다.
언급URL : https://stackoverflow.com/questions/219569/best-database-field-type-for-a-url
'source' 카테고리의 다른 글
자연어 처리를 위한 Java 또는 Python (0) | 2022.10.25 |
---|---|
Brew를 통해 MySQL을 설치한 후 PID 파일을 업데이트하지 않고 서버가 종료되었습니다.라는 오류가 나타납니다. (0) | 2022.10.25 |
Java는 불량 데이터에 대한 예외를 발생시키지 않는 int.tryparse를 가지고 있습니까? (0) | 2022.10.25 |
자바에서 패키지 이름을 포함한 현재 클래스 이름을 가져오려면 어떻게 해야 합니까? (0) | 2022.10.25 |
MariaDB 30일 이내에 만료되는 계정의 모든 레코드를 선택합니다. (0) | 2022.10.25 |