เหตุใดการตั้งชื่อคอลัมน์คีย์หลักของตาราง“ Id” จึงถือว่าไม่เหมาะสม [ปิด]

ครู t-sql ของฉันบอกเราว่าการตั้งชื่อคอลัมภ์ PK "Id" ของเรานั้นถือว่าเป็นการฝึกที่ไม่ดีโดยไม่มีคำอธิบายใด ๆ เพิ่มเติม

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

ฉันจะออกมาและบอกว่ามัน: มันไม่ได้จริงๆปฏิบัติไม่ดี (และแม้ถ้ามันเป็นไม่ได้ว่าไม่ดี)

คุณสามารถสร้างข้อโต้แย้ง (ตามที่ชาดชี้) ว่าสามารถปกปิดข้อผิดพลาดเช่นในแบบสอบถามต่อไปนี้:

SELECT * 
    FROM cars car
    JOIN manufacturer mfg
        ON mfg.Id = car.ManufacturerId
    JOIN models mod
        ON mod.Id = car.ModelId
    JOIN colors col
        ON mfg.Id = car.ColorId

แต่สิ่งนี้สามารถบรรเทาได้ง่าย ๆ โดยไม่ใช้นามแฝงเล็ก ๆ สำหรับชื่อตารางของคุณ:

SELECT * 
    FROM cars
    JOIN manufacturer
        ON manufacturer.Id = cars.ManufacturerId
    JOIN models
        ON models.Id = cars.ModelId
    JOIN colors
        ON manufacturer.Id = cars.ColorId

การปฏิบัติของการเสมอโดยใช้ตัวย่อ 3 idตัวอักษรดูเหมือนว่าเลวร้ายมากกับผมกว่าการใช้ชื่อคอลัมน์ (ในกรณี: ใครจะเป็นตัวย่อชื่อตารางcarsด้วยตัวย่อจริง ๆ แล้วcarมันทำหน้าที่อะไร?)

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

มุ่งเน้นที่การเรียนรู้สิ่งต่าง ๆ ที่เป็นการปฏิบัติที่ไม่ดีจริง ๆ (เช่นแบบสอบถามย่อยที่สัมพันธ์กันหลายรายการ) แทนที่จะครุ่นคิดมากกว่าประเด็นเช่นนี้ ปัญหาของการตั้งชื่อคอลัมน์ "ID" ของคุณนั้นใกล้เคียงกับรสนิยมมากกว่าการฝึกฝนที่ไม่ดี

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

เพราะเมื่อคุณมีตารางที่มีรหัสต่างประเทศคุณจะไม่สามารถตั้งชื่อรหัสต่างประเทศ "รหัส" ได้ คุณมีชื่อตารางว่า TableId

และจากนั้นการเข้าร่วมของคุณดูเหมือน

SELECT * FROM cars c JOIN manufacturer m ON m.Id = c.ManufacturerId

และในอุดมคติเงื่อนไขของคุณควรมีชื่อเขตข้อมูลเดียวกันในแต่ละด้าน

SELECT * FROM cars c JOIN manufacturer m ON m.ManufacturerId = c.ManufacturerId

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

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

SELECT * 
    FROM cars car 
    JOIN manufacturer mfg
        ON mfg.Id = car.ManufacturerId
    JOIN models mod
        ON mod.Id = car.ModelId
    JOIN colors col
        ON mfg.Id = car.ColorId

ในขณะที่มีการตั้งชื่อที่เหมาะสมข้อผิดพลาดก็โผล่ออกมา ...

SELECT * 
    FROM cars car 
    JOIN manufacturer mfg
        ON mfg.ManufacturerId = car.ManufacturerId
    JOIN models mod
        ON mod.ModelId = car.ModelId
    JOIN colors col
        ON mfg.ManufacturerId = car.ColorId

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

SELECT   manufacturer.Id as 'ManufacturerId'
        ,cars.Id as 'CarId'
        --etc
    FROM cars 
    JOIN manufacturer
        ON manufacturer.Id = cars.Id

ด้วยชื่อที่ถูกต้องนี่เป็นปัญหาน้อยกว่า

ไลบรารี ActiveRecord ของรูบี้และ GORM ของ Groovy ใช้ "id" สำหรับคีย์ตัวแทนโดยค่าเริ่มต้น ฉันชอบการปฏิบัตินี้ การทำซ้ำชื่อตารางในแต่ละชื่อคอลัมน์ซ้ำซ้อนน่าเบื่อเขียนและน่าเบื่ออ่าน

ชื่อคอลัมน์ทั่วไปหรือคีย์เช่น "ชื่อ" หรือ "Id" ควรขึ้นต้นด้วย TableName

มันลบความคลุมเครือง่ายต่อการค้นหาหมายถึงชื่อแทนคอลัมน์ที่น้อยลงเมื่อต้องการค่า "Id" ทั้งคู่

