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

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

2
สร้างฐานข้อมูล MySQL ด้วย charset UTF-8
ฉันใหม่กับ MySQL และฉันต้องการที่จะรู้ว่า: ฉันจะสร้างฐานข้อมูลด้วยชุดอักขระutf-8เช่นเดียวกับที่ฉันทำใน navicat ได้อย่างไร create mydatabase; ... ดูเหมือนว่าจะใช้ชุดอักขระเริ่มต้นบางประเภท
142 mysql  collation  utf-8 

4
วิธีการเปลี่ยนการเปรียบเทียบของ SQL Server
ฉันจะเปลี่ยนการเปรียบเทียบค่าเริ่มต้นของ SQL Server 2008 R2 Express สำหรับเซิร์ฟเวอร์ทั้งหมดและฐานข้อมูลเฉพาะได้อย่างไร มีวิธีการใช้อินเทอร์เฟซภาพของ SQL Server Management Studio หรือไม่? ในหน้าต่างคุณสมบัติเซิร์ฟเวอร์ (และในหน้าต่างคุณสมบัติฐานข้อมูลที่สอดคล้องกัน) คุณสมบัตินี้ไม่สามารถแก้ไขได้

1
ทำไม PostgreSQL ของฉันเรียงตามตัวพิมพ์เล็ก - ใหญ่
ฉันมี Postgres 9.4.4 ทำงานบน Debian และฉันได้รับORDER BYพฤติกรรมดังต่อไปนี้: veure_test=# show LC_COLLATE; lc_collate ------------- en_US.UTF-8 (1 row) veure_test=# SELECT regexp_split_to_table('D d a A c b CD Capacitor', ' ') ORDER BY 1; regexp_split_to_table ----------------------- a A b c Capacitor CD d D (8 rows) และuname -a: Linux ---- 3.2.0-4-amd64 #1 SMP Debian …

3
ฉันควรเลือกชุดเปรียบเทียบใดสำหรับเว็บไซต์ภาษา muiti
การเปรียบเทียบมีผลกับความเร็วการสืบค้นหรือไม่? ขนาดของตารางเปลี่ยนไปตามการเปรียบเทียบหรือไม่? หากฉันต้องการสร้างเว็บไซต์ที่ต้องรองรับภาษาที่เป็นไปได้ทั้งหมด (ลองทำเช่น Google) ซึ่งจะเป็นการเปรียบเทียบที่แนะนำหรือไม่ ฉันจะต้องเก็บตัวอักษรเช่น日本語การค้นหาของฉันในเว็บไซต์จะต้องส่งคืนsomethingค่าsóméthíngอินพุตนั้นจะต้องตรงตามตัวพิมพ์เล็กและตัวพิมพ์ใหญ่ ฉันจะรู้ได้อย่างไรว่าทางเลือกใดที่ดีที่สุด? การเปรียบเทียบชุดไหนที่เหมาะกับกรณีนี้มากที่สุด

2
LC_CTYPE มีผลกระทบอะไรกับฐานข้อมูล PostgreSQL
ดังนั้นฉันมีเซิร์ฟเวอร์ Debian ไม่กี่เครื่องที่มี PostgreSQL อยู่ ในอดีตเซิร์ฟเวอร์เหล่านั้นและ PostgreSQL มีการแปลเป็นภาษาละตินด้วยชุดอักขระ Latin 9 และย้อนกลับไปได้ ตอนนี้เราต้องจัดการกับสิ่งต่างๆเช่นโปแลนด์กรีกหรือจีนดังนั้นการเปลี่ยนมันจึงกลายเป็นปัญหาที่กำลังเติบโต เมื่อฉันพยายามสร้างฐานข้อมูล UTF8 ฉันได้รับข้อความ: ข้อผิดพลาด: การเข้ารหัส UTF8 ไม่ตรงกับรายละเอียดสถานที่ fr_FR: การตั้งค่า LC_CTYPE ที่เลือกต้องใช้การเข้ารหัส LATIN9 ไม่กี่ครั้งที่ฉันได้ทำการวิจัยเกี่ยวกับเรื่องนี้กับเพื่อนเก่าของ Google และสิ่งที่ฉันพบคือขั้นตอนที่ซับซ้อนเช่นการอัปเดต Debian LANG, คอมไพล์ PostgreSQL ด้วยชุดอักขระที่ถูกต้องแก้ไขLC_ตัวแปรระบบทั้งหมดและโซลูชันที่ไม่ชัดเจนอื่น ๆ ดังนั้นในขณะนี้เราจึงปล่อยให้ปัญหานี้เกิดขึ้น เมื่อเร็ว ๆ นี้มันกลับมาอีกครั้งชาวกรีกต้องการสิ่งของและละติน 9 ไม่ต้องการ และในขณะที่ฉันกำลังตรวจสอบปัญหานี้อีกครั้งเพื่อนร่วมงานคนหนึ่งมาหาฉันและพูดว่า "ไม่นะมันง่ายดูสิ" เขาไม่ได้ทำการแก้ไขอะไรเลยไม่ได้ใช้กลอุบายเขาแค่ทำแบบสอบถาม SQL นี้: CREATE DATABASE my_utf8_db WITH ENCODING='UTF8' OWNER=admin …

