กุญแจแทนจะถูกเปิดเผยต่อผู้ใช้หรือไม่?

14

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

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

ข้อได้เปรียบหลักของการเปิดเผยคีย์ตัวแทนคือความเรียบง่ายของการใช้ฟิลด์ที่คุณมีอยู่แล้ว

ภายใต้สถานการณ์ใดดีกว่าที่จะเปิดเผยคีย์ตัวแทนโดยตรงกับผู้ใช้

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

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

— James Snell

1

มนุษย์เนื้อหนัง

— psr

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

10

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

หากข้อมูลไม่มีรหัสธุรกิจที่เป็นธรรมชาติคุณสามารถเพิ่มเขตข้อมูลเพิ่มเติมสำหรับ "ตัวระบุธุรกิจ" ควรปรับให้เหมาะสมสำหรับกระบวนการที่ใช้ รายการปุ่มกดโทรศัพท์หมายถึงตัวเลขเท่านั้น ทางโทรศัพท์ / ทางวาจาหมายถึงหลีกเลี่ยงสัญลักษณ์ที่ทำให้เกิดเสียงคล้ายกัน (B / D, M / N, ฯลฯ ) คุณสามารถสร้างวลีที่จดจำได้ง่าย ("เยลลี่สีเขียว") โดยอัตโนมัติ

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

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

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

— Chris Pitman
แหล่งที่มา

5

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

— Robert Harvey

1

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

— DougM

3

@DougM: จากนั้นเขียนระเบียนไปยังตารางรวมใหม่ด้วยรหัสตัวแทนของตัวเองและรักษารหัสต้นฉบับในเขตข้อมูลแยกต่างหากในตารางใหม่ (และเขตข้อมูลที่ระบุตารางต้นฉบับต้นฉบับ) เป็นการอ้างอิงหากจำเป็น การรวมแบบนั้นน่าจะหายากเป็นพิเศษและเป็นผลมาจากการออกแบบที่ไม่เรียบร้อย ทำซ้ำหลังจากฉัน: ตัวแทน คีย์ ไม่เคย เปลี่ยนแปลง นั่นเป็นเหตุผลที่พวกเขากำลังตั้งครรภ์แทน

— Robert Harvey

2

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

— Chris Pitman

2

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

— Robert Harvey

4

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

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

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

— Alan Shutko
แหล่งที่มา

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

— Kyle McVay

บ่อยครั้งสิ่งที่เกิดขึ้นคือคุณได้รับหมายเลขประจำตัวพนักงานดังนั้นในระบบพนักงานคุณจะแตกต่างจากคนอื่นที่มีชื่อเดียวกัน ในบัตรประกันของคุณอาจแสดงรายการ บริษัท และรหัสพนักงานของคุณ แต่ บริษัท ประกันสุขภาพมักจะสร้างรหัสภายในของตนเองที่สามารถใช้กับทุกระบบแทนการใช้ชื่อวันเดือนปีเกิดและรหัสพนักงานที่ได้รับจากนายจ้างของคุณ กุญแจที่สร้างขึ้นเหล่านี้เป็นตัวแทนหรือกุญแจธรรมชาติหรือไม่? ขึ้นอยู่กับว่าคุณถามใคร (ตรวจสอบคำจำกัดความ 2 ทางเลือกที่en.wikipedia.org/wiki/Surrogate_key )

— Alan Shutko

1

คุณควรเปิดเผยคีย์ตัวแทนเฉพาะเมื่อมันสร้างขึ้นอย่างถูกต้อง GUID / UUID * การเปิดเผยกุญแจตัวแทนตามลำดับคือหมายเลข 4ในประเด็นความปลอดภัย OWASP 10 อันดับแรก

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

— ปีเตอร์เทย์เลอร์
แหล่งที่มา

2

ไม่ชัดเจนจากคำตอบของคุณว่า GUID ช่วยเพิ่มความปลอดภัยได้อย่างไร

— Robert Harvey

1

@ RobertHarvey - ฉันถือว่าเพราะพวกเขาไม่ได้เรียงตามลำดับและไม่สามารถเดาได้

— Bobson

1

security.stackexchange.com/q/38777

— Robert Harvey

@ RobertHarvey ชี้แจง

— Peter Taylor

1

หากตารางไม่มีคีย์ธรรมชาติคีย์ตัวแทนจะอนุญาตให้ใช้แถวเช่นนี้

surrogate_key  some_name
--
1              Wibble
2              Wibble
...
17             Wibble
...
235            Wibble

ฉันจะเรียกกุญแจประดิษฐ์เหล่านี้แทนกุญแจตัวแทน แต่ความแตกต่างนั้นไม่สำคัญสำหรับคำถามนี้

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

— ไมค์ Sherrill 'Cat Recall'
แหล่งที่มา

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

— Kyle McVay

@ KyleMcVay: มันไม่ขัดแย้ง มันให้เกียรติความหมายของตัวแทนความคิดที่สำคัญซึ่งก็คือ "เพื่อทดแทน" คีย์ตัวแทนทดแทนคีย์ธรรมชาติ (Codd และทฤษฎีความสัมพันธ์ในการใช้งานทั่วไปที่สำคัญตัวแทนในความรู้สึกนี้.) ตารางที่มีไม่มีคีย์ธรรมชาติไม่สามารถมีคีย์ตัวแทนในแง่ที่ว่า แต่สามารถมีค่าตามอำเภอใจที่ใช้แทนสิ่งอื่น นั่นคือสิ่งที่ฉันเรียกว่ากุญแจประดิษฐ์

— Mike Catrill 'Cat Recall'

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

— Kyle McVay

0

ในคำพูดของคนธรรมดา:

ตัวแทนควรถูกซ่อนจากผู้ใช้
คุณควรเปิดเผยรหัสผู้สมัครธุรกิจอื่น ๆ แก่ผู้ใช้
หากไม่มีรหัสผู้สมัครอื่นอยู่คุณควรแสดง PK แต่ในกรณีนี้ PK ไม่ถือว่าเป็นตัวแทนเนื่องจากไม่ใช่คอลัมน์อื่น

— Tulains Córdova
แหล่งที่มา

ทำไมต้องแสดง PK ฉันคิดว่านั่นเป็นคำถามของฉัน - ว่า PK ที่สร้างขึ้นอัตโนมัตินั้นถูกเรียกว่าคีย์ตัวแทนหรือไม่

— psr

1

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

— Tulains Córdova

คำถามคือคุณควรเพิ่มคอลัมน์หรือแสดงรหัสที่คุณมี

— psr

@psr ฉันได้เขียนคำตอบอีกครั้งเพื่อให้ชัดเจนยิ่งขึ้น

— Tulains Córdova

1

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

— Robert Harvey

0

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

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

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

0

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

ข้อแม้: สิ่งนี้ถือว่าเป็นแอปพลิเคชั่นบนเว็บหรือ n-tier ที่การอนุญาตด้านเซิร์ฟเวอร์เป็นไปได้ / เป็นไปได้ หากคุณมีแอป VB ที่รัน sql โดยตรงนั่นเป็นปัญหาที่เกิดขึ้นทั้งหมด

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

จะไม่สามารถแทรกแล้วลบระเบียนในขณะที่รักษาความสัมพันธ์กับคีย์ต่างประเทศตามที่กล่าวไว้ในคำถาม

— psr

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

— GrandmasterB