ทำไมฐานข้อมูลเชิงสัมพันธ์ไม่สนับสนุนข้อมูลที่ส่งคืนในรูปแบบที่ซ้อนกัน?

สมมติว่าฉันกำลังสร้างบล็อกที่ฉันต้องการโพสต์และแสดงความคิดเห็น ดังนั้นฉันจึงสร้างสองตารางตาราง 'โพสต์' ที่มีคอลัมน์ 'id' จำนวนเต็มโดยอัตโนมัติและตาราง 'ความคิดเห็น' ที่มีคีย์ต่างประเทศ 'post_id'

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

SELECT id, content, (SELECT * FROM comments WHERE post_id = 7) AS comments
FROM posts
WHERE id = 7

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

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

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

(ข้อจำกัดความรับผิดชอบ: ฉันมักจะเขียน webapps โดยใช้ Rails และ NoSQL datastores แต่เมื่อเร็ว ๆ นี้ฉันได้ลองใช้ Postgres และฉันชอบมันมากจริง ๆ ฉันไม่ได้ตั้งใจจะโจมตีฐานข้อมูลเชิงสัมพันธ์ฉันแค่สับสน)

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

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

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

ข้อความค้นหาข้อ จำกัด และการอัปเดตมีความซับซ้อนยากต่อการเขียนและยากขึ้นสำหรับ RDBMS ที่จะสนับสนุนหากคุณอนุญาตแอตทริบิวต์ที่มีค่าความสัมพันธ์ (RVA)

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

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

จากสิ่งที่ฉันเข้าใจ (ฉันไม่ได้ใช้) RelและDataphorเป็นโครงการ RDBMS ที่สนับสนุนแอตทริบิวต์ที่มีค่าความสัมพันธ์

ความคิดเห็นอีกครั้งจาก @dportas:

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

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

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

ยังมีตัวอย่างบางส่วนของระบบฐานข้อมูลแบบลำดับชั้นใน wild โดยเฉพาะ windows registry และ LDAP

ครอบคลุมเรื่องนี้อย่างกว้างขวางในบทความต่อไปนี้

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

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

ฉันไม่เห็นสิ่งใดที่ไม่มีประสิทธิภาพในการส่ง 2 ข้อความค้นหาและรับผลลัพธ์ 2 ชุดด้วย:

--- Query-1-posts
SELECT id, content 
FROM posts
WHERE id = 7


--- Query-2-comments
SELECT * 
FROM comments 
WHERE post_id = 7

ฉันขอยืนยันว่า (เกือบ) วิธีที่มีประสิทธิภาพมากที่สุด (เกือบเพราะคุณไม่ต้องการposts.idและไม่ใช่คอลัมน์ทั้งหมดcomments.*)

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

ฉันไม่สามารถพูดเกี่ยวกับ ORM ได้จริงๆ แต่บางทีพวกเขาบางคนสามารถทำหน้าที่นี้ให้เราได้

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

ฉันเดาว่ามาตรฐานเช่น SQL นั้นดีที่สุดหากพวกเขามีความเชี่ยวชาญในด้านเดียวและไม่พยายามครอบคลุมทุกสาขา

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

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

ฉันรู้ว่าอย่างน้อย SQLServer รองรับการสืบค้นซ้อนเมื่อคุณใช้สำหรับ XML

SELECT id, content, (SELECT * FROM comments WHERE post_id = posts.id FOR XML PATH('comments'), TYPE) AS comments
FROM posts
WHERE id = 7
FOR XML PATH('posts')

ปัญหาที่นี่ไม่ใช่การขาดการสนับสนุนจาก RDBMS แต่ขาดการสนับสนุนตารางที่ซ้อนกันในตาราง

นอกจากสิ่งที่ห้ามไม่ให้คุณใช้การเข้าร่วมภายใน

SELECT id, content, comments.*
FROM posts inner join comments on comments.post_id = posts.id
WHERE id = 7