1
ฉันจะตั้งค่าสตริง SQL Unicode / NVARCHAR ของเซิร์ฟเวอร์เป็นอีโมจิหรืออักขระเสริมได้อย่างไร
ฉันต้องการตั้งค่าตัวแปรสตริง Unicode เป็นอักขระเฉพาะตามจุดโค้ด Unicode ฉันต้องการใช้จุดรหัสเกิน 65535 แต่ฐานข้อมูล SQL Server 2008 R2 SQL_Latin1_General_CP1_CI_ASมีการเปรียบเทียบของ ตามเอกสาร NCHAR ไมโครซอฟท์ที่NCHARฟังก์ชั่นใช้เวลาจำนวนเต็มดังนี้ integer_expression เมื่อการเรียงของฐานข้อมูลไม่มีค่าสถานะอักขระเสริม (SC) นี่เป็นจำนวนเต็มบวกตั้งแต่ 0 ถึง 65535 (0 ถึง 0xFFFF) หากระบุค่านอกช่วงนี้ NULL จะถูกส่งคืน สำหรับข้อมูลเพิ่มเติมเกี่ยวกับอักขระเสริมดูที่การเรียงหน้าและการสนับสนุน Unicode เมื่อการเรียงฐานข้อมูลสนับสนุนแฟล็กอักขระเสริม (SC) นี่เป็นจำนวนเต็มบวกตั้งแต่ 0 ถึง 1114111 (0 ถึง 0x10FFFF) หากระบุค่านอกช่วงนี้ NULL จะถูกส่งคืน ดังนั้นรหัสนี้: SELECT NCHAR(128512); ส่งคืนNULLในฐานข้อมูลนี้ ฉันต้องการให้ส่งคืนเช่นนี้: SELECT N'😀'; ฉันจะตั้งค่าตัวแปรสตริง …

3
วิธีเลือกการเปรียบเทียบสำหรับฐานข้อมูลสากล?
ฉันกำลังออกแบบฐานข้อมูลที่จะเก็บข้อมูลในภาษาต่าง ๆ (โดยใช้ UTF-8) ดังนั้นฉันคิดว่าวิธีที่ดีที่สุดในการแสดงผลลัพธ์ของแบบสอบถามคือการสั่งซื้อตามภาษาของผู้ใช้ในระหว่างการสืบค้น ( เพราะมีมากกว่าหนึ่ง วิธีที่ถูกต้องในการทำเช่นนั้น ) ดังนี้: SELECT a < b COLLATE "de_DE" FROM test1; สมมติว่านี่เป็นวิธีที่ถูกต้องในการทำงานกับข้อมูลระหว่างประเทศซึ่งเป็นการเปรียบเทียบที่ดีที่สุดสำหรับฐานข้อมูลตัวเอง? เอกสาร PostgreSQL บอกว่า : การเปรียบเทียบทั้ง C และ POSIX ระบุพฤติกรรม "ดั้งเดิม C" ซึ่งมีเพียงตัวอักษร ASCII "A" ถึง "Z" เท่านั้นที่จะถือว่าเป็นตัวอักษรและการเรียงลำดับจะกระทำอย่างเคร่งครัดโดยค่าไบต์รหัสตัวอักษร ฉันคิดว่านี่เป็นตัวเลือกที่ดีที่สุดในกรณีนี้หรือฉันผิด (คำถามโบนัส: มันช้าเกินไปที่จะเลือกการเรียงในแบบสอบถามหรือไม่)

