เหตุใดชื่อคอลัมน์นำหน้าจึงถือว่าไม่เหมาะสม

25

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

ทั้งหมดที่ฉันรู้คือการอ่าน AdventureWorks นั้นง่ายกว่ามาก ใน~~การนี้~~บริษัท ของเรา DB คุณจะเห็นตารางบุคคลและมันอาจจะมีชื่อคอลัมน์:

Person_First_Name
หรืออาจเป็น
Person_Person_First_Name (อย่าถามฉันว่าทำไมคุณถึงเห็นตัวบุคคล 2x)

เหตุใดจึงถือว่าเป็นวิธีปฏิบัติที่ไม่ถูกต้องในการแก้ไขชื่อคอลัมน์ล่วงหน้า ขีดเส้นใต้ถือว่าเป็นความชั่วร้ายใน SQL เช่นกัน?

หมายเหตุ: ฉันเป็นเจ้าของ Pro SQL Server 2008 - การออกแบบและการใช้ฐานข้อมูลที่เกี่ยวข้อง ยินดีต้อนรับการอ้างอิงถึงหนังสือเล่มนั้น

sql

— P.Brian.Mackey
แหล่งที่มา

2

ดูเหมือนว่าใครเป็นคนทำกฎเหล่านี้ไม่ทราบถึงฟังก์ชั่นนามแฝง

— ba__friend

@Daniel Pryden - ฉันใช้ถ้อยคำไม่ดี อัปเดตคำถามแล้ว

— P.Brian.Mackey

โพสต์ที่คล้ายกันที่นี่stackoverflow.com/questions/465136/ …

@ba__friend - คุณช่วยให้รายละเอียดบางอย่างกับฉันในความคิดเห็นนี้ได้หรือไม่?

— P.Brian.Mackey

1

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

44

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

โดยส่วนตัวแล้วสถานที่เดียวที่ฉันรู้สึกว่าต้องใช้ tablename ในคอลัมน์นั้นอยู่ในคอลัมน์ ID (การใช้ just id เป็นปฏิปักษ์ในการออกแบบฐานข้อมูลเพราะทุกคนที่ทำแบบสอบถามการรายงานที่หลากหลายสามารถบอกคุณได้มันสนุกมากที่จะเปลี่ยนชื่อ 12 คอลัมน์ในข้อความค้นหาของคุณทุกครั้งที่คุณเขียนรายงาน) ซึ่งทำให้ง่ายต่อการรู้จัก FKs ในตารางอื่น ๆ ได้ง่ายขึ้นเนื่องจากมีชื่อเดียวกัน

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

— HLGEM
แหล่งที่มา

4

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

— HLGEM

2

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

— โปรแกรมเมอร์

3

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

— HLGEM

7

@ Jason, ฉันเป็นคนฐานข้อมูลเรารู้กันดีว่าไม่มีความรู้สึกในการผจญภัย!

— HLGEM

2

เห็นด้วยอย่างสิ้นเชิงกับ TableName.Id เป็นปฏิปักษ์ ได้ทำงานภายในและไม่ใช้รูปแบบนั้นนานพอที่ฉันสามารถบอกได้เลยว่าข้อผิดพลาด / ความสับสนเกิดขึ้นกับ TableName.Id ที่ไม่ได้เกิดขึ้นกับ TableName.TableNameId

— AaronLS

16

อาร์กิวเมนต์สำหรับคำนำหน้าชื่อคอลัมน์จะป้องกันชื่อ "การชนกัน" เมื่อเข้าร่วมหลายตารางและเมื่อผู้สร้างแบบสอบถามไม่ได้ใช้ชื่อแทน

SELECT person.name, company.name FROM person JOIN company ON ...

SELECT * FROM person JOIN company ON ...

ข้อความค้นหาทั้งสองจะมีสองคอลัมน์ "ชื่อ" ( name_1, name_2 ) โดยไม่มี "บอก" ว่าเป็นนิติบุคคลใด และคุณไม่สามารถแน่ใจได้ว่าชื่อคอลัมน์ที่สร้างขึ้น (จะเป็นชื่อ _2 หรือชื่อ _3 หรือ ... ) หากคุณใช้คำนำหน้าชื่อตารางชื่อคอลัมน์จะเป็นperson_name , company_nameเพื่อให้คุณรู้ชื่อแต่ละชื่อของเอนทิตีและคุณรู้ว่าชื่อคอลัมน์จะคงที่ (ถ้าคุณได้รับใน Java โดยใช้ JDBC เป็นต้น) )

