ใครสามารถแนะนำมาตรฐานการเข้ารหัสสำหรับ TSQL ได้บ้าง


9

เรามีมาตรฐานการเข้ารหัสสำหรับรหัส. Net ของเรามานานและดูเหมือนว่าจะมีแหล่งข้อมูลที่มีชื่อเสียงหลายแห่งสำหรับแนวคิดเกี่ยวกับวิธีการปรับใช้ซึ่งพัฒนาขึ้นตามกาลเวลา

ฉันต้องการที่จะสามารถรวบรวมมาตรฐานบางอย่างสำหรับ SQL ที่เขียนขึ้นเพื่อใช้งานโดยผลิตภัณฑ์ของเรา แต่ดูเหมือนจะไม่มีทรัพยากรใด ๆ อยู่ที่ฉันทามติสำหรับสิ่งที่กำหนด SQL ที่เขียนได้ดี?


1
Pinal เดฟมีรายชื่อของมาตรฐานการเข้ารหัสบนเว็บไซต์ของเขา พวกเขาดูเหมือนพื้นฐานที่เป็นธรรมสำหรับชุดมาตรฐาน
จะ

1
มีเป็นคำถามที่เกี่ยวข้องในดังนั้น
Scott Whitlock

1
@Scott ที่ครอบคลุมเฉพาะการระบุ ไม่มีอะไรเกี่ยวกับการตั้งชื่อการใช้เคอร์เซอร์ / ขั้นตอนการจัดเก็บ / ตัวเลือกประเภทข้อมูลหรืออะไรก็ตามที่ส่งผลกระทบต่อคุณภาพของรหัสจริง ๆ ...
Rowland Shaw

1
ดังนั้นทำไมฉันบอกว่ามันเป็น "ที่เกี่ยวข้อง" ไม่ใช่ "ซ้ำกัน"
Scott Whitlock

คำตอบ:


6

จากประสบการณ์ของฉันสิ่งสำคัญที่ฉันต้องการคือ:

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

  • การสร้างทั้งหมดควรมีการดรอป (เงื่อนไขบนวัตถุที่มีอยู่) เป็นส่วนหนึ่งของไฟล์ คุณอาจต้องการรวมสิทธิ์การอนุญาตตามที่คุณต้องการ

  • เลือกอัปเดตแทรกและลบควรวางชื่อคอลัมน์หนึ่งชื่อตารางหนึ่งชื่อและหนึ่งตำแหน่งที่ส่วนคำสั่ง / คำสั่งตามข้อต่อบรรทัดเพื่อให้พวกเขาสามารถแสดงความคิดเห็นได้อย่างง่ายดายในแต่ละครั้งในระหว่างการแก้จุดบกพร่อง

  • คำนำหน้าสำหรับประเภทวัตถุโดยเฉพาะอย่างยิ่งที่พวกเขาอาจจะสับสน (ดังนั้น v สำหรับการดูเป็นสิ่งที่สำคัญที่สุด) ไม่แน่ใจว่ายังใช้อยู่หรือไม่ แต่จะไม่มีประสิทธิภาพสำหรับโพรซีเดอร์ที่เก็บไว้นอกเหนือจากโพรซีเดอร์ระบบเพื่อเริ่ม sp_ น่าจะเป็นแนวทางปฏิบัติที่ดีที่สุดในการสร้างความแตกต่างให้กับพวกเขาต่อไป usp_ เป็นสิ่งที่ฉันใช้ล่าสุด

  • มาตรฐานที่ระบุว่าชื่อของทริกเกอร์ควรระบุว่าเป็นชื่อสำหรับ update / insert / delete และตารางที่ใช้ ฉันไม่มีมาตรฐานที่ต้องการ แต่นี่เป็นข้อมูลที่สำคัญและต้องค้นหาได้ง่าย

  • มาตรฐานการเป็นเจ้าของวัตถุใน SQL Server รุ่นก่อนหน้าหรือ schema ที่ควรมีอยู่ในปี 2005 และใหม่กว่า มันคือการเรียกของคุณมันคืออะไร แต่คุณไม่ควรคาดเดาว่าใครเป็นเจ้าของ / ที่ที่มันอาศัยอยู่) และถ้าเป็นไปได้ควรรวมสคีมา / เจ้าของไว้ในสคริปต์ CREATE เพื่อลดโอกาสที่จะเกิดความผิดพลาด

  • ตัวบ่งชี้ว่าทุกคนที่ใช้ SELECT * จะถูกสร้างขึ้นเพื่อดื่มไพน์จากปัสสาวะของพวกเขาเอง

  • เหตุผลที่ดีจริงๆ (ซึ่งไม่รวมถึงความเกียจคร้านในส่วนของคุณ) มีบังคับและรักษาความสัมพันธ์กับคีย์หลัก / คีย์ต่างประเทศตั้งแต่ต้น นี่คือหลังจากที่ฐานข้อมูลเชิงสัมพันธ์ทั้งหมดไม่ได้เป็นไฟล์แบนและบันทึกกำพร้าจะทำให้การสนับสนุนชีวิตของคุณในบางจุด นอกจากนี้โปรดทราบว่าถ้าคุณไม่ทำตอนนี้ฉันสามารถสัญญากับคุณได้ว่าคุณจะไม่สามารถนำไปใช้งานได้หลังจากเหตุการณ์เพราะมันเป็น 10 เท่าของการทำงานเมื่อคุณมีข้อมูล (ซึ่งจะเมาเล็กน้อยเพราะคุณไม่เคยบังคับใช้ ความสัมพันธ์ที่เหมาะสม)

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

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

