มีเหตุผลที่จะใช้ชื่อตารางตัวย่ออย่างยิ่งหรือไม่?

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

ชื่อตารางเป็นเหมือน aptrx (ธุรกรรมบัญชีเจ้าหนี้) และ apmaster_all (อยากรู้อยากเห็นนี่คือตารางผู้ขาย) มันเป็นฐานข้อมูลที่ซับซ้อนอย่างยิ่งดังนั้นฉันจึงสงสัยว่ามีตรรกะใด ๆ ในการประชุมหรือว่ามันเป็นแค่การงงงวยอย่างจงใจหรืออย่างอื่น

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

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

ผลกระทบที่สำคัญกว่าของชื่อตารางสั้น ๆ คือมันยากที่จะทำงานด้วย ฉันก็ต้องรักษาคีมาฐานข้อมูลองค์กรด้วยชื่อสั้น ๆ ไม่มีเหตุผลที่ดีที่จะมีชื่อตารางสั้น ๆ ความง่ายในการบำรุงรักษาสำคัญกว่าการทำให้งงงวยหรือนิสัย DOS เก่าทุกครั้ง

ฉันรู้สึกว่ามีสองสิ่งที่ยังจำเป็นต้องพูดหรือทำอย่างละเอียด:

1. การตั้งชื่อสิ่งต่าง ๆนั้นไม่สำคัญอย่างที่คิด

   วิทยาศาสตร์คอมพิวเตอร์มีปัญหาเพียงสองปัญหาเท่านั้น: การทำให้แคชใช้ไม่ได้และการตั้งชื่อ ฟิลคาร์ลตัน

2. ในขณะที่ชื่อที่ไม่มีความหมายสั้น ๆ จะไม่ดีอยู่เสมอชื่อยาวนั้นไม่ดีเสมอไป - สมองของเรามี inbuilt tl; dr threshold ที่ต่ำอย่างน่าประหลาดใจ 30 ตัวอักษรมักจะเพียงพอ แต่ฉันชอบ RDBMS เพื่อให้เหมาะกับกรณีพิเศษเมื่อมันไม่ใช่ (และเช่นเดียวกับในภาษาชื่อที่ยาวกว่าจะมีประโยชน์มากกว่าสำหรับสิ่งที่เราไม่ได้พูดถึงบ่อย ๆ เช่นชื่อข้อ จำกัด และ ชื่อที่สั้นกว่าจะมีประโยชน์มากกว่าสำหรับตารางที่เราสืบค้นตลอดเวลา)

ฉันมักจะถูกล่อลวงให้ใช้เวลาน้อยเกินไปในการเลือกชื่อและจะเสียใจในภายหลังหากฉัน - การเปลี่ยนชื่อเกิดขึ้นเพียงเล็กน้อยเท่านั้น

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

ชื่อตารางเป็นเหมือน aptrx (ธุรกรรมบัญชีเจ้าหนี้) และ apmaster_all (อยากรู้อยากเห็นนี่คือตารางผู้ขาย) มันเป็นฐานข้อมูลที่ซับซ้อนอย่างยิ่งดังนั้นฉันจึงสงสัยว่ามีตรรกะใด ๆ ในการประชุมหรือว่ามันเป็นแค่การงงงวยอย่างจงใจหรืออย่างอื่น

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

ตัวย่อประหยัดพื้นที่บนแพลตฟอร์มที่มีข้อ จำกัด แน่นแม้ว่าจะมีความสำคัญน้อยกว่าเมื่อ 30 ปีที่แล้ว (ฉันดูเหมือนจะจำได้ว่ากำลังทำงานกับระบบในปี 1980 ที่ จำกัด คุณไว้ที่ชื่อตาราง 6 หรือ 8 ตัว)

ตัวย่อจะทำให้ชื่อตารางและชื่อคอลัมน์อ่านง่ายขึ้นตราบใดที่การย่อทำได้ดี ถ้าฉันทำงานกับรหัสสำหรับ AP ทั้งวันฉันควรอ่านชื่อคอลัมน์เช่น "ap_trx.inv_num" มากกว่า "accounts_payable_transactions.invoice_number" (ฉันชอบเครื่องหมายขีดเส้นใต้) การพิมพ์ชื่อยาวไม่ได้เป็นปัญหามากนักกับโปรแกรมแก้ไขข้อความที่ดี

ในระบบบัญชีทั้ง "ap" และ "trx" เป็นตัวย่อที่รู้จักกันดี อื่น ๆ รวมถึง "ar", "gl" และ "gj" สำหรับลูกหนี้บัญชีแยกประเภททั่วไปและสมุดรายวันทั่วไป

ในระบบที่ออกแบบมาอย่างดีถ้าฉันพบการทำธุรกรรมบัญชีเจ้าหนี้ในตารางชื่อ "aptrx" ฉันหวังว่าจะพบการทำธุรกรรมบัญชีลูกหนี้ใน artrx, ธุรกรรมบัญชีแยกประเภททั่วไปใน gltrx และอื่น ๆ ฉันพบว่า "apmaster_all" ดูงุนงงเล็กน้อย แต่ถ้าฉันเจอ "armaster_all" ฉันก็จะสันนิษฐานว่าคนแรกถือผู้ขายทั้งหมด (เมื่อเทียบกับผู้ขายที่ไม่ได้ใช้งานหรือไม่ได้ใช้งาน)

