การออกแบบตารางคอลัมน์เดียวดีไหม [ปิด]

111

ปิด . คำถามนี้เป็นคำถามความคิดเห็นตาม ขณะนี้ยังไม่ยอมรับคำตอบ

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

ปิดให้บริการใน4 ปีที่แล้ว

ปรับปรุงคำถามนี้

มีตารางที่มีคอลัมน์เดียวได้ไหม ฉันรู้ว่ามันไม่ผิดกฎหมาย แต่ถือว่าเป็นการออกแบบที่ไม่ดีหรือไม่?

แก้ไข:

นี่คือตัวอย่างบางส่วน:

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

มีคนพูดถึงการเพิ่มฟิลด์คีย์ อย่างที่ฉันเห็นคอลัมน์เดียวนี้น่าจะเป็นคีย์หลัก

sql database-design

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

ฉันมีปัญหาเล็กน้อยในการจินตนาการถึง use-case สำหรับตารางที่มีเพียงคอลัมน์เดียว คุณสามารถยกตัวอย่างได้หรือไม่?

— Paul Morie

แต่อย่างน้อยอย่าสร้างดัชนีสำหรับมัน!

— สาธุ

3

รหัสรัฐของสหรัฐอเมริกาเป็นตัวอย่างคลาสสิกในการกำหนดโดเมน

— Quassnoi

3

ฉันเคยเห็นตารางฐานข้อมูลที่ใช้เก็บค่าล็อคสำหรับแอปพลิเคชันมาก่อน

— Russ Cam

ฉันใช้รูปแบบนี้เพื่อสร้างชุดข้อมูล แต่ละระเบียนในตารางหลักมีเขตข้อมูล SET มีการเชื่อมต่อบันทึกที่มี SET เดียวกัน คุณจะแทรกหลายระเบียนด้วย SET เดียวกันได้อย่างไร? 'INSERT INTO กำหนดค่า ()' จากนั้นใช้รหัสแทรกสุดท้ายเป็นรหัสชุดของคุณเพื่อแนบไปกับเรกคอร์ด จากนั้นอีกครั้งบางทีฉันอาจจะใช้ UUID แต่มีบางอย่างผิดปกติ

— William Entriken

87

ใช่มันเป็นการออกแบบที่ดีอย่างแน่นอนในการออกแบบโต๊ะเพื่อให้มีประสิทธิภาพสูงสุด "การออกแบบ RDBMS ที่ไม่ถูกต้อง" มักมีศูนย์กลางอยู่ที่ความไม่มีประสิทธิภาพ

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

— Erik Funkenbusch
แหล่งที่มา

168

ในแง่ของrelational algebraสิ่งนี้จะเป็นความสัมพันธ์ที่เป็นเอกภาพหมายความว่า " สิ่งนี้มีอยู่จริง "

ใช่มันเป็นเรื่องปกติที่จะมีตารางที่กำหนดความสัมพันธ์เช่นกำหนดโดเมน

ค่าของตารางดังกล่าวควรเป็นคีย์หลักตามธรรมชาติแน่นอน

ตารางการค้นหาprime numbersคือสิ่งที่อยู่ในใจของฉันเป็นอันดับแรก

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

3

+1: ตารางคือชุดของค่าที่เกิดขึ้นเป็นประเภทดั้งเดิมของ RDBMS ของคุณ

— S.Lott

4

+1 สำหรับการให้คำตอบตามทฤษฎีเชิงสัมพันธ์

— lubos hasko

นี่คือตัวอย่างที่ดีของสคีมาที่มีตาราง 1 คอลัมน์ที่ไม่ใช่คีย์ธรรมชาติตารางเธรดในระบบส่งข้อความ ... stackoverflow.com/a/6542556/45767

— JeremyWeir

29

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

— Spencer Ruport
แหล่งที่มา

19

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

— เควิน
แหล่งที่มา

+1 - บรรทัดล่างนี่คือคำตอบที่ถูกต้องในหนังสือของฉัน

— Mark Brittingham

