คำถามติดแท็ก collation

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

1
วิธีตรวจสอบการเรียงของตารางใน PostgreSQL
ฉันต้องการสคริปต์ตรวจสอบการเปรียบเทียบที่ใช้ในตารางของฉันใน PostgreSQL แต่ googling สำหรับPostgresql detect collationทำงานได้ไม่ดีสำหรับฉันและเอกสารไม่ได้ทำให้การค้นหานี้ง่าย มีใครบอกฉันได้ไหมว่าฉันจะตรวจสอบเรื่องนี้อย่างไร

1
ละเว้นการเน้นเสียงใน 'ที่ไหน'
ในฐานข้อมูลของเราเรามีหลายรายการที่มี caron / hatschek ตอนนี้ผู้ใช้ของเราต้องการค้นหารายการรวมถึง caron / hatschek เมื่อค้นหารายการที่ไม่มี ฉันจะแสดงสิ่งนี้ด้วยตัวอย่างง่ายๆ: ในฐานข้อมูลของเราเรามีรายการ (ติดต่อกับชื่อ) Millière ดังนั้นชื่อนี้ถูกต้องในประเทศที่บุคคลนั้นอาศัยอยู่ ในประเทศของเราเราไม่ได้มีตัวอักษรใด ๆ กับรอน / hatschek Milliereดังนั้นผู้ใช้ค้นหาของเราสำหรับ ไม่มีผลการค้นหาขึ้นมาเป็นไม่ชัดไม่ตรงกับèe ผมไม่มีความคิดวิธีนี้อาจจะตระหนักว่าé, è, êและอื่น ๆ อีกมากมายที่มีอยู่ (และนี่เป็นเพียงตัวอย่างจดหมายe... ) (วิธีอื่นจะง่ายกว่ามากเพราะฉันสามารถแทนที่ตัวอักษรทั้งหมดด้วย caron / hatschek ด้วยตัวอักษรพื้นฐานได้อย่างชัดเจนเห็นได้ชัดว่าผู้ใช้ของเราต้องการชื่อรุ่นที่ถูกต้องในฐานข้อมูลไม่ใช่คนพิการ)

4
วิธีการตัดเครื่องหมายเน้นภาษาฮิบรู
ฉันต้องการเคล็ดลับการเข้ารหัส Char เพื่อเปลื้องเครื่องหมายสำเนียงภาษาฮิบรู ตัวอย่างก่อน בְּרֵאשִׁ֖יתבָּרָ֣אאֱלֹהִ֑יםאֵ֥תהַשָּׁמַ֖יִםוְאֵ֥תהָאָֽרֶץ ตัวอย่างหลังจาก בראשיתבראאלהיםאתהשמיםואתהארץ

2
Latin1_General_BIN ส่งผลกระทบต่อประสิทธิภาพเมื่อเปลี่ยนการเปรียบเทียบค่าเริ่มต้นของฐานข้อมูล
ฉันได้ตั้งค่าการเปรียบเทียบฐานข้อมูลเป็นLatin1_General_BINเพื่อทำการเปรียบเทียบสตริงตัวพิมพ์เล็กและตัวพิมพ์ใหญ่ สิ่งนี้จะส่งผลกระทบต่อประสิทธิภาพหรือไม่ มันจะมีผลกระทบกับการดำเนินงาน DML หรือ DDL ในฐานข้อมูลหรือไม่ ฐานข้อมูลมีอยู่แล้วในตาราง

4
SQL Server 2005/2008 UTF-8 Collation / Charset
ฉันไม่สามารถค้นหาตัวเลือกโดยตรงเพื่อตั้งค่าการUTF-8รวมCollations/Charsetsใน SQL Server 2005/2008 เช่นเดียวกับที่เป็นไปได้ในการตั้งค่าในเอ็นจิน SQL อื่น แต่ใน SQL Server 2005/2008 มีการเปรียบเทียบละตินและ SQL เท่านั้น มีตัวเลือกในการบังคับ / ติดตั้ง collations / charsets เหล่านี้ในเอ็นจิน SQL Server (สำหรับทั้งสองเวอร์ชัน) 2005/2008 บน Win2008 OS