แก้ไข: การแก้ไขสองรายการ - รวมถึงสกีมาในส่วนการเป็นเจ้าของลบเคล็ดลับที่ผิดพลาดเกี่ยวกับการนับ (*) - ดูความคิดเห็นด้านล่าง


1
ตัวเลือกแปลก ๆ ... "เลือก COUNT (*)" ไม่ดีใช่ไหม เคยได้ยิน schemas (ซึ่งไม่เหมือนกับเจ้าของ)? คนอื่น ๆ ของคุณเป็นสิ่งที่ดี
gbn

1
@ Jon Hopkins - ฉันรู้ว่าทำไมมันไม่ดีที่จะใช้ SELECT * คงจะดีมากถ้าคุณบอกว่าทำไมการเลือก SELECT COUNT (*) ถึงไม่ดี
k25

1
@gbn @ k25 - ไม่กี่ปีหลัง (2002?) ฉันมี DBA ที่ร้อนแรงมากในการนับ (*) แต่ Googling ตอบคำถามของคุณดูเหมือนว่านี่จะล้าสมัยแล้ว (ถ้าเคยเป็นจริง) sqlservercentral.com/articles/Performance+Tuning/adviceoncount/… (ต้องลงทะเบียน) เธอเป็น Oracle DBA เป็นหลักดังนั้นจึงอาจเป็นปัญหาของแท้ที่นั่นซึ่งเธอสันนิษฐานว่าเป็นปัญหาสำหรับตัวเพิ่มประสิทธิภาพ SQL
Jon Hopkins

1
@gbn - ใช่ฉันมีแม้ว่าฉันจะค่อนข้างถนัดตั้งแต่พวกเขาได้รับการแนะนำดังนั้นปฏิกิริยาอัตโนมัติของฉันคือผู้ใช้ ฉันจะอัปเดตคำตอบเพื่อให้ครอบคลุม schema
Jon Hopkins

1
@gbn, @ k25 - ยิ่งขุดจำนวนมากขึ้น (*) เห็นได้ชัดว่านี่เป็นปัญหาใน Oracle 7 และก่อนหน้านี้ได้รับการแก้ไขใน 8i ขึ้นไป ไม่ชัดเจนว่าเคยเป็นปัญหาใน SQL Server แต่ไม่แน่นอนอีกต่อไป DBA ของฉันเก่าเกินไป
Jon Hopkins

3

ดูเหมือนจะไม่มีทรัพยากรใด ๆ อยู่ที่นั่นบนฉันทามติสำหรับสิ่งที่กำหนด SQL ที่เขียนได้ดี

นั่นเป็นเพราะไม่มีฉันทามติ เช่นเดียวกับตัวอย่างฉันจะได้คำตอบที่แตกต่างกันอย่างน้อยครึ่งรายการในรายการของ Jon Hopkins และจากจำนวนรายละเอียดในรายการของเขามันเป็นการเดาที่ปลอดภัยที่เราทั้งคู่ทำงานกับฐานข้อมูลเพื่อหาเลี้ยงชีพ

ที่กล่าวว่ามาตรฐานการเข้ารหัสยังคงเป็นสิ่งที่ดีและมาตรฐานที่ทุกคนในทีมเข้าใจและเห็นด้วยเป็นสิ่งที่ดีกว่าเพราะมาตรฐานนั้นจะมีแนวโน้มมากกว่า


1
+1 ฉันคิดว่าสิ่งที่สำคัญที่สุดคือคุณมีความมั่นคงในทีมของคุณ
Dean Harding

1
จากสิ่งที่คุณจะทำแตกต่างกันอย่างไร พวกเขาส่วนใหญ่เป็นเรื่องของรสนิยม (รูปแบบและอื่น ๆ ) หรือมีข้อผิดพลาด "ยาก"?
Jon Hopkins

1
@ จอน: ไม่มีข้อผิดพลาดยากเพียงแค่สิ่งที่เป็นอัตนัยเช่นชื่อตารางเอกพจน์ความเกลียดชังของทริกเกอร์ ฯลฯ .. BTW, "SELECT *" เป็นเรื่องปกติใน "EXISTS ()"
Larry Coleman

1
ตัวอย่างที่ยุติธรรม (และฉันใช้กับ EXISTS และไม่บังคับให้ฉันดื่มปัสสาวะ)
Jon Hopkins

1

นอกจากคำตอบของ Jon Hopkins '...

  • แยกภายในกับวัตถุภายนอก

    • IX, UQ, TRG, CK ฯลฯ สำหรับข้อ จำกัด และดัชนี ฯลฯ
    • ตัวพิมพ์เล็กหรือ CapsCase สำหรับไคลเอ็นต์ที่หันเข้าหาเช่น uspThing_Add
  • สำหรับวัตถุภายในทำให้ชัดเจนถ้า "ไม่ใช่ค่าเริ่มต้น"

    • UQ = ข้อ จำกัด ที่ไม่ซ้ำกัน
    • UQC = ข้อ จำกัด ของคลัสเตอร์ที่ไม่ซ้ำกัน
    • PK = คีย์หลัก
    • PKN = คีย์หลักแบบไม่คลัสเตอร์
    • ทรงเครื่อง = ดัชนี
    • IXU = ดัชนีที่ไม่ซ้ำ
    • IXC = ดัชนีคลัสเตอร์
    • IXCU หรือ IXUC = ดัชนีคลัสเตอร์ที่ไม่ซ้ำกัน
  • ใช้สกีมาเพื่อทำให้การตั้งชื่อ + สิทธิ์ทำได้ง่ายขึ้น ตัวอย่าง:

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