4
มีอะไรขึ้นอยู่กับการเรียงคอลัมน์บางคอลัมน์ใน sys.database?
ฉันพยายามเรียกใช้UNPIVOTคอลัมน์ต่างๆที่มีอยู่ในsys.databasesSQL Server เวอร์ชันต่างๆตั้งแต่ปี 2005 ถึง 2012 ความUNPIVOTล้มเหลวพร้อมกับข้อความแสดงข้อผิดพลาดต่อไปนี้: ข่าวสารเกี่ยวกับ 8167 ระดับ 16 สถานะ 1 สาย 48 ประเภทของคอลัมน์ "CompatibilityLevel" ขัดแย้งกับประเภทของคอลัมน์อื่น ๆ ที่ระบุในรายการ UNPIVOT T-SQL: DECLARE @dbname SYSNAME; SET @dbname = DB_NAME(); SELECT [Database] = unpvt.DatabaseName , [Configuration Item] = unpvt.OptionName , [Configuration Value] = unpvt.OptionValue FROM ( SELECT DatabaseName = name , …

2
เน้นการเรียงที่ละเอียดอ่อน
ทำไมทั้งสองSELECTคำสั่งจึงส่งผลให้เรียงลำดับที่แตกต่างกัน USE tempdb; CREATE TABLE dbo.OddSort ( id INT IDENTITY(1,1) PRIMARY KEY , col1 NVARCHAR(2) , col2 NVARCHAR(2) ); GO INSERT dbo.OddSort (col1, col2) VALUES (N'e', N'eA') , (N'é', N'éB') , (N'ë', N'ëC') , (N'è', N'èD') , (N'ê', N'êE') , (N'ē', N'ēF'); GO SELECT * FROM dbo.OddSort ORDER BY col1 …

2
การเปรียบเทียบแบบ case-insensitive ทำงานอย่างไร
ชนิดการเรียงข้อมูลเริ่มต้นใน SQL Server อนุญาตสำหรับการทำดัชนีกับสตริงที่ไม่คำนึงถึงขนาดตัวพิมพ์ แต่เคสของข้อมูลยังคงอยู่ มันใช้งานได้จริงอย่างไร? ฉันกำลังมองหาถั่วและโบลต์บิตและไบต์จริง ๆ หรือแหล่งข้อมูลที่ดีที่อธิบายรายละเอียด create table casetest (fruitnames nvarchar(50) not null); create unique index IX_fruitnames on casetest(fruitnames); insert into casetest values ('apples'); insert into casetest values ('Pears'); -- this insert fails insert into casetest values ('pears'); -- this yields 'Pears' as a result select * …

2
ไม่สามารถอัปเดต“ CO2” เป็น“ CO₂” ในแถวตาราง
รับตารางนี้: CREATE TABLE test ( id INT NOT NULL, description NVARCHAR(100) COLLATE Modern_Spanish_CI_AS NOT NULL ); INSERT INTO test (id, description) VALUES (1, 'CO2'); ฉันรู้ว่าฉันไม่สามารถแก้ไขปัญหาเกี่ยวกับการพิมพ์ได้: SELECT * FROM test WHERE id = 1; UPDATE test SET description = 'CO₂' WHERE id = 1; SELECT * FROM test WHERE id = …

2
ฉันควรใช้การเปรียบเทียบชุดใดในฮีบรูในพระคัมภีร์ไบเบิล?
ฉันควรใช้การเปรียบเทียบ SQL Server สำหรับภาษาฮีบรูในพระคัมภีร์ไบเบิลอย่างไร ฐานข้อมูลที่อยู่ระหว่างการพิจารณาจำเป็นต้องมีการกำกับกำกับ (เช่นเสียงสระ, เสียง, เสียงแหลม, ฯลฯ )

2
DBMS ใดมีการเปรียบเทียบที่เป็นทั้งตัวพิมพ์เล็กและตัวพิมพ์ใหญ่และตัวพิมพ์เล็ก
หมายเหตุคำถามนี้คือผู้ขาย / รุ่นที่ไม่เชื่อเรื่องพระเจ้า ดูเหมือนว่าฉันในฐานะวิทยากร (ผู้พิมพ์ดีดนักเขียน) ของภาษาอังกฤษมีเหตุผลที่คาดว่าจะได้คำที่ถูกต้อง แต่ไม่จำเป็นต้องมีสำเนียงที่ถูกต้องไปในทิศทางที่ถูกต้อง: ตามที่ฉันรำพึงใน tete-a-tete กับ Chloe the maitre d'hotel ที่ร้านอาหาร Champs-Elysees ในขณะที่รอ garcon เพื่อดึง jalapeno sateed ของฉัน ... คุณได้รับความคิดด้วยสิ่งนั้น ดังนั้นวันนี้ฉันคิดว่าฉันต้องการเงื่อนไขการค้นหาเพื่อใช้การเปรียบเทียบที่คำนึงถึงตัวพิมพ์เล็กและตัวพิมพ์เล็ก แต่เน้นเรื่องเล็ก แต่ไม่สามารถหาได้ มีเหตุผลที่ดีสำหรับสิ่งนี้หรือเป็นเพียงกรณีการใช้งานที่หายาก? นี่คือตัวอย่างของเอกสารบางอย่างที่ฉันดู (คิดว่าผู้ขาย / รุ่นไม่เชื่อเรื่องพระเจ้า): ชื่อเรียงเซิร์ฟเวอร์ SQL (SQL Server 2008 R2)

1
ทำไมคุณต้องจัดทำดัชนี text_pattern_ops ในคอลัมน์ข้อความ
วันนี้ฐานข้อมูลเจ็ดแห่งในเจ็ดสัปดาห์แนะนำให้ฉันรู้จักกับดัชนีผู้ดำเนินการต่อ คุณสามารถจัดทำดัชนีสตริงสำหรับรูปแบบที่ตรงกับแบบสอบถามก่อนหน้านี้โดยสร้างtext_pattern_opsดัชนีระดับผู้ประกอบการตราบใดที่มีการจัดทำดัชนีเป็นตัวพิมพ์เล็ก CREATE INDEX moves_title_pattern ON movies ( (lower(title) text_pattern_ops); เราใช้text_pattern_opsเพราะชื่อเป็นข้อความประเภท หากคุณจำเป็นต้องดัชนี varchars, ตัวอักษรหรือชื่อที่ใช้ปฏิบัติการที่เกี่ยวข้อง: varchar_pattern_ops, และbpchar_pattern_opsname_pattern_ops ฉันพบตัวอย่างที่ทำให้สับสนจริงๆ ทำไมการทำเช่นนี้จึงมีประโยชน์ หากคอลัมน์เป็นข้อความประเภทจะไม่ถูกแปลงเป็นประเภทอื่น (varchar, char, name) เป็นข้อความก่อนที่จะใช้เป็นค่าการค้นหาหรือไม่ ดัชนีนั้นมีพฤติกรรมแตกต่างจากที่ใช้ตัวดำเนินการเริ่มต้นอย่างไร CREATE INDEX moves_title_pattern ON movies (lower(title));

2
การย้ายจาก SQL 2005 [SQL_Latin1_General_CP1_CI_AS] เป็น 2008 - ฉันจะสูญเสียคุณสมบัติใด ๆ โดยใช้ 'ความเข้ากันได้ย้อนหลัง' หรือไม่
เรากำลังย้ายจาก SQL 2005 [อินสแตนซ์และฐานข้อมูลมีการเปรียบเทียบSQL_Latin1_General_CP1_CI_AS] เป็น SQL 2008 [ซึ่งเป็นค่าเริ่มต้นไปยังLatin1_General_CI_AS] ฉันเสร็จสิ้นการติดตั้ง SQL 2008 R2 และใช้การLatin1_General_CI_ASเปรียบเทียบค่าเริ่มต้นแล้วโดยที่การคืนค่าฐานข้อมูลยังคงเปิดอยู่SQL_Latin1_General_CP1_CI_ASเปรียบเทียบกับการฟื้นฟูของฐานข้อมูลที่ยังคงอยู่ในปัญหาที่ยกเว้นเกิดขึ้น - ตาราง #temp ซึ่งใน Latin1_General_CI_ASขณะที่ฐานข้อมูลอยู่ SQL_Latin1_General_CP1_CI_ASและนี่คือที่ฉันอยู่ตอนนี้ - ฉันต้องการคำแนะนำเกี่ยวกับข้อผิดพลาดตอนนี้โปรด ในการติดตั้ง SQL 2008 R2 ฉันมีตัวเลือกในการติดตั้งให้ใช้โดย'SQL Collation, used for backwards compatibility'ที่ฉันมีตัวเลือกให้เลือกการเรียงหน้าเดียวกันกับฐานข้อมูลปี 2005:SQL_Latin1_General_CP1_CI_AS2005: สิ่งนี้จะทำให้ฉันไม่มีปัญหากับ #temp tables แต่มีข้อผิดพลาดหรือไม่? ฉันจะสูญเสียฟังก์ชันการทำงานหรือคุณลักษณะใด ๆ โดยไม่ใช้การจัดเรียง "ปัจจุบัน" ของ SQL 2008 หรือไม่ สิ่งที่เกี่ยวกับเมื่อเราย้าย (เช่นใน 2 ปี) จาก 2008 …

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.