PostgreSQL: ความแตกต่างระหว่างข้อความและ varchar (การเปลี่ยนแปลงอักขระ)

อะไรคือความแตกต่างระหว่างtextชนิดข้อมูลและcharacter varying( varchar) ชนิดข้อมูล?

ตามเอกสารประกอบ

หากใช้การเปลี่ยนแปลงอักขระโดยไม่มีตัวระบุความยาวชนิดจะยอมรับสตริงที่มีขนาดใดก็ได้ หลังคือส่วนขยาย PostgreSQL

และ

นอกจากนี้ PostgreSQL ยังมีประเภทข้อความซึ่งจัดเก็บสตริงที่มีความยาวเท่าใดก็ได้ แม้ว่าข้อความชนิดไม่ได้อยู่ในมาตรฐาน SQL แต่ระบบการจัดการฐานข้อมูล SQL อื่น ๆ ก็มีเช่นกัน

ดังนั้นความแตกต่างคืออะไร?

ไม่มีความแตกต่างภายใต้ประทุนมันคือทั้งหมดvarlena( อาร์เรย์ความยาวผันแปร )

ตรวจสอบบทความนี้จาก Depesz: http://www.depesz.com/index.php/2010/03/02/charx-vs-varcharx-vs-varchar-vs-text/

ไฮไลท์สอง:

หากต้องการสรุปทั้งหมด:

• char (n) - ใช้พื้นที่มากเกินไปเมื่อจัดการกับค่าที่สั้นกว่าn(ใส่ลงในn) และอาจทำให้เกิดข้อผิดพลาดเล็กน้อยเนื่องจากการเพิ่มช่องว่างต่อท้ายรวมถึงปัญหาในการเปลี่ยนขีด จำกัด
• varchar (n) - เป็นปัญหาในการเปลี่ยนขีด จำกัด ในสภาพแวดล้อมแบบสด (ต้องใช้การล็อกแบบเอกสิทธิ์เฉพาะบุคคลขณะเปลี่ยนตาราง)
• varchar - เหมือนข้อความ
• ข้อความ - สำหรับฉันผู้ชนะ - ประเภทข้อมูลเกิน (n) เพราะมันไม่มีปัญหาและมากกว่า varchar - เพราะมีชื่อแตกต่างกัน

บทความนี้ทำการทดสอบโดยละเอียดเพื่อแสดงให้เห็นว่าประสิทธิภาพของเม็ดมีดและเลือกสำหรับทั้ง 4 ประเภทของข้อมูลนั้นคล้ายคลึงกัน นอกจากนี้ยังดูรายละเอียดเกี่ยวกับวิธีอื่นในการจำกัดความยาวเมื่อต้องการ ฟังก์ชันข้อ จำกัด หรือโดเมนที่ให้ประโยชน์ของการเพิ่มความยาวของข้อ จำกัด และบนพื้นฐานของการลดข้อจำกัดความยาวของสตริงนั้นหาได้ยาก Depesz สรุปว่าหนึ่งในนั้นมักจะเป็นตัวเลือกที่ดีที่สุดสำหรับการจำกัดความยาว

ในฐานะที่เป็น " ตัวละครประเภท " ในจุดเอกสารออกvarchar(n), char(n)และtextทั้งหมดถูกเก็บไว้ในลักษณะเดียวกัน ความแตกต่างเพียงอย่างเดียวคือรอบพิเศษที่จำเป็นในการตรวจสอบความยาวหากมีการกำหนดและต้องใช้พื้นที่และเวลาเพิ่มเติมหากจำเป็นต้องใช้ช่องว่างchar(n)ภายใน

อย่างไรก็ตามเมื่อคุณต้องการเก็บอักขระเพียงตัวเดียวจะมีข้อได้เปรียบด้านประสิทธิภาพเล็กน้อยเมื่อใช้ชนิดพิเศษ"char"(เก็บเครื่องหมายคำพูดคู่ไว้ - เป็นส่วนหนึ่งของชื่อประเภท) คุณเข้าถึงฟิลด์ได้เร็วขึ้นและไม่มีค่าใช้จ่ายในการจัดเก็บความยาว

