'COLLATE SQL_Latin1_General_CP1_CI_AS' ทำอะไร

ฉันมีแบบสอบถาม SQL เพื่อสร้างฐานข้อมูลใน SQLServer ตามที่ระบุด้านล่าง:

create database yourdb
on
( name = 'yourdb_dat',
  filename = 'c:\program files\microsoft sql server\mssql.1\mssql\data\yourdbdat.mdf',
  size = 25mb,
  maxsize = 1500mb,
  filegrowth = 10mb )
log on
( name = 'yourdb_log',
  filename = 'c:\program files\microsoft sql server\mssql.1\mssql\data\yourdblog.ldf',
  size = 7mb,
  maxsize = 375mb,
  filegrowth = 10mb )
COLLATE SQL_Latin1_General_CP1_CI_AS;
go

มันทำงานได้ดี

ในขณะที่ SQL ที่เหลือนั้นชัดเจนว่าฉันค่อนข้างสับสนเกี่ยวกับการทำงานของCOLLATE SQL_Latin1_General_CP1_CI_AS.

ใครช่วยอธิบายเรื่องนี้ให้ฉันฟังหน่อย นอกจากนี้ฉันต้องการทราบว่าการสร้างฐานข้อมูลด้วยวิธีนี้เป็นแนวทางปฏิบัติที่ดีที่สุดหรือไม่?

กำหนดวิธีการจัดเรียงเซิร์ฟเวอร์ฐานข้อมูล (เปรียบเทียบชิ้นส่วนของข้อความ) ในกรณีนี้:

SQL_Latin1_General_CP1_CI_AS

แบ่งออกเป็นส่วนที่น่าสนใจ:

1. latin1 ทำให้เซิร์ฟเวอร์ปฏิบัติต่อสตริงโดยใช้ charset latin 1 โดยพื้นฐานแล้ว ascii
2. CP1 ย่อมาจาก Code Page 1252
3. CI การเปรียบเทียบแบบไม่คำนึงถึงตัวพิมพ์เล็กและใหญ่ดังนั้น 'ABC' จึงเท่ากับ 'abc'
4. AS เน้นความไวดังนั้น 'ü' จึงไม่เท่ากับ 'u'

PSสำหรับรายละเอียดเพิ่มเติมให้แน่ใจว่าได้อ่านคำตอบ @ โซโลมอน rutzky ของ

โปรดทราบว่าคำตอบที่ยอมรับนั้นไม่สมบูรณ์เล็กน้อย ใช่ในระดับพื้นฐานที่สุด Collation จะจัดการกับการเรียงลำดับ แต่กฎการเปรียบเทียบที่กำหนดโดยการเรียงลำดับที่เลือกจะถูกใช้ในหลาย ๆ ที่นอกเหนือจากการสอบถามของผู้ใช้กับข้อมูลผู้ใช้

ถ้า " COLLATE SQL_Latin1_General_CP1_CI_ASทำอะไร" หมายถึง " COLLATEประโยคของCREATE DATABASEdo คืออะไร" จากนั้น:

COLLATE {collation_name}ประโยคของCREATE DATABASEคำสั่งระบุเปรียบเทียบค่าเริ่มต้นของฐานข้อมูลและไม่เซิร์ฟเวอร์; Collations เริ่มต้นระดับฐานข้อมูลและระดับเซิร์ฟเวอร์ควบคุมสิ่งที่แตกต่างกัน

เซิร์ฟเวอร์ (เช่นอินสแตนซ์) -การควบคุมระดับ :

