เคยใช้รายการในฐานข้อมูลเชิงสัมพันธ์หรือไม่?

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

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

แน่นอนถ้าฉันบันทึกงานเหล่านี้ทีละรายการใน "บุคคล" ฉันจะต้องมีคอลัมน์ "TaskID" หลอกตานับสิบ ๆ ตัวและจัดการแบบไมโครเพราะจะมีงานมอบหมายให้บุคคลหนึ่งถึง 0 ถึง 100

จากนั้นอีกครั้งถ้าฉันบันทึกงานในตาราง "งาน" ฉันจะต้องมีคอลัมน์ "PersonID" หลอกตานับสิบ ๆ ตัวและจัดการกับมันแบบไมโคร - ปัญหาเช่นเดียวกับเมื่อก่อน

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

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

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

ตัวอย่างคุณมีตารางต่อไปนี้:

บุคคล:

+ ---- + ----------- +
| ID | ชื่อ |
+ + ==== =========== +
| 1 | อัลเฟรด
| 2 | Jebediah |
| 3 | ยาโคบ |
| 4 | เอเสเคียล
+ ---- + ----------- +

งาน:

+ ---- + -------------------- +
| ID | ชื่อ |
+ + ==== ==================== +
| 1 | เลี้ยงไก่
| 2 | ไถ
| 3 | รีดนมวัว
| 4 | ยกยุ้งฉาง
+ ---- + -------------------- +

จากนั้นคุณจะสร้างตารางที่สามด้วยการมอบหมาย ตารางนี้จะเป็นแบบจำลองความสัมพันธ์ระหว่างบุคคลและงาน:

+ ---- + ----------- + --------- +
| ID | PersonId | TaskId |
+ + ==== =========== + + =========
| 1 | 1 | 3 |
| 2 | 3 | 2 |
| 3 | 2 | 1 |
| 4 | 1 | 4 |
+ ---- + ----------- + --------- +

จากนั้นเราจะมีข้อ จำกัด Foreign Key เช่นว่าฐานข้อมูลจะบังคับให้ PersonId และ TaskIds ต้องเป็น ID ที่ถูกต้องสำหรับรายการต่างประเทศเหล่านั้น สำหรับแถวแรกเราจะเห็นPersonId is 1ดังนั้นอัลเฟรดได้รับมอบหมายให้TaskId 3, วัวรีดนม

สิ่งที่คุณควรเห็นที่นี่คือคุณมีงานมอบหมายน้อยหรือมากตามที่คุณต้องการ ในตัวอย่างนี้เอเสเคียลไม่ได้มอบหมายงานใด ๆ และอัลเฟรดได้รับมอบหมาย 2 หากคุณมีงานหนึ่งงานที่มี 100 คนการดำเนินการSELECT PersonId from Assignments WHERE TaskId=<whatever>;จะให้ผล 100 แถวพร้อมด้วยบุคคลที่แตกต่างหลากหลายที่ได้รับมอบหมาย คุณสามารถWHEREบน PersonId เพื่อค้นหางานทั้งหมดที่มอบหมายให้กับบุคคลนั้น

หากคุณต้องการส่งคืนเคียวรีที่แทนที่ Id ด้วยชื่อและภารกิจคุณจะได้เรียนรู้วิธีเข้าร่วมตาราง

คุณถามคำถามสองข้อที่นี่

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

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

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

create table person (
    person_id integer primary key,
    ...
);

create table task (
    task_id integer primary key,
    ...
);

create table person_task_xref (
    person_id integer not null,
    task_id integer not null,
    primary key (person_id, task_id),
    foreign key (person_id) references person (person_id),
    foreign key (task_id) references task (task_id)
);

... ไม่เป็นไร (หรือแทบจะไม่เคย) ตกลงที่จะเก็บรายการ ID หรือสิ่งที่ชอบในฟิลด์

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

เนื่องจาก "รายการ" คือตามคำนิยามประกอบด้วยองค์ประกอบขนาดเล็ก (รายการ) นี่ไม่ใช่กรณีที่นี่และคุณควรทำให้ข้อมูลเป็นมาตรฐาน

... ถ้าฉันบันทึกงานเหล่านี้ทีละรายการใน "บุคคล" ฉันจะต้องมีคอลัมน์ "TaskID" หลอกตานับสิบ ...

ไม่คุณจะมีแถวสองสามแถวใน Intersection Table (aka Weak Entity) ระหว่างบุคคลและภารกิจ ฐานข้อมูลทำงานได้ดีกับแถวจำนวนมาก จริงๆแล้วพวกเขาค่อนข้างขยะที่ทำงานกับคอลัมน์ [ซ้ำ] จำนวนมาก

ตัวอย่างชัดเจนดีที่กำหนดโดย whatsisname

มันอาจถูกต้องตามกฎหมายในบางฟิลด์ที่คำนวณล่วงหน้า

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

ตัวอย่างเช่นใน UI ที่คุณต้องการแสดงรายการนี้โดยใช้มุมมองกริดซึ่งแต่ละแถวสามารถเปิดรายละเอียดทั้งหมด (พร้อมรายการทั้งหมด) หลังจากดับเบิลคลิก:

REGISTERED USER LIST
+------------------+----------------------------------------------------+
|Name              |Top 3 most visited tags                             |
+==================+====================================================+
|Peter             |Design, Fitness, Gifts                              |
+------------------+----------------------------------------------------+
|Lucy              |Fashion, Gifts, Lifestyle                           |
+------------------+----------------------------------------------------+

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

คุณสามารถทำให้ฟิลด์นั้นพร้อมใช้งานได้แม้จะค้นหา (เป็นข้อความปกติ)

สำหรับกรณีดังกล่าวการเก็บรักษารายการนั้นถูกต้องตามกฎหมาย คุณเพียงแค่ต้องคำนึงถึงตัวพิมพ์ใหญ่กว่าความยาวฟิลด์สูงสุด

นอกจากนี้หากคุณใช้ Microsoft Access เขตข้อมูลที่มีหลายค่าเป็นกรณีการใช้งานพิเศษอีกกรณีหนึ่ง พวกเขาจัดการรายการของคุณในเขตข้อมูลโดยอัตโนมัติ

แต่คุณสามารถถอยกลับไปใช้แบบฟอร์มมาตรฐานปกติที่แสดงในคำตอบอื่น

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

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

รับสองตาราง; เราจะเรียกพวกเขาว่า Person and Task โดยแต่ละอันจะมี ID ของตัวเอง (PersonID, TaskID) ... แนวคิดพื้นฐานคือการสร้างตารางที่สามเพื่อผูกเข้าด้วยกัน เราจะเรียกตารางนี้ว่า PersonToTask อย่างน้อยที่สุดมันควรมี ID ของตัวเองเช่นเดียวกับอีกสองคนดังนั้นเมื่อมันมาถึงการมอบหมายงานให้ใครบางคน คุณจะไม่จำเป็นต้องอัปเดตตารางบุคคลอีกต่อไปคุณเพียงแค่แทรกบรรทัดใหม่ใน PersonToTaskTable และการบำรุงรักษาง่ายขึ้น - ต้องลบงานเพียงแค่ลบตาม TaskID ไม่ต้องอัปเดตตารางบุคคลและเชื่อมโยงกับการแยกวิเคราะห์

CREATE TABLE dbo.PersonToTask (
    pttID INT IDENTITY(1,1) NOT NULL,
    PersonID INT NULL,
    TaskID   INT NULL
)

CREATE PROCEDURE dbo.Task_Assigned (@PersonID INT, @TaskID INT)
AS
BEGIN
    INSERT PersonToTask (PersonID, TaskID)
    VALUES (@PersonID, @TaskID)
END

CREATE PROCEDURE dbo.Task_Deleted (@TaskID INT)
AS
BEGIN
    DELETE PersonToTask  WHERE TaskID = @TaskID
    DELETE Task          WHERE TaskID = @TaskID
END

วิธีการเกี่ยวกับรายงานอย่างง่ายหรือผู้ที่ได้รับมอบหมายให้ทำงาน

CREATE PROCEDURE dbo.Task_CurrentAssigned (@TaskID INT)
AS
BEGIN
    SELECT PersonName
    FROM   dbo.Person
    WHERE  PersonID IN (SELECT PersonID FROM dbo.PersonToTask WHERE TaskID = @TaskID)
END

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

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

------------------------  
Employee Name | Task 
Jack          |  1,2,5
Jill          |  4,6,7
------------------------

------------------------  
Employee Name | Task 
Jack          |  1
Jack          |  2
Jack          |  5
Jill          |  4
Jill          |  6
Jill          |  7
------------------------

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

ตัวอย่างเช่นการเปรียบเทียบเวลาที่ใช้ในการเรียกคืน 2 แถวเทียบกับการเรียกใช้แบบสอบถามที่จะสร้าง 2 แถว หากใช้เวลานานและผู้ใช้ไม่ต้องการรายการที่เป็นปัจจุบันมากที่สุด (* คาดว่าจะมีการเปลี่ยนแปลงน้อยกว่า 1 รายการต่อวัน) ก็สามารถจัดเก็บได้

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

คุณกำลังทำอะไรควรอยู่ในตารางอื่นหมุนมันผ่าน 90 องศาแล้วเปลี่ยนเป็นอีกโต๊ะ

มันเหมือนกับการมีตารางการสั่งซื้อที่คุณมี itemProdcode1, itemQuantity1, itemPrice1 ... itemProdcode37, itemQuantity37, itemPrice37 นอกเหนือจากความงุ่มง่ามในการจัดการโดยทางโปรแกรมคุณสามารถรับประกันได้ว่าพรุ่งนี้ใครบางคนจะต้องการสั่งซื้อ 38 สิ่ง

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

ดังนั้นคำสั่งซื้อคือรายการ Bill of Materials จึงเป็นรายการ (หรือรายการของรายการซึ่งจะเป็นฝันร้ายที่จะนำ "ไซด์เวย์" ไปใช้) แต่โน้ต / ความคิดเห็นและบทกวีไม่ใช่

ถ้ามันเป็น "ไม่ตกลง" มันก็ค่อนข้างเลวร้ายที่ทุกเว็บไซต์ Wordpress เคยมีรายการใน wp_usermeta ที่มี wp_capabilities ในแถวเดียว, ไล่รายการลิสต์ในแถวหนึ่งและอื่น ๆ ...

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