2
ทำไมไม่ใช่ตัวเลข LIKE [0-9]
การเปรียบเทียบค่าเริ่มต้นของเซิร์ฟเวอร์ของฉันคือ Latin1_General_CI_AS ตามที่กำหนดโดยแบบสอบถามนี้: SELECT SERVERPROPERTY('Collation') AS Collation; ฉันรู้สึกประหลาดใจที่ค้นพบว่าด้วยการเปรียบเทียบนี้ฉันสามารถจับคู่อักขระที่ไม่ใช่ตัวเลขในสตริงโดยใช้เพLIKE '[0-9]'รดิเคต ทำไมในการจัดเรียงเริ่มต้นนี้เกิดขึ้นได้อย่างไร ฉันไม่สามารถนึกถึงกรณีที่สิ่งนี้จะเป็นประโยชน์ ฉันรู้ว่าฉันสามารถหลีกเลี่ยงพฤติกรรมนี้ได้โดยใช้การเปรียบเทียบแบบไบนารี แต่ดูเหมือนจะเป็นวิธีที่แปลกในการใช้การเปรียบเทียบแบบเริ่มต้น ตัวกรองหลักสร้าง caracters ที่ไม่ใช่ตัวเลข ฉันสามารถสาธิตพฤติกรรมโดยการสร้างคอลัมน์ที่มีค่าอักขระไบต์เดียวที่เป็นไปได้ทั้งหมดและกรองค่าด้วยภาคแสดงการจับคู่ตัวเลข คำสั่งต่อไปนี้สร้างตารางชั่วคราวที่มี 256 แถวหนึ่งแถวสำหรับรหัสแต่ละจุดในหน้ารหัสปัจจุบัน: WITH P0(_) AS (SELECT 0 UNION ALL SELECT 0), P1(_) AS (SELECT 0 FROM P0 AS L CROSS JOIN P0 AS R), P2(_) AS (SELECT 0 FROM P1 AS L …

4
มีการเปรียบเทียบเรียงลำดับสตริงต่อไปนี้ตามลำดับต่อไปนี้ 1,2,3,6,10,10A, 10B, 11 หรือไม่
ฉันมีฐานข้อมูลที่มีคอลัมน์ VARCHAR ที่มีจำนวนเต็มความยาวแตกต่างกัน ฉันต้องการจัดเรียงพวกเขาดังนั้น 10 มาหลังจาก 9 ไม่ใช่ 1 และ 70A มาหลังจาก 70 ฉันสามารถทำได้ด้วยPATINDEX () , คำสั่ง CTE และ CASE ในส่วนคำสั่ง WHERE อย่างไรก็ตามฉันสงสัยว่ามีการเปรียบเทียบที่นี่จะไม่จำเป็น

2
ตั้งค่า character_set_client เป็น utf8mb4
ฉันพยายามแปลงฐานข้อมูลของฉันให้เป็นutf8mb4ไปตามคู่มือนี้ ฉันได้ตั้ง: [client] default-character-set=utf8mb4 [mysql] default-character-set=utf8mb4 [mysqld] init-connect='SET NAMES utf8mb4' collation_server=utf8mb4_unicode_ci character_set_server=utf8mb4 skip-character-set-client-handshake แต่คุณค่าของcharacter_set_clientและcharacter_set_resultsยังคงไม่เปลี่ยนเป็น utf8mb4 mysql> SHOW VARIABLES WHERE Variable_name LIKE 'character\_set\_%' OR Variable_name LIKE 'collation%'; +--------------------------+--------------------+ | Variable_name | Value | +--------------------------+--------------------+ | character_set_client | utf8 | | character_set_connection | utf8mb4 | | character_set_database | utf8mb4 | | character_set_filesystem …
12 mysql  collation  utf-8 

1
N'Șc 'พิจารณาคีย์ที่ซ้ำกันของ N'C' โดยใช้การเปรียบเทียบ Latin1_General_CI_AS
ฉันมีตารางที่มีคีย์เฉพาะที่มีNVARCHAR(50)คอลัมน์ (ถูกต้องหรือไม่ แต่มีอยู่) ดังนั้นเมื่อพยายามที่จะแทรกȘcหรือC(ไม่สำคัญกับคำสั่งของเม็ดมีด) มันจะแตกบนเม็ดที่สองเนื่องจากปัญหาการเรียง นี่คือข้อผิดพลาด: (รับผลกระทบ 1 แถว) ข่าวสารเกี่ยวกับ 2601, ระดับ 14, สถานะ 1, บรรทัดที่ 16 ไม่สามารถแทรกแถวคีย์ซ้ำในวัตถุ 'dbo.testT' ด้วยดัชนีเฉพาะ 'IX_TestT' ค่าคีย์ที่ซ้ำกันคือ (C) เลือกผลตอบแทน: Latin1_General_CI_ASเปรียบเทียบค่าเริ่มต้นฐานข้อมูลเป็น ใช้เวลาดูวิธีการแก้ปัญหาโดยไม่ต้องเปลี่ยนโครงสร้างที่มีอยู่แล้ว แต่ไม่สามารถหาวิธีทำงานได้ พยายามเรียงความและรวมที่แตกต่างกันทุกอย่างล้มเหลว อ่าน ( ที่นี่และที่นี่ ) เกี่ยวกับการขยายตัวอักขระและอื่น ๆ ยังคงติดอยู่ นี่คือตัวอย่างรหัสที่ฉันใช้เพื่อทำซ้ำปัญหารู้สึกฟรีเพื่อแก้ไขและแนะนำสิ่งที่สามารถช่วยแก้ปัญหานี้ได้ CREATE TABLE testT ( [Default_Collation] [NVARCHAR] (50) COLLATE DATABASE_DEFAULT, [Latin1_General_CI_AS] [NVARCHAR] (50) COLLATE Latin1_General_CI_AS, …

4
เหตุใดการผสมการเรียงคอลัมน์ในฐานข้อมูลเดียวจึงถือว่าไม่ดี
มีสองเหตุผลที่ทำให้ฉันถามคำถามนี้: tSQLt เฟรมเวิร์กการทดสอบ T-SQL tSQLt พิจารณาว่าเป็นปัญหาของ"High Severity"เมื่อมีคอลัมน์ที่มีการจัดเรียงที่ไม่ใช่ค่าเริ่มต้น ผู้เขียนการทดสอบระบุสิ่งต่อไปนี้: ฉันไม่แนะนำให้ทุกคอลัมน์สตริงควรมีการเปรียบเทียบที่ตรงกับการเปรียบเทียบเริ่มต้นสำหรับฐานข้อมูล ฉันขอแนะนำว่าเมื่อมันแตกต่างกันควรมีเหตุผลที่ดี กระนั้นความรุนแรงของการทดสอบที่ล้มเหลวก็ถือว่าสูง การปรับใช้ Octopus ในขณะที่กำหนดค่าเซิร์ฟเวอร์การปรับใช้ Octopus การตั้งค่าล้มเหลวด้วยข้อผิดพลาด FATAL ในระหว่างการเริ่มต้นของ OctopusServer-instance บทความที่เกี่ยวข้องกับข้อผิดพลาดข้อความไม่ได้อธิบายว่าทำไมนี้เป็นความต้องการ แต่เพียงระบุว่ามันจะเป็นความจำเป็นสำหรับการใช้งานในอนาคตจากการรวมทั้งปลาหมึกรุ่น 3.8 ในฐานะที่เป็นกล่องด้านข้างแพคเกจ CI-tool ของ RedGate นั้นเป็นชุดDLM Automation Suiteรองรับการปรับใช้ที่มีการเปรียบเทียบที่หลากหลายโดยไม่มีการร้องเรียน คำแนะนำในการคงการเรียงคอลัมน์ทั้งหมดไว้เป็นค่าเริ่มต้นของฐานข้อมูลดูเหมือนจะเป็นแนวทางหรือแนวทางปฏิบัติที่ดีที่สุดสำหรับฉัน เหตุใดจึงถือว่าข้อผิดพลาดร้ายแรงบางรายการ

3
การรักษาตัวอักษรอาหรับบางตัวเหมือนกัน
ในภาษาอาหรับเรามีอักขระเช่นا (alef) และأ (alef with hamza) ผู้ใช้เขียนพวกเขาแทนกันและเราต้องการค้นหาพวกเขาสลับกันได้ SQL Server ถือว่าเป็นอักขระแยกต่างหาก ฉันจะทำให้ SQL ปฏิบัติต่อพวกเขาในลักษณะเดียวกันได้อย่างไร? ฉันคิดว่าจะแทนที่أ (alef กับ hamza) ด้วยا (alef) ที่ใส่เข้าไป แต่เรามีทางเลือกมากมายในภาษาอาหรับไม่ใช่แค่แค่ا (alef) และأ (alef กับ hamza) ฉันพยายามArabic_CI_ASแล้วArabic_CI_AIแต่นั่นก็ไม่ได้แก้ปัญหา นี่คือสคริปต์ในการสร้างปัญหาใหม่: CREATE TABLE [dbo].[TestTable] ( [ArabicChars] [nvarchar](50) NOT NULL, CONSTRAINT [PK_TestTable] PRIMARY KEY CLUSTERED ( [ArabicChars] ASC ) ) ON [PRIMARY]; INSERT INTO …

1
สั่งซื้อโดยการเปรียบเทียบตัวอักษรและตัวเลขผสมกัน
เราจำเป็นต้องทำการรายงานบางอย่างเกี่ยวกับค่าที่มักจะรวมสตริงของตัวเลขและตัวอักษรที่ต้องเรียงลำดับ 'ตามธรรมชาติ' สิ่งที่ต้องการเช่น "P7B18" หรือ "P12B3" @ สายอักขระส่วนใหญ่จะเป็นลำดับของตัวอักษรจากนั้นจึงสลับตัวเลข จำนวนของกลุ่มเหล่านี้และความยาวของแต่ละกลุ่มอาจแตกต่างกันไป เราต้องการเรียงลำดับตัวเลขเหล่านี้ตามลำดับตัวเลข เห็นได้ชัดว่าถ้าฉันจัดการค่าสตริงเหล่านั้นโดยตรงด้วยORDER BY"P12B3" จะมาก่อน "P7B18" เนื่องจาก "P1" เก่ากว่า "P7" แต่ฉันต้องการย้อนกลับเพราะ "P7" อยู่ก่อน "P12" ฉันยังต้องการที่จะทำการเปรียบเทียบช่วงเช่น@bin < 'P13S6'หรือบางอย่างเช่น ฉันไม่ต้องจัดการกับจำนวนจุดลอยตัวหรือจำนวนลบ; สิ่งเหล่านี้จะเป็นจำนวนเต็มที่ไม่ติดลบที่เรากำลังทำอยู่ ความยาวสตริงและจำนวนของเซกเมนต์อาจเป็นไปได้เองโดยไม่ จำกัด ขอบเขต ในกรณีของเราปลอกสตริงนั้นไม่สำคัญแม้ว่าจะมีวิธีการในการเปรียบเทียบการเรียงตัว แต่คนอื่น ๆ อาจพบว่ามีประโยชน์ ส่วนที่น่าเกลียดที่สุดของทั้งหมดนี้คือฉันต้องการที่จะทำทั้งการสั่งซื้อและการกรองช่วงในWHEREข้อ ถ้าฉันทำสิ่งนี้ใน C # มันจะเป็นงานที่ค่อนข้างง่าย: ทำการแยกวิเคราะห์เพื่อแยกอัลฟาจากตัวเลขใช้ IComparable และคุณก็ทำได้โดยทั่วไป แน่นอนว่า SQL Server ไม่ได้เสนอฟังก์ชั่นที่คล้ายกันอย่างน้อยที่สุดเท่าที่ฉันทราบ ใครรู้เทคนิคที่ดีในการทำงานนี้หรือไม่? มีความสามารถเล็กน้อยเผยแพร่ในการสร้างประเภท CLR ที่กำหนดเองที่ใช้ …
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.