• ฐานข้อมูลระดับ Collation สำหรับฐานข้อมูลระบบ: master, model, และmsdbtempdb
• เนื่องจากการควบคุมการจัดเรียงระดับฐานข้อมูลtempdbจึงเป็นค่าเริ่มต้นของการจัดเรียงคอลัมน์สตริงในตารางชั่วคราว (ส่วนกลางและภายใน) แต่ไม่ใช่ตัวแปรตาราง
• เนื่องจากการควบคุมการจัดเรียงระดับฐานข้อมูลของ masterจึงเป็นการ Collation ที่ใช้สำหรับข้อมูลระดับเซิร์ฟเวอร์เช่นชื่อฐานข้อมูล (เช่นnameคอลัมน์ในsys.databases) ชื่อล็อกอินเป็นต้น
• การจัดการชื่อพารามิเตอร์ / ตัวแปร
• การจัดการชื่อเคอร์เซอร์
• การจัดการGOTOฉลาก
• การเรียงค่าเริ่มต้นที่ใช้สำหรับฐานข้อมูลที่สร้างขึ้นใหม่เมื่อไฟล์ COLLATEคำสั่งหายไป

ระดับฐานข้อมูลการควบคุม :

• เริ่มต้นการเปรียบเทียบที่ใช้สำหรับคอลัมน์สตริงที่สร้างขึ้นใหม่ ( CHAR, VARCHAR, NCHAR, NVARCHAR, TEXTและNTEXT- แต่ไม่ได้ใช้TEXTหรือNTEXT) เมื่อCOLLATEข้อหายไปจากความหมายของคอลัมน์ สำหรับทั้งสองอย่างนี้CREATE TABLEกับALTER TABLE ... ADDงบ
• การเรียงค่าเริ่มต้นที่ใช้สำหรับตัวอักษรสตริง (เช่น 'some text' ) และตัวแปรสตริง (เช่น@StringVariable) การเรียงลำดับนี้จะใช้เมื่อเปรียบเทียบสตริงและตัวแปรกับสตริงและตัวแปรอื่นเท่านั้น เมื่อเปรียบเทียบสตริง / ตัวแปรกับคอลัมน์จะใช้การจัดเรียงคอลัมน์
• การจัดเรียงที่ใช้สำหรับข้อมูลเมตาระดับฐานข้อมูลเช่นชื่อวัตถุ (เช่นsys.objects) ชื่อคอลัมน์ (เช่นsys.columns ) ชื่อดัชนี (เช่นsys.indexes) เป็นต้น
• การเรียงลำดับที่ใช้สำหรับระดับฐานข้อมูลวัตถุ : ตารางคอลัมน์ดัชนี ฯลฯ

นอกจากนี้:

• ASCII คือการเข้ารหัสซึ่งมีขนาด 8 บิต (สำหรับการใช้งานทั่วไปในทางเทคนิค "ASCII" คือ 7 บิตโดยมีค่าอักขระ 0 - 127 และ "ASCII Extended" คือ 8 บิตโดยมีค่าอักขระ 0-255) กลุ่มนี้เหมือนกันในทุกวัฒนธรรม
• โค้ดเพจเป็นส่วนที่ "ขยาย" ของ Extended ASCII และควบคุมว่าจะใช้อักขระใดสำหรับค่า 128-255 กลุ่มนี้จะแตกต่างกันไปตามแต่ละวัฒนธรรม
• Latin1ไม่ได้หมายความว่า "ASCII" เนื่องจาก ASCII มาตรฐานครอบคลุมเฉพาะค่า 0 - 127 และโค้ดเพจทั้งหมด (ที่สามารถแสดงใน SQL Server และแม้กระทั่งNVARCHAR) แมปค่า 128 ที่เหมือนกันกับอักขระเดียวกัน

ถ้า " COLLATE SQL_Latin1_General_CP1_CI_ASทำอะไร" หมายถึง "การเปรียบเทียบโดยเฉพาะนี้ทำอะไร" จากนั้น:

• เนื่องจากชื่อขึ้นต้นด้วยSQL_นี่คือการเปรียบเทียบ SQL Server ไม่ใช่การเปรียบเทียบ Windows สิ่งเหล่านี้ล้าสมัยอย่างแน่นอนแม้ว่าจะไม่ได้เลิกใช้อย่างเป็นทางการก็ตามและส่วนใหญ่มีไว้สำหรับความเข้ากันได้ก่อน SQL Server 2000 แม้ว่าจะSQL_Latin1_General_CP1_CI_ASเป็นเรื่องธรรมดามากเนื่องจากเป็นค่าเริ่มต้นเมื่อติดตั้งบนระบบปฏิบัติการโดยใช้ภาษาอังกฤษแบบสหรัฐอเมริกาเป็นภาษาของมัน ควรหลีกเลี่ยงการจัดเรียงเหล่านี้หากเป็นไปได้

  การจัดเรียงของ Windows (ที่ไม่ได้ขึ้นต้นด้วยชื่อSQL_) เป็นรุ่นที่ใหม่กว่าทำงานได้มากกว่ามีการเรียงลำดับที่สอดคล้องกันระหว่างVARCHARและNVARCHARสำหรับค่าเดียวกันและกำลังได้รับการอัปเดตด้วยน้ำหนักการเรียงลำดับเพิ่มเติม / แก้ไขและการแมปตัวพิมพ์ใหญ่ / ตัวพิมพ์เล็ก เรียงเหล่านี้ยังไม่ได้มีปัญหาประสิทธิภาพการทำงานที่อาจเกิดขึ้นว่า collations SQL Server มี: ผลกระทบต่อดัชนีเมื่อผสม VARCHAR และประเภท

• Latin1_General คือวัฒนธรรม / สถานที่
  • สำหรับNCHAR, NVARCHARและNTEXTข้อมูลนี้จะกำหนดกฎระเบียบทางภาษาที่ใช้ในการคัดแยกและการเปรียบเทียบ
  • สำหรับCHAR, VARCHARและTEXTข้อมูล (คอลัมน์ตัวอักษรและตัวแปร) นี้กำหนด:
    • กฎทางภาษาที่ใช้สำหรับการเรียงลำดับและการเปรียบเทียบ
    • หน้ารหัสที่ใช้ในการเข้ารหัสอักขระ ตัวอย่างเช่นการLatin1_Generalจัดเรียงใช้รหัสหน้า 1252 การHebrewเปรียบเทียบใช้รหัสหน้า 1255 เป็นต้น

• CP{code_page} หรือ {version}

  • สำหรับSQL Server collations: CP{code_page}เป็นโค้ดเพจ 8 บิตที่กำหนดว่าอักขระใดแม็พกับค่า 128-255 ในขณะที่มีโค้ดเพจสี่เพจสำหรับ Double-Byte Character Sets (DBCS) ที่สามารถใช้ชุดค่าผสม 2 ไบต์เพื่อสร้างมากกว่า 256 อักขระเหล่านี้ไม่พร้อมใช้งานสำหรับการเปรียบเทียบ SQL Server

  • สำหรับWindows collations: {version}แม้ว่าจะไม่มีอยู่ในชื่อการจัดเรียงทั้งหมด แต่หมายถึงเวอร์ชันของ SQL Server ที่มีการนำการเปรียบเทียบมาใช้ (ส่วนใหญ่) การเปรียบเทียบ Windows ที่ไม่มีหมายเลขเวอร์ชันในชื่อคือเวอร์ชัน80(หมายถึง SQL Server 2000 เช่นเดียวกับเวอร์ชัน 8.0) SQL Server บางเวอร์ชันไม่ได้มาพร้อมกับการเรียงใหม่ดังนั้นจึงมีช่องว่างในหมายเลขเวอร์ชัน มีบางส่วนที่เป็น90(สำหรับ SQL Server 2005 ซึ่งเป็นเวอร์ชัน 9.0) ส่วนใหญ่เป็น100(สำหรับ SQL Server 2008 เวอร์ชัน 10.0) และชุดเล็ก ๆ140 (สำหรับ SQL Server 2017 เวอร์ชัน 14.0)

    ฉันพูดว่า "ส่วนใหญ่" เนื่องจากการเรียงลำดับที่ลงท้ายด้วย_SCถูกนำมาใช้ใน SQL Server 2012 (เวอร์ชัน 11.0) แต่ข้อมูลพื้นฐานไม่ใช่เรื่องใหม่ แต่เพิ่มการรองรับอักขระเสริมสำหรับฟังก์ชันในตัวเท่านั้น ดังนั้นตอนจบเหล่านี้จึงมีอยู่สำหรับเวอร์ชัน90และการ100เปรียบเทียบ แต่เริ่มต้นใน SQL Server 2012 เท่านั้น