+1 สำหรับคำตอบที่กระชับและชัดเจน

— Matthew Jones

3

เหตุใดจึงไม่สามารถเชื่อมโยงตารางคอลัมน์หนึ่งกับตารางอื่นได้

— Aheho

2

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

— Aheho

1

นั่นเป็นตัวอย่างที่ดีในช่วงเวลาหนึ่งที่น่าจะเป็นความคิดที่ดี

— Kevin

11

กรณีหนึ่งที่ฉันพบบางครั้งก็เป็นเช่นนี้:

ตารางcountries_idมีเพียงคอลัมน์เดียวที่มีรหัสตัวเลขสำหรับแต่ละประเทศ

ตารางcountries_descriptionประกอบด้วยคอลัมน์ที่มีรหัสประเทศคอลัมน์ที่มีรหัสภาษาและคอลัมน์ที่มีชื่อประเทศที่แปลแล้ว

ตารางcompany_factoriesมีข้อมูลสำหรับโรงงานแต่ละแห่งของ บริษัท รวมถึงประเทศใน Wich ที่ตั้งอยู่

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

ในกรณีนี้ฉันคิดว่าการมีอยู่ของตารางคอลัมน์เดียวนั้นเป็นธรรม

แก้ไขตามความคิดเห็นโดย: Quassnoi

_{(ที่มา: ggpht.com )}

ในสคีมานี้ฉันสามารถกำหนดคีย์ต่างประเทศในตาราง company_factories ที่ไม่ต้องการให้ฉันรวมคอลัมน์ภาษาในตาราง แต่ถ้าฉันไม่มีตาราง countries_id ฉันต้องรวมคอลัมน์ภาษาในตารางเพื่อกำหนดคีย์ต่างประเทศ .

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

2

ทำไมต้องมี countries_id ในการแทรกประเทศคุณจำเป็นต้องทราบชื่อในภาษาอย่างน้อยหนึ่งภาษาและจะส่งผลให้ country_id ปรากฏใน countries_description country_id ที่ไม่มีรายการ countries_description จะไม่มีความหมาย "Mr. Barack Obama, President of COALESCE (14243, country_name) RETURNED NULL VALUE, วันนี้พบกับ Dmitry Medvedev, President of Россия"

— Quassnoi

4

@ Doliveras: ตกลงฉันเห็นแล้ว +1 อย่างไรก็ตามฉันควรใช้ ISO 3166-1 สำหรับ coutry_code ซึ่งแตกต่างจากรหัสตัวเลขรหัสประเทศ 3 ตัวอักษรให้ความคิดว่าคนเกือบทุกคนในโลกกล่าวถึงประเทศใดที่สามารถอ่านอักษรละตินได้

— Quassnoi

นี่เป็นอีกวิธีหนึ่งที่ฉันใช้เพื่อรองรับการแปลภาษาธรรมชาติในตารางเดียวกัน จริงอยู่ที่ผลลัพธ์หลายฟิลด์เป็นโมฆะ แต่คุณสามารถถ่ายโอนความสมบูรณ์ของข้อมูลไปยังทริกเกอร์ที่กำหนดเองได้ สร้างตาราง "DBA" "myLocalisedTable" ( "entry_id" จำนวนเต็มไม่เป็นโมฆะ DEFAULT AUTOINCREMENT "master_entry_id" จำนวนเต็มโมฆะ "master_entry_label" VARCHAR (200) โมฆะ "language_id" จำนวนเต็มโมฆะ "localised_entry_label" VARCHAR (300) โมฆะ.

— Vincent Buck

7

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

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

— Jeremy Bourque
แหล่งที่มา

5

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

ฉันนึกถึงการใช้ตารางคอลัมน์เดียว OTMH สองแบบ:

1) มีรายการข้อมูล มักใช้ในรายการแบบเลื่อนลง ใช้สำหรับการทดสอบความถูกต้องตามกฎหมายอย่างง่าย