คอลัมน์ที่ใช้น้อยลงหรือตรวจสอบหรือไม่ใช่คีย์ (พูด LastUpdatedDateTime) ไม่สำคัญ

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

ฉันเชื่อว่าสำหรับเดือนนี้ฉันได้ใช้เวลาทุกวันทุกวันทำงานในจำนวนมากของฐานข้อมูลขนาดใหญ่ (Salesforce) Idและสิ่งที่ดีที่สุดที่ฉันสามารถพูดเกี่ยวกับสกีมาคือการที่ทุกตารางมีคีย์หลักที่เรียกว่า ฉันสามารถรับประกันคุณฉันอย่างไม่เคยได้รับสับสนเกี่ยวกับการเข้าร่วมคีย์หลักไปยังต่างประเทศที่สำคัญเพราะ PK Idที่เรียกว่า อีกสิ่งที่ผู้คนไม่ได้กล่าวถึงก็คือตารางอาจมีชื่อที่โง่ ๆ เช่นTable_ThatDoesGood_stuff__c; ชื่อนั้นไม่ดีพอเนื่องจากสถาปนิกมีอาการเมาค้างในตอนเช้าเขาคิดว่าตาราง แต่ตอนนี้คุณกำลังบอกฉันว่ามันเป็นวิธีปฏิบัติที่ไม่ดีที่จะไม่เรียกคีย์หลักTable_ThatDoesGood_stuff__cId (จำได้ว่าชื่อคอลัมน์ SQL ไม่ตรงตามตัวพิมพ์ใหญ่ - เล็ก)

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

ฉันไม่คิดว่ามันเป็นการปฏิบัติที่ไม่ดี ความมั่นคงเป็นราชาเช่นเคย

ฉันคิดว่ามันเป็นเรื่องของบริบท ในบริบทของตารางด้วยตนเอง "id" นั้นหมายถึงสิ่งที่คุณคาดหวังฉลากที่จะช่วยระบุตัวตนที่ไม่ซ้ำกับผู้อื่นที่อาจเป็น (หรือปรากฏ) เหมือนกัน

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

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

จากdata.stackexchange.com

บูมตอบคำถามแล้ว
ตอนนี้ไปบอกครูของคุณว่าดังนั้นฝึกการออกแบบฐานข้อมูลที่ไม่ดี

มันทำให้ยาก (และสับสน) ในการเล่นแบบธรรมชาติบนโต๊ะดังนั้นใช่มันไม่ดีถ้าไม่แย่มาก

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

ถ้าคุณตั้งชื่อ ID หลักทั้งหมดของคุณคุณจะเสียความสะดวกและความเรียบง่ายของการเข้าร่วมแบบธรรมชาติ select * from dudes natural join carsจะต้องมีการเขียนselect * from dudes inner join cars where cars.dudeid = dudes.idหรือselect * from dudes inner join cars where dudes.carid = cars.id. หากคุณสามารถเข้าร่วมได้อย่างเป็นธรรมชาติคุณจะไม่สนใจว่าความสัมพันธ์คืออะไรซึ่งฉันเชื่อว่ามันยอดเยี่ยมมาก

มีสถานการณ์ที่การติด "ID" ในทุกตารางไม่ใช่ความคิดที่ดีที่สุด: USINGคำหลักหากได้รับการสนับสนุน เราใช้บ่อยใน MySQL

ตัวอย่างเช่นหากคุณมีfooTableคอลัมน์fooTableIdและbarTableคีย์ต่างประเทศfooTableIdคุณสามารถสร้างคิวรีของคุณเช่น:

SELECT fooTableId, fooField1, barField2 FROM fooTable INNER JOIN barTable USING (fooTableId)

ไม่เพียงบันทึกการพิมพ์ แต่สามารถอ่านได้มากกว่าเมื่อเปรียบเทียบกับตัวเลือกอื่น ๆ :

SELECT fooTable.Id, fooField1, barField2 FROM fooTable INNER JOIN barTable ON (fooTable.Id = barTable.foTableId)

ทำไมไม่ถามครู

คิดเกี่ยวกับสิ่งนี้เมื่อคอลัมน์ PK ของตารางทั้งหมดของคุณชื่อIDมันทำให้พวกเขาใช้เป็นกุญแจต่างประเทศเป็นฝันร้าย

ชื่อคอลัมน์จะต้องมีความหมายอย่างมีนัยสำคัญ IDคือทั่วไป

ID ไม่ถูกต้องเนื่องจากสาเหตุต่อไปนี้:

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

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

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

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

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

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

ใช่สิ่งนี้สามารถทำได้โดยมาตรฐานของการมี "id" และรู้ว่าจะใช้มันเป็น "tableNameID" เสมอไป แต่ที่ทั้งคู่ต้องรู้ว่าการฝึกปฏิบัตินั้นเกิดขึ้นและขึ้นอยู่กับนักพัฒนาดั้งเดิมที่จะต้องทำตาม การปฏิบัติมาตรฐานที่ใช้งานง่าย

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

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

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