• ต่อไปคุณจะมีความไวซึ่งอาจอยู่ในชุดค่าผสมต่อไปนี้ แต่จะระบุไว้ในลำดับนี้เสมอ:
  • CS= case-sensitive หรือCI= case-insensitive
  • AS= เน้นเสียงหรือAI= ไม่เน้นเสียง
  • KS = Kana type-sensitive or missing = Kana type-insensitive
  • WS = width-sensitive or missing = width insensitive
  • VSS = ตัวเลือกรูปแบบที่ละเอียดอ่อน (มีเฉพาะในรุ่น 140 collations) หรือไม่มี = ตัวเลือกการเปลี่ยนแปลงที่ไม่สำคัญ

• ชิ้นสุดท้ายเสริม:

  • _SCในตอนท้ายหมายถึง "การสนับสนุนตัวละครเสริม" "การสนับสนุน" มีผลเฉพาะกับการที่ฟังก์ชันในตัวตีความคู่ตัวแทน (ซึ่งเป็นวิธีเข้ารหัสอักขระเสริมใน UTF-16) หากไม่มี_SCส่วนท้าย (หรือ_140_ตรงกลาง) ฟังก์ชันในตัวจะไม่เห็นอักขระเสริมเพียงตัวเดียว แต่จะเห็นจุดรหัสที่ไม่มีความหมายสองจุดที่ประกอบเป็นคู่ตัวแทน ตอนจบนี้สามารถเพิ่มลงในการเปรียบเทียบที่ไม่ใช่ไบนารีเวอร์ชัน 90 หรือ 100
  • _BINหรือ_BIN2ในตอนท้ายหมายถึงการเรียงลำดับและการเปรียบเทียบแบบ "ไบนารี" ข้อมูลยังคงถูกจัดเก็บเหมือนเดิม แต่ไม่มีกฎเกณฑ์ทางภาษา ตอนจบนี้จะไม่รวมกับการใด ๆ ของ 5 _SCความเปราะบางหรือ _BINเป็นสไตล์เก่าและ_BIN2เป็นสไตล์ใหม่ที่ถูกต้องกว่า หากใช้ SQL Server 2005 หรือใหม่กว่าให้ใช้_BIN2. สำหรับรายละเอียดเกี่ยวกับความแตกต่างระหว่าง_BINและ_BIN2โปรดดูที่: ความแตกต่างระหว่างต่างๆไบนารี Collations (วัฒนธรรมรุ่นและถัง VS BIN2)

  • _UTF8เป็นตัวเลือกใหม่ของ SQL Server 2019 เป็นการเข้ารหัสแบบ 8 บิตที่อนุญาตให้จัดเก็บข้อมูล Unicode VARCHARและCHARประเภทข้อมูล (แต่ไม่ใช่TEXTประเภทข้อมูลที่เลิกใช้แล้ว) ตัวเลือกนี้สามารถใช้ได้เฉพาะกับการจัดเรียงที่รองรับอักขระเสริมเท่านั้น (เช่นเวอร์ชัน 90 หรือ 100 การเปรียบเทียบ_SCในชื่อและเวอร์ชัน 140 การเปรียบเทียบ) นอกจากนี้ยังมีการ_UTF8เรียงเลขฐานสองเดียว( _BIN2ไม่ใช่_BIN)

    โปรดทราบ: UTF-8 ได้รับการออกแบบ / สร้างขึ้นเพื่อให้เข้ากันได้กับสภาพแวดล้อม / รหัสที่ตั้งค่าสำหรับการเข้ารหัส 8 บิต แต่ต้องการสนับสนุน Unicode แม้ว่าจะมีบางสถานการณ์ที่ UTF-8 สามารถประหยัดพื้นที่ได้ถึง 50% เมื่อเทียบกับการเรียง นี่เป็นสภาวะธรรมชาติสำหรับทุกคนที่ใช้สิ่งนี้เพื่อความเข้ากันได้ แต่ไม่ใช่สำหรับผู้ที่หวังจะใช้เพื่อประหยัดพื้นที่ โปรดใช้ความระมัดระวังในการผสมข้อมูล VARCHAR โดยใช้การเปรียบเทียบกับข้อมูลโดยใช้การไม่จัดเรียงหรือข้อมูลเนื่องจากคุณอาจพบพฤติกรรมแปลก ๆ / ข้อมูลสูญหาย สำหรับรายละเอียดเพิ่มเติมเกี่ยวกับการเปรียบเทียบ UTF-8 ใหม่โปรดดูที่: Native UTF-8 Support in SQL Server 2019: Savior or False Prophet?NVARCHARแต่นั่นเป็นผลข้างเคียงและมีค่าใช้จ่ายเล็กน้อยต่อประสิทธิภาพในการดำเนินการหลายอย่าง / ส่วนใหญ่ หากคุณต้องการสิ่งนี้เพื่อความเข้ากันได้ก็ยอมรับค่าใช้จ่ายได้ หากคุณต้องการสิ่งนี้เพื่อการประหยัดพื้นที่คุณต้องทดสอบให้ดีขึ้นและทดสอบอีกครั้ง การทดสอบรวมถึงฟังก์ชันการทำงานทั้งหมดและข้อมูลมากกว่าสองสามแถว ขอเตือนว่าการเปรียบเทียบ UTF-8 จะทำงานได้ดีที่สุดเมื่อคอลัมน์ทั้งหมดและฐานข้อมูลเองกำลังใช้VARCHARข้อมูล (คอลัมน์ตัวแปรตัวอักษรสตริง) กับ_UTF8_UTF8VARCHAR_UTF8NVARCHAR