ในโดเมนปัญหาอื่น ๆ คุณจะพบตัวย่ออื่น ๆ ที่รู้จักกันดี ในการระบุที่อยู่คุณจะพบตัวย่อเช่น "addr" สำหรับที่อยู่ "st" สำหรับถนน "usps" สำหรับบริการไปรษณีย์ของสหรัฐอเมริกา "ups" สำหรับ United Parcel Service "cty" สำหรับเขต "zip" เพื่อปรับปรุงโซน รหัสและอื่น ๆ

ฉันจะไม่เรียกสิ่งนี้ว่าทำให้งงงวย หากการทำธุรกรรมบัญชีเจ้าหนี้ถูกเก็บไว้ในตารางที่ชื่อว่า "cdrs21" ฉันจะเรียกว่า obfuscation (แม้ว่าฉันจะเคยทำงานให้กับ บริษัท ที่ตั้งชื่อโมดูลแอสเซมเบลอร์เมนเฟรมทั้งหมดของพวกเขาด้วยวิธีนี้ข้อ จำกัด ของตัวละครไม่ใช่การทำให้งงงวย)

แต่ฐานข้อมูลที่มีประโยชน์จะขยายตัวและคุณพบปัญหาเมื่อฐานข้อมูลมีขนาดใหญ่ เมื่อคุณเพิ่มโดเมนปัญหาในฐานข้อมูลของคุณคุณจะพบกับสถานการณ์ที่ตัวย่อที่รู้จักกันดีชนกัน หากคุณจัดการกับสื่อดังนั้น "ap" อาจย่อ "Associated Press", "สื่อทางเลือก" หรือ "การจัดวางล่วงหน้า" เมื่อเกิดเหตุการณ์ดังกล่าวถึงเวลาที่ต้องละทิ้งตัวย่อหรือเปลี่ยนเป็นรหัส ยิ่งองค์กรมีขนาดใหญ่ขึ้น (และยิ่งมีฐานข้อมูลมากขึ้น) ยิ่งฉันพบรหัสมากขึ้นเท่านั้น

เพียงแค่ตะโกนด้วย "เทพเจ้าของฉันแว่นตาที่พวกเขาไม่ทำอะไรเลยสำหรับเรื่องการตั้งชื่อที่น่ากลัว" ทีมจัดการข้อมูลที่สภาพแวดล้อมสุดท้ายของฉันระบุเหตุผลในการใช้ชื่อตารางแบบย่อคือข้อ จำกัด ของ DB2 (เรามี DB2 บน z / os และ SQL Server) 18 ตัวอักษรสำหรับตารางและคอลัมน์ ฉันชี้ให้เห็นทันทีว่าเอกสารนี้ไม่ถูกต้องจากเว็บไซต์ของ IBM จากนั้นพวกเขากล่าวว่ามันเป็นปัญหาของภาษาโคบอล (ใช่พวกเขาได้รับการพัฒนาอย่างแข็งขันในภาษาโคบอล) ในกรณีที่จำเป็นต้องพูดคุยกับฐานข้อมูลซึ่งได้รับการพิสูจน์แล้ว ในที่สุดการตอบสนองของพวกเขาคือมาตรฐานการเผยแพร่ของเรา

เราได้ยื่นคำร้องต่อคณะกรรมการมาตรฐานเพื่อเพิ่มความยาวจาก 18 เป็น 32 ตัวอักษรและได้รับ 30 ข้อ จำกัด ส่งผลให้ตารางเปลี่ยนจากชื่อไร้ประโยชน์ของ 'SR_M_DLY_ADV_PRD_S' เป็น 'IDX_FDSHRCLAS_LIF_RTRN_STATS_X' FML

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

มันเป็นนิสัย (ฉันเห็นด้วยกับ Kevinsky) มันเป็นการตอบสนองต่อปัญหาเก่า ๆ (อาจมีอยู่) ต่อข้อ จำกัด (ความยาวชื่อช่องว่างระหว่างคำที่ซับซ้อนชื่อหลายภาษา ฯลฯ ) ของระบบปฏิบัติการ (เช่น DOS, Windows เป็นต้น) และซอฟต์แวร์บางตัวที่ไม่ได้ใช้ชื่อนั้น คนที่มีประสบการณ์พูดว่า: "ทำได้ (ใช้ชื่อย่อและคั่นด้วยชื่อขีดเส้นใต้) และทุกอย่างก็โอเค"

ฉันชอบใช้การตั้งชื่อเชิงพรรณนาด้วยเหตุผลดังกล่าวข้างต้นโดยผู้โพสต์

แต่ก็ยังมีประโยชน์อีกอย่าง ตัวอย่างเช่นด้วยการตั้งชื่อแบบอธิบายจะช่วยให้คุณใช้ชื่อที่ซ้อนกัน สมมติว่าคุณมีตารางชื่อพนักงาน หากคุณมีความสัมพันธ์กับตารางอื่นอาจเรียกว่า EmployeeAddress หรือพนักงานฝ่าย ด้วยความลับทำให้การตั้งชื่อที่ไม่ปฏิบัตินี้เป็นไปไม่ได้เกือบ

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