และนั่นคือสาเหตุที่การใช้ id นั้นเป็นวิธีปฏิบัติที่ไม่ดี: id มักไม่ใช่ข้อมูลแค่การเพิ่มขึ้นอัตโนมัติ

พิจารณาตารางต่อไปนี้:

PK id | Countryid   | Countryname
    1 |         840 | United States
    2 |         528 | the Netherlands

มีอะไรผิดปกติกับตารางนี้คือมันช่วยให้ผู้ใช้สามารถเพิ่มอีกบรรทัด: United States, กับ countrycode 840 มันเพิ่งทำลายความสัมพันธ์เชิงสัมพันธ์ แน่นอนคุณสามารถบังคับใช้เอกลักษณ์ในแต่ละคอลัมน์หรือคุณสามารถใช้คีย์หลักที่มีอยู่แล้ว:

PK Countryid   | Countryname
           840 | United States
           528 | the Netherlands

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

ฉันมักจะใช้ 'id' เป็นชื่อคอลัมน์หลักสำหรับทุกตารางเพียงเพราะเป็นหลักการของกรอบที่ฉันใช้ (Ruby on Rails, CakePHP) ดังนั้นฉันจึงไม่จำเป็นต้องแทนที่มันตลอดเวลา

นั่นจะไม่ชนะเหตุผลทางวิชาการสำหรับฉัน

ฉันไม่คิดว่ามันเป็นการปฏิบัติที่ไม่ดีถ้ามันถูกใช้อย่างถูกต้อง เป็นเรื่องปกติที่จะมีช่อง ID ที่เพิ่มขึ้นอัตโนมัติที่เรียกว่า "ID" ที่คุณไม่ต้องแตะและใช้ตัวระบุที่เป็นมิตรสำหรับแอปพลิเคชัน อาจเป็นเรื่องยุ่งยากในการเขียนโค้ดเช่นนี้from tableA a inner join tableB b on a.id = b.a_idแต่รหัสนั้นสามารถซ่อนอยู่ได้

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

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

หวังว่าจะไม่มีใครพัฒนาฐานข้อมูล sql โดยที่ ID เป็นคำที่สงวนไว้

CREATE TABLE CAR (ID);

ดูแลชื่อฟิลด์คีย์หลักและการเพิ่มอัตโนมัติโดย 1 เริ่มต้นด้วย 1 ทั้งหมดในแพ็คเกจตัวละคร 2 ตัวเล็ก ๆ ที่ดี โอ้และฉันจะเรียกมันว่า CARS แต่ถ้าเราจะประหยัดในการกดปุ่มและใครคิดว่าตารางที่ชื่อว่า CAR จะมีแค่อันเดียว?

คำถามนี้ถูกตีซ้ำแล้วซ้ำอีก แต่ฉันคิดว่าฉันก็จะเพิ่มความคิดเห็นของฉัน

1. ฉันใช้รหัสเพื่อหมายความว่านั่นคือตัวระบุสำหรับแต่ละตารางดังนั้นเมื่อฉันเข้าร่วมกับตารางและฉันต้องการคีย์หลักฉันจะเข้าร่วมกับคีย์หลักโดยอัตโนมัติ

2. ฟิลด์ id เป็น autoincrement ที่ไม่ได้ลงชื่อ (หมายความว่าฉันไม่จำเป็นต้องตั้งค่าและไม่สามารถลบได้)

3. สำหรับคีย์ต่างประเทศฉันใช้ tablenameid (เป็นเรื่องของสไตล์อีกครั้ง) แต่คีย์หลักที่ฉันเข้าร่วมคือฟิลด์ id ของตารางดังนั้นความสอดคล้องจึงหมายความว่าฉันสามารถตรวจสอบคิวรีได้อย่างง่ายดาย

4. id สั้นและหวานเกินไป

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

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

ตัวอย่างเช่นคุณจะไม่สามารถโหลด schema ของคุณลงในเครื่องมืออย่าง Visio และทำให้ ERD นั้นถูกต้อง

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

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

SELECT cars.color, cars.model FROM cars WHERE cars.id = <some_var>

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

ดังนั้นเพื่อสรุปสิ่งที่ฉันต้องการเพิ่มคือมันเป็นเพียงเรื่องของการตั้งค่าและวิธีการอธิบายการอ่าน SQL เป็นที่นิยมที่สุด

แม้ว่าจะมีบางกรณีที่ไม่ได้ใช้งานเช่น (ตัวอย่างที่หายากกว่า) เมื่อ ID เป็นสตริงที่อธิบายได้จริง ตัวอย่างid = "RedFordMustang1970"หรือสิ่งที่คล้ายกัน ฉันหวังว่าฉันจะอธิบายเรื่องนี้อย่างน้อยก็เพื่อให้ได้ความคิด