레일에서 문자열과 텍스트의 차이점은 무엇입니까?


435

나는 레일을 사용하여 새 웹 응용 프로그램을 만들고 있어요, 그리고 궁금 해서요의 차이 무엇 string과 text? 그리고 각각 언제 사용해야합니까?

답변:


522

차이점은 쿼리 언어에서 기호가 해당 열 유형으로 변환되는 방식에 달려 있습니다.

MySQL과 : 문자열 VARCHAR에 매핑 (255) - http://guides.rubyonrails.org/migrations.html

:string |                   VARCHAR                | :limit => 1 to 255 (default = 255)  
:text   | TINYTEXT, TEXT, MEDIUMTEXT, or LONGTEXT2 | :limit => 1 to 4294967296 (default = 65536)

참고:

http://www.packtpub.com/article/Working-with-Rails-ActiveRecord-Migrations-Models-Scaffolding-and-Database-Completion

각각 언제 사용해야합니까?

일반적으로 :string간단한 텍스트 입력 (사용자 이름, 전자 메일, 비밀번호, 제목 등)에 사용 :text하고 설명, 주석 내용 등과 같은 더 긴 예상 입력에 사용하십시오 .


11
더 나은 경험 법칙은 항상 사용하는 것 :text입니다. depesz.com/2010/03/02/charx-vs-varcharx-vs-varchar-vs-text
— Reed G. Law

74
MySQL의 경우, 그리 많지 않은 것은 varchars에 대한 인덱스를 가질 수 있고 텍스트에는 없습니다.
— Omar Qureshi

12
PostgreSQL 구현은 텍스트를 선호합니다. pg 문자열 / 텍스트의 유일한 차이점은 문자열 길이에 대한 제약입니다. 성능 차이가 없습니다.
— Andy Bettisworth

이것은 ActiveRecord의 전체 이야기가 아닌 것 같습니다. MySQL에서 truevarchar (ergo, stringtype 필드)에 값 을 저장하면 값 1이 (완전히 공평하게) 직렬화 됩니다. 그러나 texttype에서 "true"값을 저장하면 단일 char로 직렬화됩니다 t. 나는 이것을 실현하지 않고 열을 마이그레이션했으며 값이 true 인 미래의 모든 행이 이제 t있습니다. 누구든지이 행동에 대한 통찰력이 있습니까?
— 피터

1
@ elli0t는 색인을 생성 할 수 없음을 의미합니다. 이것이 중요한 경우, MySQL에서 텍스트를 사용해서는 안됩니다
— Omar Qureshi

157

postgres를 사용하는 경우 text 대 varchar에 대한 성능 페널티가 없기 때문에 크기 제한이 없으면 텍스트를 사용하십시오.

공백으로 채워진 유형을 사용할 때 스토리지 공간이 증가하고 길이가 제한된 컬럼에 저장할 때 길이를 확인하는 몇 가지 추가 CPU주기 외에는이 세 가지 유형간에 성능 차이가 없습니다. character (n)은 일부 다른 데이터베이스 시스템에서 성능 이점이 있지만 PostgreSQL에서는 그러한 이점이 없습니다. 실제로 character (n)은 추가 스토리지 비용으로 인해 일반적으로 3 개 중 가장 느립니다. 대부분의 상황에서 텍스트 나 문자를 다르게 사용해야합니다.

PostsgreSQL 매뉴얼


4
그러나 데이터베이스에 구애받지 않기 위해 이것이 최선의 접근 방법입니까? 데이터베이스를 변경하려면 어떻게합니까? 나는 현실 세계에서 그렇게 자주 발생하지 않지만 여전히``성능 차이가 없다면 ''짧은 일에 문자열을 사용하고 더 긴 일에 텍스트를 사용하는 것이 어떻습니까? 그리고 자신의 주석 색인 문자열을 고려할 때 여전히 최선의 방법으로 보입니다.
— Dan Barron

6
현실에서 필요할 수있는 이유는 여러 가지가 있는데, 문제에 대한 하나의 진정한 해결책이 있다는 생각을 없애는 것이 가장 좋습니다.
— Dan Barron

14
그럴 수도 있지만 데이터베이스 불가지론은 거짓 선지자입니다.
— Omar Qureshi

2
성능 저하가 중요한지 또는 조기 최적화의 경우에 대한 정보가 있습니까? 내 생각에 당신은 차이를 느끼지 못할 것입니다. 단락의 시작은 "이 세 가지 유형 사이에는 성능 차이가 없습니다"는 것을 확인하는 것 같습니다.
— Dennis

5
당신은 좋은 지적을하지만 전적으로 확신하지는 않습니다. textover (n)데이터 유형 을 사용하기위한 블로그 게시물의 주장 은 설득력이 있지만 textover 를 사용하는 주장 varchar은 그렇지 않습니다. 그는 그들이 같은거야라고하지만 좋아 text하기 때문에 varchar혼동 할 수 있습니다 varchar(n)때문 text입력 적은 문자입니다. 그러나 text대신에 varchar를 사용하면 저장된 데이터가 길지 않아야한다는 컨텍스트를 잃게됩니다. 예를 들어, 사용자 이름을 저장하면 text오해의 소지가 있습니다.
— Dennis