อาร์กิวเมนต์ทั้งสองสามารถถูกละเว้นได้หากคุณใช้นามแฝง แต่ฉันคิดว่าอนุสัญญาการเข้ารหัสที่บังคับใช้ใน บริษัท ส่วนใหญ่มาจากโปรแกรมเมอร์ (รุ่นจูเนียร์) จำนวนมากที่ไม่ปฏิบัติตามแนวทางปฏิบัติที่ดี ในกรณีนี้ตัวอย่างเช่นการใช้อักขระตัวแทนบนคำสั่ง SELECT อาจทำให้เกิดปัญหาโดยไม่มีการใส่คำนำหน้าชื่อ

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

SELECT person_name, COUNT(bought_product) FROM bought_products WHERE person_name LIKE 'A%'

— Nicolae Albu
แหล่งที่มา

6

ฉันจะรักถ้าคอลัมน์ทั้งหมดที่มีข้อมูลเดียวกันในตารางที่แตกต่างกันจะมีชื่อเดียวกันและทุกครั้งที่คุณใช้นามแฝงของตารางมากกว่า 1 ตารางจะเป็นมาตรฐานที่บังคับใช้ เริ่มเบื่อกับการจำแผนที่ที่ patid, patientid, pat_id, id_pat หรือ ptatient_id

— Pieter B

1

ฉันไม่เคยเขียนแบบสอบถามการผลิตโดยไม่ต้องใช้นามแฝงคอลัมน์ทั้งหมด มันทำให้การบำรุงรักษาง่ายขึ้นมาก แน่นอนฉันเขียนแบบสอบถามประเภทรายงาน / ส่งออกที่มีความซับซ้อนมากถึง 10-20 ตัวเชื่อมและ 30-50 คอลัมน์และหกเดือนต่อมามันก็ยากที่จะจำได้ว่าตารางใดมาจากคอลัมน์นั้น

— HLGEM

8

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

— เซร์คิโอ
แหล่งที่มา

4

มีข้อยกเว้นถ้าใช้อย่างรอบคอบ (ตามคำตอบแพทริค Karcher ในการเชื่อมโยงของคุณ) สำหรับชื่อคอลัมน์ที่พบบ่อย (ปกติเพียง ID บางครั้งชื่อ) ที่จะมีความคลุมเครือบ่อยเกินไป

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

เปรียบเทียบสิ่งเหล่านี้: ซึ่งเป็นสิ่งที่ง่ายที่สุดในสายตา?

SELECT P.name, P.Salary FROM dbo.Person P

SELECT Person.Name, Person.Salary FROM dbo.Person Person

SELECT dbo.Person.name, dbo.Person.Salary FROM dbo.Person

SELECT Person.Person_name, Person.Person_Salary FROM dbo.Person Person

— GBN
แหล่งที่มา

3

คนแรกแน่นอน ... :)

— ErikE

3

เกี่ยวกับSELECT name, salary FROM dbo.Personอะไร : P

— cHao

1

@cHao: ลองสร้างมุมมองด้วย SCHEMABINDING ในนั้น ...

— gbn

@gbn: ทำงานได้ดีสำหรับฉัน

CREATE VIEW [dbo].[vwMeritPercentage] with schemabinding AS 	SELECT  		[Performance Score] as dblMinScore, 		ISNULL(( 			SELECT TOP 1 [Performance Score]  			FROM dbo.Budget b 			WHERE b.[Performance Score] > budget.[Performance Score] 			ORDER BY [Performance Score] 		), 100.00) as dblMaxScore, 		[Merit Minimum] as dblMinPercentage, 		[Merit Midpoint] as dblBudgetPercentage, 		[Merit Maximum] as dblMaxPercentage 	FROM dbo.Budget;

— cHao

1

เอกสารที่เกี่ยวข้อง ( msdn.microsoft.com/en-us/library/ms187956(v=SQL.105).aspx ): "เมื่อคุณใช้ SCHEMABINDING, select_statement ต้องมีชื่อสองส่วน (schema.object) ของตาราง มุมมองหรือฟังก์ชั่นที่ผู้ใช้กำหนดเองที่อ้างถึง " โปรดทราบว่าคอลัมน์ไม่จำเป็นต้องมีชื่อเป็นจุด (ยกเว้นว่าจำเป็นต้องมีการแก้ไขความกำกวมในข้อความค้นหา) ... เฉพาะตารางมุมมองและฟังก์ชั่น

— cHao

3

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

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

— แดนไซม่อน
แหล่งที่มา

2

