ใช้ที่อยู่อีเมลเป็นรหัสหลักหรือไม่

ที่อยู่อีเมลเป็นตัวเลือกที่ไม่ถูกต้องสำหรับข้อมูลหลักเมื่อเปรียบเทียบกับตัวเลขที่เพิ่มขึ้นอัตโนมัติหรือไม่

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

เป็นเหตุผลที่ถูกต้องหรือไม่ที่จะไม่ใช้อีเมลเป็นคีย์หลัก?

PostgreSQLเราใช้

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

หากคุณเก็บข้อมูลเกี่ยวกับผู้ใช้ในหลาย ๆ ตารางคีย์ต่างประเทศในตารางผู้ใช้จะเป็นที่อยู่อีเมล นั่นหมายความว่าคุณเก็บที่อยู่อีเมลหลายครั้ง

ฉันจะชี้ให้เห็นว่าอีเมลเป็นตัวเลือกที่ไม่ดีในการสร้างฟิลด์ที่ไม่เหมือนใครมีผู้คนและธุรกิจขนาดเล็กที่ใช้ที่อยู่อีเมลร่วมกัน และเช่นเดียวกับหมายเลขโทรศัพท์อีเมลสามารถใช้ซ้ำได้Jsmith@somecompany.com สามารถเป็นของ John Smith ได้หนึ่งปีและ Julia Smith อีกสองปีต่อมา

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

คีย์หลักควรไม่ซ้ำกันและคงที่

ที่อยู่อีเมลเปลี่ยนไปตามฤดูกาล มีประโยชน์เป็นคีย์รองสำหรับการค้นหา แต่เป็นทางเลือกที่แย่สำหรับคีย์หลัก

ข้อเสียของการใช้ที่อยู่อีเมลเป็นคีย์หลัก:

1. ช้าลงเมื่อเข้าร่วม