ฉันเพิ่งสร้างตารางสุ่ม"char"เลือก1,000,000 ตัวจากตัวอักษรตัวพิมพ์เล็ก แบบสอบถามเพื่อรับการแจกแจงความถี่ ( select count(*), field ... group by field) ใช้เวลาประมาณ 650 มิลลิวินาทีเทียบกับประมาณ 760 ข้อมูลเดียวกันโดยใช้textฟิลด์

การอัพเดท BENCHMARKS สำหรับปี 2559 (pg9.5 +)

และใช้การเปรียบเทียบ "pure SQL" (ไม่มีสคริปต์ภายนอก)

1. ใช้ string_generator ใด ๆ กับ UTF8

2. มาตรฐานหลัก:

   2.1 INSERT

   2.2 เลือกการเปรียบเทียบและการนับ

CREATE FUNCTION string_generator(int DEFAULT 20,int DEFAULT 10) RETURNS text AS $f$
  SELECT array_to_string( array_agg(
    substring(md5(random()::text),1,$1)||chr( 9824 + (random()*10)::int )
  ), ' ' ) as s
  FROM generate_series(1, $2) i(x);
$f$ LANGUAGE SQL IMMUTABLE;

เตรียมการทดสอบเฉพาะ (ตัวอย่าง)

DROP TABLE IF EXISTS test;
-- CREATE TABLE test ( f varchar(500));
-- CREATE TABLE test ( f text); 
CREATE TABLE test ( f text  CHECK(char_length(f)<=500) );

ทำการทดสอบขั้นพื้นฐาน:

INSERT INTO test  
   SELECT string_generator(20+(random()*(i%11))::int)
   FROM generate_series(1, 99000) t(i);

และการทดสอบอื่น ๆ

CREATE INDEX q on test (f);

SELECT count(*) FROM (
  SELECT substring(f,1,1) || f FROM test WHERE f<'a0' ORDER BY 1 LIMIT 80000
) t;

... EXPLAIN ANALYZEและการใช้งาน

อัปเดตอีกครั้ง 2018 (pg10)

แก้ไขเพียงเล็กน้อยเพื่อเพิ่มผลลัพธ์ของ 2018 และเสริมคำแนะนำ

ผลลัพธ์ในปี 2559 และ 2561

ผลลัพธ์ของฉันโดยเฉลี่ยแล้วในเครื่องหลายเครื่องและการทดสอบหลายอย่าง: เหมือนกันทั้งหมด
(ค่าเบี่ยงเบนมาตรฐานต่ำกว่าจริง)

คำแนะนำ

• ใช้textประเภทข้อมูล,
  หลีกเลี่ยงเก่าvarchar(x)เพราะบางครั้งมันไม่ได้มาตรฐานเช่นใน CREATE FUNCTIONข้อ ≠varchar(x)varchar(y)

• แสดงขีด จำกัด (แบบเดียวกับvarcharผลการปฏิบัติงาน) โดยมีCHECKข้อในเช่นCREATE TABLE
  ด้วยการสูญเสียประสิทธิภาพเล็กน้อยใน INSERT / UPDATE คุณสามารถควบคุมช่วงและโครงสร้างสตริง เช่นCHECK(char_length(x)<=10)

CHECK(char_length(x)>5 AND char_length(x)<=20 AND x LIKE 'Hello%')

ในคู่มือ PostgreSQL

ไม่มีความแตกต่างด้านประสิทธิภาพระหว่างสามประเภทนี้นอกเหนือจากพื้นที่เก็บข้อมูลที่เพิ่มขึ้นเมื่อใช้ประเภทที่มีเบาะรองและรอบ CPU เพิ่มเติมไม่กี่รอบเพื่อตรวจสอบความยาวเมื่อจัดเก็บในคอลัมน์ที่มีความยาว จำกัด ในขณะที่ตัวละคร (n) มีข้อได้เปรียบด้านประสิทธิภาพในบางระบบฐานข้อมูลอื่น ๆ แต่ก็ไม่มีข้อได้เปรียบดังกล่าวใน PostgreSQL ในความเป็นจริงตัวละคร (n) มักจะช้าที่สุดในสามเพราะค่าใช้จ่ายในการจัดเก็บเพิ่มเติม ในสถานการณ์ส่วนใหญ่ข้อความหรือตัวละครที่แตกต่างกันควรใช้แทน

ฉันมักจะใช้ข้อความ

การอ้างอิง: http://www.postgresql.org/docs/current/static/datatype-character.html