เช่น. ตัวย่อรัฐของสหรัฐอเมริกาสองตัวอักษร รหัสไปรษณีย์ที่เราจัดส่งไป; คำกฎหมายใน Scrabble; เป็นต้น

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

เช่น. พนักงานที่เป็นโรคระยะสุดท้าย ธนาคารที่มีอายุ 360 วัน (ส่วนใหญ่ใช้ 365) เป็นต้น

อัล

— AI Breveleri
แหล่งที่มา

4

ไม่มีปัญหาตราบใดที่มีค่าที่ไม่ซ้ำกัน

— Agnel Kurian
แหล่งที่มา

4

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

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

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

— Stealth Rabbi

2

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

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

ฉันเคยเห็นตารางตัวเลขที่ใช้อย่างมีประสิทธิภาพในอดีต

— เบรนแดนเอ็นริก
แหล่งที่มา

1

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

บางทีนี่อาจเป็นตารางการรวบรวม (เช่น FirstName + LastName + Birthdate) แต่ฉันยังไม่แน่ใจว่าทำไมคุณถึงต้องการทำเช่นนั้น

แก้ไข: ฉันเห็นการใช้ตารางประเภทนี้สำหรับรายการง่ายๆบางประเภท นั่นคือสิ่งที่คุณใช้เพื่อ?

— Matthew Jones
แหล่งที่มา

9

ไม่วัตถุประสงค์หลักของฐานข้อมูลคือการจัดเก็บข้อมูล

— Spencer Ruport

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

— Matthew Jones

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

— Mark Brittingham

@ มาร์ค - นั่นคือสิ่งที่ฉันหมายถึงโดยรายการง่ายๆ เดาว่าฉันอธิบายตัวเองไม่เก่ง

— Matthew Jones

1

@SR - ไม่วัตถุประสงค์หลักของฐานข้อมูลคือการดึงข้อมูล เนื่องจากแถวที่สนใจมักจะไม่ขึ้นอยู่กับข้อมูลอื่น ๆ ฉันจึงคิดว่าความคิดเห็นดั้งเดิมของ MJ นั้นมีความหมาย

— CurtainDog

1

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

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

2

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

— Erik Funkenbusch

1

โดย "ไม่ทำงาน" เขาอาจหมายถึง "ไม่ทำงานตามที่คาดไว้" ซึ่งครอบคลุมเงื่อนไข "เฮ้ฉันลบหนึ่งแถว แต่ทั้งคู่หายไป"

— GWLlosa

หรือหากคุณพยายามลบระเบียนใน SSMS จากมุมมอง "Open Table" มันจะแสดงกล่องโต้ตอบที่ไม่สามารถระบุระเบียนแบบไม่ซ้ำกันได้จากนั้นไม่ทำอะไรเลย ...

— Michael Fredrickson

-1

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

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

ดังนั้นแม้ว่าจะไม่ผิดกฎหมาย แต่โดยทั่วไปคุณอาจไม่ควรมีตารางที่มีเพียงคอลัมน์เดียว

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

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

— u07ch

-1

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

1

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

— Josh Noe

-2

ใช่ว่าจะดีอย่างสมบูรณ์แบบ แต่ช่อง ID ไม่สามารถทำร้ายได้ใช่ไหม

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

7

จริงๆแล้วมันทำได้ เมื่อคุณมีรายการค่าที่ถูกต้องสุดท้ายสิ่งสุดท้ายที่คุณต้องการคือฟิลด์ ID เนื่องจากหมายความว่าค่านั้นไม่ซ้ำกัน หาก 'LightBlue' เป็นกุญแจสำคัญคุณไม่ต้องการให้ใครบางคนคิดว่า 'LightBlue' กับ id 1 อาจแตกต่างจาก 'LightBlue' กับ id 4

— Jeremy Bourque

ใครบอกว่า Id ต้องเป็นตัวตน? หรือเป็นส่วนหนึ่งของคีย์?

— Eric

3

อาจเป็นคีย์สังเคราะห์และฟิลด์ดั้งเดิมอาจมีข้อ จำกัด เฉพาะ

— Mark Canlas