17

문자열은 데이터베이스에서 "Varchar"로 번역되고 텍스트는 "text"로 번역됩니다. varchar는 훨씬 적은 수의 항목을 포함 할 수 있으며 텍스트는 길이가 거의 다를 수 있습니다.

참조가 좋은 심층 분석은 http://www.pythian.com/news/7129/text-vs-varchar/를 확인 하십시오.

편집 : 일부 데이터베이스 엔진은 varchar한 번에 로드 할 수 있지만 테이블 외부에 텍스트 (및 블롭)를 저장할 수 있습니다 . A는 SELECT name, amount FROM products사용하는 경우, 많은 느린 수 text를 위해 name사용할 때보다 varchar. Rails부터는 기본적으로 SELECT * FROM...텍스트 열이있는 레코드 가로드됩니다. 그래도 이것은 아마도 내 앱에서 실제로 문제가되지 않을 것입니다 (조기 최적화는 ...). 그러나 텍스트가 항상 "무료"인 것은 아는 것이 좋습니다.


12

크기가 고정적이고 작 으면 문자열이고 가변적이고 큰 경우 텍스트입니다. 텍스트가 문자열보다 크기 때문에 이것은 중요합니다. 더 많은 킬로바이트가 포함되어 있습니다.

따라서 작은 필드의 경우 항상 string (varchar)을 사용하십시오. 같은 분야. first_name, 로그인, 이메일, 제목 (기사 또는 게시물) 및 텍스트 예 : 게시물 또는 기사의 내용 / 본문. 단락 등의 필드

문자열 크기 1 ~ 255 (기본값 = 255)

텍스트 크기 1 ~ 4294967296 (기본값 = 65536) 2


11

위에서 설명한 것처럼 db 데이터 유형은 비계 인 경우 생성되는 뷰에도 영향을 미칩니다. 문자열은 text_field를 생성합니다. text는 text_area를 생성합니다.


2

이름, 주소, 전화 번호, 회사와 같은 짧은 필드에는 문자열을 사용하십시오.

더 큰 내용, 설명, 내용, 단락에는 텍스트를 사용하십시오.

나의 일반적인 규칙, 그것이 한 줄 이상의 무언가라면, 나는 보통 2-6 단어의 짧은 텍스트라면 텍스트를 찾습니다.

문자열의 공식 규칙은 255입니다. 따라서 문자열이 255자를 초과하면 텍스트로 이동하십시오.


1

oracle을 사용하는 경우 ... STRING가 VARCHAR(255)열로 생성 되고 TEXT, 가로 생성됩니다 CLOB.

NATIVE_DATABASE_TYPES = {
    primary_key: "NUMBER(38) NOT NULL PRIMARY KEY",
    string: { name: "VARCHAR2", limit: 255 },
    text: { name: "CLOB" },
    ntext: { name: "NCLOB" },
    integer: { name: "NUMBER", limit: 38 },
    float: { name: "BINARY_FLOAT" },
    decimal: { name: "DECIMAL" },
    datetime: { name: "TIMESTAMP" },
    timestamp: { name: "TIMESTAMP" },
    timestamptz: { name: "TIMESTAMP WITH TIME ZONE" },
    timestampltz: { name: "TIMESTAMP WITH LOCAL TIME ZONE" },
    time: { name: "TIMESTAMP" },
    date: { name: "DATE" },
    binary: { name: "BLOB" },
    boolean: { name: "NUMBER", limit: 1 },
    raw: { name: "RAW", limit: 2000 },
    bigint: { name: "NUMBER", limit: 19 }
}

https://github.com/rsim/oracle-enhanced/blob/master/lib/active_record/connection_adapters/oracle_enhanced_adapter.rb


1

허용되는 답변은 훌륭합니다. 문자열과 텍스트의 차이 (대부분 데이터베이스의 제한 크기이지만 몇 가지 다른 문제가 있음)를 올바르게 설명하지만 그 대답으로 나를 통과시키는 작은 문제를 지적하고 싶었습니다. 나를 위해 그것을 완전히하지 않았다.

최대 크기 : limit => 1 ~ 4294967296 은 정확히 작동하지 않았으므로 최대 크기에서 -1로 이동해야했습니다. 나는 큰 JSON blob을 저장하고 있으며 때로는 거대한 미친 일입니다.

다음은 MySQL이 불평하지 않는 가치로 더 큰 가치를 가진 마이그레이션입니다.

6이 아니라 한계의 끝에서 5 를 유의하십시오.

class ChangeUserSyncRecordDetailsToText < ActiveRecord::Migration[5.1]
  def up
    change_column :user_sync_records, :details, :text, :limit => 4294967295
  end

  def down
    change_column :user_sync_records, :details, :string, :limit => 1000
  end
end

0

속성이 f.text_field양식 사용 문자열 에서 일치 f.text_area하면 텍스트를 사용 하십시오 .

당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.