ใน TSQL คุณสามารถอ้างถึงเขตข้อมูลในรูปแบบ TableName.FieldName หากคุณต้องการหลีกเลี่ยงความคลุมเครือดังนั้นการเพิ่มชื่อตารางให้กับชื่อเขตข้อมูลนั้นจะไม่สามารถอ่านได้จริงทำให้ TableName.TableName_FieldName หรือคล้ายกัน ฉันคิดว่าการใช้ขีดเส้นใต้หรือไม่นั้นเป็นตัวเลือกส่วนบุคคลมากกว่า ฉันชอบ CamelCase และฉันใช้ _ เมื่อฉันต้องการเพิ่มคำต่อท้ายหรือคล้ายกันเช่น TableName_Temp แต่นั่นเป็นเพียงฉัน

— เบ็นโรบินสัน
แหล่งที่มา

2

ฉันเคยทำงานในระบบที่เราตัดสินใจใช้รหัสย่อเพื่อนำหน้าคอลัมน์ ฟิลด์ PK ใช้ "ชื่อตารางเต็ม" เป็นคำนำหน้าและคอลัมน์อื่น ๆ ทั้งหมดใช้ 2-4 อักขระอย่างสม่ำเสมอเป็นส่วนนำหน้า แต่ละคอลัมน์ยังใช้โดเมนข้อมูลเป็นคำต่อท้าย ถ้าทำอย่างสม่ำเสมอมันจะดีและสะอาด มันไร้สาระที่มาตรฐานการตั้งชื่อของประเภทหนึ่งหรืออีกนัยหนึ่งเขียนรหัสเลอะเทอะ การมีมาตรฐานที่สอดคล้องกันเป็นสิ่งที่สำคัญ ฉันเห็นฐานข้อมูลจำนวนหนึ่งที่ไม่สอดคล้องกันเพราะไม่มีมาตรฐานที่ชัดเจนและยิ่งกว่าสิ่งอื่นใดที่บ่งบอกว่ามีปัญหาในโครงสร้างข้อมูล หากผู้ออกแบบฐานข้อมูลไม่สามารถระบุชื่อวัตถุและลูก ๆ ของมันได้อย่างสม่ำเสมอ

— ทอม
แหล่งที่มา

1

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

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

— Justin Dearing
แหล่งที่มา

1

ฐานข้อมูลจำนวนมากมีข้อ จำกัด ที่เข้มงวดเกี่ยวกับจำนวนอักขระในชื่อคอลัมน์ (เช่น Oracle)

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

แม้ว่าคุณจะทำงานกับ SQL Server แล้วในตอนนี้ แต่ก็ไม่มีใครสามารถทำนายอนาคตได้และเป็นไปได้ว่าซอฟต์แวร์ของคุณอาจต้องทำงานกับหลายฐานข้อมูลในอนาคต

— Britt Wescott
แหล่งที่มา

0

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

วิธีหนึ่งคือทำตามแนวทางของมาตรฐานสากล ISO / IEC 11179 - หลังจากทั้งหมดทำไมต้องบูรณาการล้อ โครงสร้างพื้นฐานคือ:

[Object] [Qualifier] Property RepresentationTerm

ด้วยตัวคั่นระหว่างองค์ประกอบ: SQL เล่นได้ไม่ดีกับช่องว่างในชื่อคอลัมน์และขีดล่างทำงานได้ดี

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

ตัวอย่างที่ผมชอบที่จะแสดงเป็นสหราชอาณาจักรเนชั่นบริการสุขภาพ (NHS) พจนานุกรมข้อมูล

ดังนั้นฉันไม่คิดว่ารูปแบบการตั้งชื่อที่คุณต้องใช้กับเสียงแย่เกินไป

ในการดำเนินการเช่นใน SQL ชาวบ้านบางคนชอบที่จะละเว้นวัตถุรอบคัดเลือกและทรัพย์สินองค์ประกอบย่อยเมื่อชื่อตารางให้บริบทเช่นperson_first_nameกลายเป็นfirst_nameในPersonตาราง ฯลฯ แต่กฎของหัวแม่มือที่องค์ประกอบของข้อมูลไม่ควรเปลี่ยนชื่อเป็นเพียงแค่ เนื่องจากตำแหน่งของมันในแบบจำลองทางกายภาพดูเหมือนว่าจะดี ทุกคนที่ถ้าคิดว่ามันไม่ควรทำตามกฎนี้ควรให้งานของการบันทึกชื่อรูปแบบทั้งหมดที่พวกเขาใช้ :)

คุณจะพบข้อสรุปที่ดีของ ISO 11179 ในรูปแบบการเขียนโปรแกรมของ Joe Celkoในหนังสือรวมถึงหลักฐานการเลือกขีดเส้นใต้เป็นตัวคั่นในชื่อคอลัมน์

— onedaywhen
แหล่งที่มา

0

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

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

— บิลลีเปอร์
แหล่งที่มา