2. บันทึกอื่น ๆ ที่มีคีย์ต่างประเทศที่โพสต์ในขณะนี้จะมีค่ามากกว่าใช้พื้นที่ดิสก์มากขึ้น (เนื่องจากราคาของพื้นที่ดิสก์ในวันนี้อาจเป็นปัญหาเล็กน้อยยกเว้นในกรณีที่เรคคอร์ดใช้เวลาในการอ่านนานขึ้นดูที่ # 1)

3. ที่อยู่อีเมลสามารถเปลี่ยนแปลงได้ซึ่งบังคับให้บันทึกทั้งหมดที่ใช้สิ่งนี้เป็นรหัสต่างประเทศที่จะได้รับการปรับปรุง เนื่องจากที่อยู่อีเมลไม่ได้เปลี่ยนแปลงทุกอย่างบ่อยครั้งปัญหาด้านประสิทธิภาพอาจไม่ดีพอ ปัญหาที่ใหญ่กว่าคือคุณต้องแน่ใจว่าได้ระบุไว้ ถ้าคุณต้องเขียนโค้ดมันจะใช้งานได้มากกว่าและมีความเป็นไปได้ของบั๊ก หากเอ็นจิ้นฐานข้อมูลของคุณรองรับ "on cascade update" นั่นเป็นปัญหาเล็กน้อย

ข้อดีของการใช้ที่อยู่อีเมลเป็นคีย์หลัก:

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

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

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

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

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

... และฉันยังไม่ได้เริ่มพูดถึงการพิจารณาเกี่ยวกับประสิทธิภาพ

ฉันไม่ทราบว่าอาจเป็นปัญหาในการตั้งค่าของคุณหรือไม่ แต่ขึ้นอยู่กับ RDBMS ค่าของคอลัมน์อาจคำนึงถึงตัวพิมพ์เล็กและตัวพิมพ์ใหญ่ PostgreSQL docs พูดว่า:„ หากคุณประกาศคอลัมน์เป็น UNIQUE หรือคีย์หลักดัชนีที่สร้างขึ้นโดยปริยายจะคำนึงถึงตัวพิมพ์เล็กและตัวพิมพ์ใหญ่ " กล่าวอีกนัยหนึ่งถ้าคุณยอมรับการป้อนข้อมูลของผู้ใช้สำหรับการค้นหาในตารางที่มีอีเมลเป็นคีย์หลักและผู้ใช้ให้ "John@Doe.com" คุณจะไม่พบ“ john@doe.com”

ดูเหมือนว่าไม่มีใครพูดถึงปัญหาที่เป็นไปได้ว่าที่อยู่อีเมลอาจถูกพิจารณาว่าเป็นส่วนตัว หากที่อยู่อีเมลเป็นคีย์หลัก URL ของหน้าโปรไฟล์มักจะมีลักษณะคล้าย..../Users/my@email.comกัน ถ้าคุณไม่ต้องการเปิดเผยที่อยู่อีเมลของผู้ใช้ คุณจะต้องไปหาวิธีอื่นในการระบุผู้ใช้อาจจะโดยค่าจำนวนเต็มไม่ซ้ำกันที่จะทำให้ URL ..../Users/1ที่ชอบ จากนั้นคุณจะจบลงด้วยค่าจำนวนเต็มที่ไม่ซ้ำกันหลังจากทั้งหมด

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

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

systempuntoout ถาม

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

นั่นคือสิ่งที่ลดหลั่นกันมา

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

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

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

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

แบบนี้:

CREATE TABLE myTable(
    id integer primary key,
    email text UNIQUE
);

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

ฉันไม่คุ้นเคยกับ postgres มากเกินไป คีย์หลักเป็นหัวข้อใหญ่ ฉันเคยเห็นคำถามและคำตอบที่ยอดเยี่ยมบนไซต์นี้ (stackoverflow.com)

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

บางคนอ่านที่นี่และที่นี่

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

เพื่อนร่วมงานของคุณถูกต้อง: ใช้จำนวนเต็มการสร้างอัตโนมัติสำหรับคีย์หลักของคุณ

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

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

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

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

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

@HLGEM ชี้ให้เห็นว่า "Jsmith@somecompany.com สามารถเป็นของ John Smith ได้หนึ่งปีและ Julia Smith อีกสองปีต่อมา" ในกรณีนี้หาก John Smith ต้องการบริการของคุณคุณต้องปฏิเสธที่จะใช้ที่อยู่อีเมลของเขาหรือลบบันทึกทั้งหมดที่เกี่ยวข้องกับ Julia Smith

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

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

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

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

คุณสามารถเพิ่มประสิทธิภาพได้โดยใช้คีย์หลักจำนวนเต็ม

คุณควรใช้คีย์หลักจำนวนเต็ม หากคุณต้องการให้คอลัมน์อีเมลไม่ซ้ำกันทำไมคุณไม่ตั้งค่าเฉพาะดัชนีในคอลัมน์นั้น

หากคุณมีค่าที่ไม่ใช่ int เป็นคีย์หลักการแทรกและดึงข้อมูลจะช้ามากในข้อมูลขนาดใหญ่

คีย์หลักควรเลือกแอตทริบิวต์คงที่ เนื่องจากที่อยู่อีเมลไม่คงที่และสามารถใช้งานร่วมกันโดยผู้สมัครหลายคนดังนั้นจึงไม่ควรใช้ที่อยู่อีเมลเหล่านี้เป็นคีย์หลัก ยิ่งไปกว่านั้นที่อยู่อีเมลเป็นสตริงที่มีความยาวแน่นอนซึ่งอาจมากกว่า id ที่ไม่ซ้ำกันที่เราต้องการใช้ [len (email_address)> len (unique_id)] ​​ดังนั้นมันจะต้องใช้พื้นที่มากขึ้นและแย่ที่สุดพวกเขาจะถูกเก็บไว้หลายครั้ง . และส่งผลให้ประสิทธิภาพลดลง

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

หากเป็นเรื่องของการกำหนดให้อีเมลไม่ซ้ำใครคุณสามารถสร้างดัชนีที่ไม่ซ้ำกับคอลัมน์นั้นได้

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

อย่าใช้ที่อยู่อีเมลเป็นคีย์หลักเก็บอีเมลที่ไม่ซ้ำกัน แต่อย่าใช้มันเป็นคีย์หลักใช้รหัสผู้ใช้หรือชื่อผู้ใช้เป็นคีย์หลัก