ในความคิดของฉันvarchar(n)มีข้อดีของตัวเอง ใช่พวกเขาทั้งหมดใช้ประเภทพื้นฐานเดียวกันและทั้งหมดนั้น แต่ควรชี้ให้เห็นว่าดัชนีใน PostgreSQL มีขนาด จำกัด ที่2712 ไบต์ต่อแถว

TL; DR: ถ้าคุณใช้textประเภทที่ไม่มีข้อ จำกัดและมีดัชนีในคอลัมน์เหล่านี้เป็นไปได้มากที่คุณจะถึงขีด จำกัด นี้สำหรับบางคอลัมน์ของคุณและได้รับข้อผิดพลาดเมื่อคุณพยายามแทรกข้อมูล แต่มีการใช้varchar(n)คุณสามารถป้องกันได้

รายละเอียดเพิ่มเติม:ปัญหาที่นี่คือ PostgreSQL ไม่ได้ให้ข้อยกเว้นใด ๆ เมื่อสร้างดัชนีสำหรับtextประเภทหรือvarchar(n)ที่nมากกว่า 2712 อย่างไรก็ตามจะให้ข้อผิดพลาดเมื่อมีการพยายามแทรกเร็กคอร์ดที่มีขนาดที่บีบอัดมากกว่า 2712 หมายความว่าคุณสามารถแทรกสตริงอักขระได้ 100.000 ตัวซึ่งประกอบด้วยอักขระซ้ำ ๆ ได้ง่ายเพราะจะถูกบีบอัดต่ำกว่า 2712 แต่คุณอาจไม่สามารถแทรกสตริงบางตัวได้ด้วยอักขระ 4000 ตัวเนื่องจากขนาดที่บีบอัดมีขนาดใหญ่กว่า 2,712 ไบต์ การใช้varchar(n)ตำแหน่งที่nไม่มากกว่า 2712 มากเกินไปคุณจะปลอดภัยจากข้อผิดพลาดเหล่านี้

ข้อความและ varchar มีการแปลงประเภทโดยนัยแตกต่างกัน ผลกระทบที่ใหญ่ที่สุดที่ฉันสังเกตเห็นคือการจัดการช่องว่างต่อท้าย ตัวอย่างเช่น ...

select ' '::char = ' '::varchar, ' '::char = ' '::text, ' '::varchar = ' '::text

ผลตอบแทนtrue, false, trueและไม่ใช่true, true, trueตามที่คุณคาดหวัง

ค่อนข้าง OT: ถ้าคุณใช้ Rails การจัดรูปแบบมาตรฐานของหน้าเว็บอาจแตกต่างกัน สำหรับtextกล่องป้อนข้อมูลในรูปแบบข้อมูลสามารถเลื่อนได้ แต่กล่องcharacter varying(รางstring) เป็นหนึ่งบรรทัด แสดงมุมมองได้นานเท่าที่จำเป็น

คำอธิบายที่ดีจากhttp://www.sqlines.com/postgresql/datatypes/text :

ข้อแตกต่างระหว่าง TEXT และ VARCHAR (n) คือคุณสามารถจำกัดความยาวสูงสุดของคอลัมน์ VARCHAR ตัวอย่างเช่น VARCHAR (255) ไม่อนุญาตให้ใส่สตริงที่มีความยาวเกิน 255 อักขระ

TEXT และ VARCHAR มีขีด จำกัด สูงสุดที่ 1 Gb และไม่มีความแตกต่างด้านประสิทธิภาพ (ตามเอกสาร PostgreSQL)

character varying(n), varchar(n)- (ทั้งคู่เหมือนกัน) ค่าจะถูกปัดเศษเป็น n ตัวอักษรโดยไม่เพิ่มข้อผิดพลาด

character(n), char(n)- (ทั้งคู่เหมือนกัน) ความยาวคงที่และจะปัดด้วยช่องว่างจนถึงจุดสิ้นสุดของความยาว

text- ความยาวไม่ จำกัด

ตัวอย่าง:

Table test:
   a character(7)
   b varchar(7)

insert "ok    " to a
insert "ok    " to b

เราได้รับผลลัพธ์:

a        | (a)char_length | b     | (b)char_length
----------+----------------+-------+----------------
"ok     "| 7              | "ok"  | 2