คำแนะนำในการคงการเรียงคอลัมน์ทั้งหมดไว้เป็นค่าเริ่มต้นของฐานข้อมูลดูเหมือนจะเป็นแนวทางหรือแนวทางปฏิบัติที่ดีที่สุดสำหรับฉัน
คุณถูกต้องทั้งหมดที่นี่
เหตุใดจึงถือว่าข้อผิดพลาดร้ายแรงบางรายการ
ด้วยเหตุผลเดียวกับที่คุณมักจะได้ยิน / อ่านว่า "คุณไม่ควรใช้:"
- CURSORs
GOTO งบ- SQLCLR
WITH (NOLOCK)- ฯลฯ ฯลฯ ฯลฯ
คุณสมบัติ / ตัวเลือก / เทคโนโลยีบางอย่างนั้นซับซ้อนกว่าตัวอื่น ๆ และโดยทั่วไปต้องการความรู้เพิ่มเติมจากผู้ใช้เนื่องจากโอกาสในการเกิดปัญหาเมื่อใช้งานนั้นมีมากกว่าโอกาสที่จะไม่มีปัญหาใด ๆ ดังนั้นจึงเป็นการง่ายกว่าที่จะมีกฎทั่วไปที่ต่อต้านสิ่งต่าง ๆ เหล่านี้สำหรับประชากรทั่วไป ในความเป็นจริงเมื่อเขียนขึ้น "มาตรฐานการเข้ารหัส" ที่ทำงานผมมักจะมีกฎไปยังไม่เคยใช้เคอร์เซอร์ แต่ฉันใช้ด้วยตัวเองเพราะฉันรู้ว่า "เมื่อ" เพื่อใช้พวกเขาและ "วิธี" เพื่อใช้พวกเขาอย่างมีประสิทธิภาพ แต่คนที่เขียนข้อความค้นหาเป็นครั้งคราวไม่ควรคาดหวังว่าจะรู้ สิ่งนี้คล้ายกับ "อย่าแก้ไขรีจิสทรีเว้นแต่คุณจะรู้ว่าคุณกำลังทำอะไรอยู่" หรือกฎที่เราทำในฐานะผู้ปกครองสำหรับเด็ก (อายุน้อยมาก) ที่เราต้องบอกให้พวกเขาไม่ทำอะไรง่ายๆเพราะพวกเขาเป็น ไม่สามารถข้ามผ่านความซับซ้อนของเมื่อมันตกลงที่จะทำสิ่งที่เฉพาะเจาะจงหรือวิธีการเกี่ยวกับการทำมัน
ในกรณีของ Collations นี่เป็นหัวข้อที่ซับซ้อนและสับสนและคุณสามารถเรียกใช้ทั้งข้อผิดพลาดที่ยาก (สิ่งเหล่านี้เป็นปัญหา แต่น้อยกว่าปัญหาเนื่องจากมีความชัดเจนและง่ายต่อการแก้ไข) และเป็น "คี่" พฤติกรรมที่เป็นการยากที่จะอธิบายว่าทำไมสิ่งต่าง ๆ จึงแสดงออกมาอย่างที่เป็นอยู่ (เหตุใดบางรายการจึงถูกกรองหรือไม่ถูกกรองนอกความคาดหวังหรือเหตุใดการเรียงลำดับจึงกระทำนอกความคาดหมาย) และน่าเศร้าที่ดูเหมือนว่าจะมีข้อมูลที่ผิดจำนวนมากลอยอยู่รอบ ๆ ซึ่งทำให้เกิดความสับสนมากขึ้น จริง ๆ แล้วฉันกำลังทำงานในโครงการเพื่อเพิ่มความรู้ทั่วไปเกี่ยวกับการเรียงและการเข้ารหัส ฯลฯ และหวังว่าจะแก้ไขข้อมูลที่ผิดและตำนาน แต่ยังไม่พร้อมที่จะเผยแพร่
สำหรับการจัดเรียงคุณต้องใช้สิ่งที่เหมาะสมที่สุดสำหรับกรณีศึกษาทางธุรกิจ แนวคิดของการไม่รวม Collations ในตารางหรือฐานข้อมูลเป็นวิธีการเริ่มต้น แต่ถ้าคุณดู Collations ที่ใช้สำหรับคอลัมน์ต่าง ๆ ของมุมมองแคตตาล็อกระบบคุณจะสังเกตเห็นการใช้ Collation ที่หลากหลาย ดังนั้นฉันจึงเห็นด้วยกับข้อความอ้างอิงหลักในคำถามที่ว่าหากการเปรียบเทียบจะแตกต่างกันมันควรจะตั้งใจ แต่ไม่มีอะไรผิดปกติกับมัน
เกี่ยวกับเรื่องนี้จากคำถาม (เน้นที่เพิ่ม):
ขณะกำหนดค่า Octopus Deploy Server การตั้งค่าล้มเหลวด้วยข้อผิดพลาด FATAL ในระหว่างการเริ่มต้นของ OctopusServer-instance บทความที่เกี่ยวข้องกับข้อความแสดงข้อผิดพลาดไม่ได้อธิบายว่าทำไมจึงเป็นข้อกำหนด
ฉันตรวจสอบหน้าเอกสารที่เชื่อมโยงและมันไม่ได้อธิบายว่าทำไมมันถึงเป็นข้อกำหนด ฉันได้คัดลอกข้อมูลที่เกี่ยวข้องจากเอกสารด้านล่างแล้ว:
คุณต้องให้แน่ใจว่าคุณยังเปลี่ยนการเรียงของวัตถุทั้งหมดในฐานข้อมูล Octopus มิฉะนั้นข้อผิดพลาดสามารถเกิดขึ้นได้เมื่อแก้ไขฐานข้อมูลในระหว่างการอัพเกรดรุ่น Octopus วัตถุใหม่ที่สร้างขึ้นจะใช้การจัดเรียงที่ปรับปรุงแล้วและเมื่อพยายาม (เช่น) ทำการรวม SQL ระหว่างวัตถุเหล่านี้และวัตถุที่มีอยู่โดยใช้การเรียงแบบดั้งเดิมข้อผิดพลาดการจับคู่การเปรียบเทียบอาจเกิดข้อผิดพลาด
พวกเขากำลังบอกว่ารหัสของพวกเขาในฐานข้อมูล Octopus มีการเข้าร่วมระหว่างคอลัมน์สตริงและน่าจะมีรหัสใหม่ที่นำมาใช้ในการอัพเกรดในอนาคตที่มี JOIN เพิ่มเติมในคอลัมน์สตริงใหม่ คอลัมน์ใหม่ไม่ว่าจะผ่านCREATE TABLEหรือALTER TABLE ... ADDจะได้รับการกำหนดการเรียงหน้าเริ่มต้นของฐานข้อมูลหากCOLLATEไม่ได้ระบุคำหลักสำหรับคอลัมน์สตริงใหม่ และเข้าร่วมระหว่างคอลัมน์สตริงที่ไม่มี Collation เดียวกันจะสร้างข้อผิดพลาด Collation ที่ไม่ตรงกัน พวกเขาดูเหมือนจะอนุญาตให้ผู้ใช้เลือก Collation ของตนเอง (อาจจะรองรับตำแหน่งที่ตั้งต่าง ๆ ) เนื่องจากพวกเขาพูดที่ด้านบนสุดว่าข้อกำหนดเพียงอย่างเดียวคือ Collation นั้นไม่คำนึงถึงขนาดตัวพิมพ์ และเนื่องจากการจัดเรียงของฐานข้อมูลที่รหัสของพวกเขาอาศัยอยู่ไม่ได้รับประกันว่าจะเหมือนกันพวกเขาไม่สามารถใช้COLLATEคำหลักเพื่อบังคับให้มีการเรียงหน้าเดียวกันในคอลัมน์สตริงใหม่ทั้งหมด (ดีพวกเขาสามารถทำได้ในทางเทคนิค SQL ไม่ใช่เรื่องง่ายที่จะจัดการเมื่อสร้างสคริปต์อัพเดต) หากพวกเขาสามารถใช้COLLATEคำหลักได้พวกเขาก็สามารถทำได้หลีกเลี่ยงการให้ Collation เริ่มต้นของฐานข้อมูลแตกต่างจากคอลัมน์สตริง ที่จะหลีกเลี่ยงข้อผิดพลาด "Collation mismatch" ที่ยาก แต่จะยังคงเปิดความเป็นไปได้ของการดำเนินการเปรียบเทียบที่เกี่ยวข้องกับหนึ่งในคอลัมน์สตริงเหล่านั้นและสตริงตัวอักษรหรือตัวแปรที่ทำให้เกิดพฤติกรรม "แปลก" เนื่องจากจะใช้ Collation ของคอลัมน์ไม่ใช่ฐานข้อมูล การตรวจทาน แน่นอนว่าอาจเป็นพฤติกรรมที่คาดหวังได้เป็นอย่างดี แต่เนื่องจากนี่เป็นแอปของบุคคลที่สามพฤติกรรมควรเป็นสิ่งที่พวกเขาตั้งใจจะมีมากกว่า 50/50 โอกาสระหว่าง a) สิ่งที่ผู้ใช้ต้องการ (หรือไม่คัดค้าน) และ b) สิ่งที่ผู้ใช้พิจารณาข้อบกพร่อง (และจากนั้น ทำให้เสียเวลาสนับสนุนของผู้ขายในการไล่ล่าห่านและ / หรือบล็อกเกี่ยวกับซอฟต์แวร์ของพวกเขาว่าเป็นบั๊กกี้)