CP1 หมายถึง 'Code Page 1' - ในทางเทคนิคจะแปลเป็นรหัสหน้า 1252

เรียงคำหลักที่ระบุชนิดของชุดอักขระและกฎระเบียบ (สั่งกฎการเผชิญหน้า) คุณใช้สำหรับค่าสตริง

ตัวอย่างเช่นในกรณีของคุณคุณกำลังใช้กฎภาษาละตินที่ไม่คำนึงถึงตัวพิมพ์เล็กและใหญ่ ( CI ) และเน้นเสียง ( AS )

คุณสามารถอ้างถึงเอกสารนี้

สิ่งนี้ระบุการเปรียบเทียบเริ่มต้นสำหรับฐานข้อมูล ทุกช่องข้อความที่คุณสร้างในตารางในฐานข้อมูลจะใช้การเปรียบเทียบนั้นเว้นแต่คุณจะระบุฟิลด์อื่น

ฐานข้อมูลมักจะมีการเปรียบเทียบค่าเริ่มต้น หากคุณไม่ระบุใด ๆ ระบบจะใช้การเปรียบเทียบเริ่มต้นของอินสแตนซ์ SQL Server

ชื่อของการจัดเรียงที่คุณใช้แสดงให้เห็นว่าใช้รหัส Latin1 หน้าที่ 1 ไม่คำนึงถึงตัวพิมพ์เล็กและใหญ่ (CI) และเน้นเสียง (AS) การจัดเรียงนี้ใช้ในสหรัฐอเมริกาดังนั้นจึงมีกฎการเรียงลำดับที่ใช้ในสหรัฐอเมริกา

การเปรียบเทียบจะตัดสินว่าค่าข้อความถูกเปรียบเทียบเพื่อความเท่าเทียมและความเหมือนอย่างไรและจะเปรียบเทียบอย่างไรเมื่อจัดเรียง โค้ดเพจถูกใช้เมื่อจัดเก็บข้อมูลที่ไม่ใช่ Unicode เช่นฟิลด์ varchar