คุณสามารถดูการรวมภายในเป็นตารางที่ซ้อนกันได้เฉพาะเนื้อหาของ 2 ฟิลด์แรกเท่านั้นที่สามารถทำซ้ำได้ ฉันไม่ต้องกังวลเกี่ยวกับประสิทธิภาพของการเข้าร่วมมากนักส่วนที่ช้าในแบบสอบถามเช่นนี้คือ io จากฐานข้อมูลไปยังไคลเอนต์ นี่จะเป็นปัญหาเมื่อเนื้อหามีข้อมูลจำนวนมาก ในกรณีที่ว่าผมจะแนะนำให้ทั้งสองคำสั่งหนึ่งที่มีและเป็นหนึ่งเดียวกับภายในเข้าร่วมและselect id, content select posts.id, comments.*สิ่งนี้จะปรับขยายได้แม้จะมีการโพสต์หลายโพสต์เนื่องจากคุณจะยังคงใช้การค้นหา 2 รายการเท่านั้น

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

SELECT id, content, cursor(SELECT * FROM comments WHERE post_id = 7) AS comments
FROM posts
WHERE id = 7

บางคนสนับสนุนการซ้อน (แบบลำดับชั้น)

หากคุณต้องการหนึ่งแบบสอบถามคุณสามารถมีหนึ่งตารางที่ตนเองอ้างอิงเอง RDMS บางรุ่นรองรับแนวคิดนี้ ตัวอย่างเช่นกับ SQL Server หนึ่งสามารถผู้ใช้ Common Table Expressions (CTEs) สำหรับแบบสอบถามแบบลำดับชั้น

ในกรณีของคุณโพสต์จะอยู่ที่ระดับ 0 จากนั้นความคิดเห็นทั้งหมดจะอยู่ที่ระดับ 1

ตัวเลือกอื่นคือ 2 ข้อความค้นหาหรือเข้าร่วมกับข้อมูลพิเศษบางอย่างสำหรับทุกระเบียนที่ส่งคืน (ที่คนอื่นพูดถึง)

ตัวอย่างของลำดับชั้น:

https://stackoverflow.com/questions/14274942/sql-server-cte-and-recursion-example

ในลิงค์ด้านบน EmpLevel แสดงระดับของการซ้อน (หรือลำดับชั้น)

ฉันขอโทษฉันไม่แน่ใจว่าฉันเข้าใจปัญหาของคุณอย่างแน่นอน

ใน MSSQL คุณสามารถรันคำสั่ง SQL 2 คำสั่งได้

SELECT id, content
FROM posts
WHERE id = 7

SELECT * FROM comments WHERE post_id = 7

และจะส่งคืนผลลัพธ์ 2 ชุดพร้อมกัน

RDBMs ตั้งอยู่บนพื้นฐานของทฤษฎีและพวกเขายึดติดกับทฤษฎี สิ่งนี้ทำให้ความสอดคล้องที่ดีและความน่าเชื่อถือที่ได้รับการพิสูจน์ทางคณิตศาสตร์

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

มีความพยายามในอดีตที่จะสร้างฐานข้อมูลแบบลำดับชั้น แต่ IIRC (ดูเหมือนจะไม่ google) มีปัญหา (รอบและความเสมอภาคมาถึงใจ)

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

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

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

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

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

แน่นอน PostgreSQL มีคุณสมบัติบางอย่างจากฐานข้อมูลเชิงวัตถุ ตามอีเมลนี้ ( ข้อความ ) คุณสามารถบรรลุสิ่งที่คุณต้องการโดยการสร้างการรวมที่กำหนดเอง

โดยส่วนตัวแล้วฉันใช้เฟรมเวิร์กเช่น Doctrine ORM (PHP) ซึ่งทำหน้าที่รวมแอพพลิเคชั่นด้านข้างและฟีเจอร์สนับสนุนเช่น lazy-loading เพื่อเพิ่มประสิทธิภาพ

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