เหตุใด RDBMS จึงไม่ส่งคืนตารางที่เข้าร่วมในรูปแบบที่ซ้อนกัน

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

SELECT * FROM users user 
    LEFT JOIN emails email ON email.user_id=user.id
    LEFT JOIN phones phone ON phone.user_id=user.id

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

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

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

เราสามารถแก้ไขได้โดยใช้ NoSQL แต่ไม่ควรมีพื้นกลางบ้าง

ฉันพลาดอะไรไปรึเปล่า? ทำไมจึงไม่มีสิ่งนี้

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

ฉันรู้ว่านี้สามารถทำได้ในภาษาสคริปต์ที่คุณเลือก แต่ต้องว่าเซิร์ฟเวอร์ SQL ทั้งส่งข้อมูลซ้ำซ้อน (ตัวอย่างด้านล่าง) SELECT email FROM emails WHERE user_id IN (/* result of first query */)หรือว่าคุณจะออกคำสั่งหลายตัวเช่น

แทนที่จะให้ MySQL คืนสิ่งที่คล้ายกับนี้:

[
    {
        "name": "John Smith",
        "dob": "1945-05-13",
        "fav_color": "red",
        "email": "johnsmith45@gmail.com",
    },
    {
        "name": "John Smith",
        "dob": "1945-05-13",
        "fav_color": "red",
        "email": "john@smithsunite.com",
    },
    {
        "name": "Jane Doe",
        "dob": "1953-02-19",
        "fav_color": "green",
        "email": "originaljane@deerclan.com",
    }
]

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

[
    {
        "name": "John Smith",
        "dob": "1945-05-13",
        "fav_color": "red",
        "emails": ["johnsmith45@gmail.com", "john@smithsunite.com"]
    },
    {
        "name": "Jane Doe",
        "dob": "1953-02-19",
        "fav_color": "green",
        "emails": ["originaljane@deerclan.com"],
    }
]

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

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

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

ดังที่กล่าวมาสิ่งนี้ช่วยให้สามารถทำการปรับแต่งบางอย่างได้อย่างสมบูรณ์ (ดัชนีเข้าร่วมสหภาพ ฯลฯ ... )

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

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

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

นอกจากนี้ยังมีประวัติการทำงานที่นี่ การถ่ายโอนข้อมูลที่มีโครงสร้างเป็นสิ่งที่น่าเกลียดในสมัยก่อน ดูรูปแบบ EDI เพื่อรับความคิดเกี่ยวกับสิ่งที่คุณอาจขอ ต้นไม้หมายถึงการเรียกซ้ำ - ซึ่งภาษาบางภาษาไม่สนับสนุน (สองภาษาที่สำคัญที่สุดของวันเก่าไม่สนับสนุนการเรียกซ้ำ - การเรียกซ้ำไม่ได้เข้าสู่ Fortran จนกระทั่ง F90และ COBOL ในยุคนั้นไม่ได้เป็นอย่างนั้น)

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

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

12. ในการออกแบบโปรโตคอลความสมบูรณ์แบบนั้นไม่ได้มาถึงเมื่อไม่มีอะไรเหลือให้เพิ่ม แต่เมื่อไม่มีอะไรเหลือให้นำออกไป

จากRFC 1925 - ความจริงด้านเครือข่ายสิบสอง

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

สิ่งที่คุณกำลังประสบอยู่เรียกว่า " Object / Relational Impedance Mismatch " ปัญหาทางเทคนิคที่เกิดขึ้นจากข้อเท็จจริงที่ว่าตัวแบบข้อมูลเชิงวัตถุและตัวแบบข้อมูลเชิงสัมพันธ์นั้นมีความแตกต่างกันหลายประการ LINQ และเฟรมเวิร์กอื่น ๆ (รู้จักกันในชื่อ ORMs, Object / Relational Mappers, ไม่เกิดขึ้นโดยบังเอิญ,) ไม่น่าอัศจรรย์ "หลีกเลี่ยงสิ่งนี้" พวกเขาเพียงแค่ออกแบบสอบถามที่แตกต่างกัน มันสามารถทำได้ใน SQL ด้วย นี่คือวิธีที่ฉันจะทำ:

SELECT * FROM users user where [criteria here]

วนซ้ำรายการผู้ใช้และสร้างรายการ ID

SELECT * from EMAILS where user_id in (list of IDs here)
SELECT * from PHONES where user_id in (list of IDs here)

แล้วคุณก็เข้าร่วมฝั่งลูกค้า นี่คือวิธีที่ LINQ และกรอบงานอื่นทำ ไม่มีเวทย์มนตร์ที่เกี่ยวข้อง แค่ชั้นของสิ่งที่เป็นนามธรรม

คุณสามารถใช้ฟังก์ชันที่มีอยู่แล้วภายในเพื่อเชื่อมข้อมูลเข้าด้วยกัน ใน MySQL คุณสามารถใช้GROUP_CONCAT()ฟังก์ชันและใน Oracle คุณสามารถใช้LISTAGG()ฟังก์ชันได้

นี่คือตัวอย่างของแบบสอบถามที่อาจมีลักษณะเป็นใน MySQL:

SELECT user.*, 
    (SELECT GROUP_CONCAT(DISTINCT emailAddy) FROM emails email WHERE email.user_id = user.id
    ) AS EmailAddresses,
    (SELECT GROUP_CONCAT(DISTINCT phoneNumber) FROM phones phone WHERE phone.user_id = user.id
    ) AS PhoneNumbers
FROM users user 

สิ่งนี้จะส่งคืนสิ่งที่ต้องการ

username    department       EmailAddresses                        PhoneNumbers
Tim_Burton  Human Resources  hr@m.com, tb@me.com, nunya@what.com   231-123-1234, 231-123-1235

ปัญหานี้คือการคืนชื่อผู้ใช้ DOB สีที่ชอบและข้อมูลอื่น ๆ ทั้งหมดที่เก็บไว้

ปัญหาคือคุณไม่ได้เลือกอย่างเพียงพอ คุณขอทุกสิ่งเมื่อคุณพูด

Select * from...

... และคุณได้รับมัน (รวมถึง DOB และสีที่ชอบ)

คุณน่าจะได้มากกว่านี้ (อะแฮ่ม) ... เลือกแล้วพูดว่า:

select users.name, emails.email_address, phones.home_phone, phones.bus_phone
from...

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

select distinct users.name, emails.email_address, phones.home_phone, phones.bus_phone
from...

... ซ้ำแล้วซ้ำอีกสำหรับแต่ละระเบียน ...

LEFT JOINนอกจากนี้ผมสังเกตเห็นว่าคุณกำลังทำ นี่จะเข้าร่วมบันทึกทั้งหมดทางด้านซ้ายของการเข้าร่วม (เช่นusers) ไปยังระเบียนทั้งหมดทางด้านขวาหรือในคำอื่น ๆ :

การรวมภายนอกด้านซ้ายส่งกลับค่าทั้งหมดจากการรวมภายในและค่าทั้งหมดในตารางด้านซ้ายที่ไม่ตรงกับตารางด้านขวา

( http://en.wikipedia.org/wiki/Join_(SQL)#Left_outer_join )

ดังนั้นคำถามอื่นคือคุณต้องการเข้าร่วมซ้ายจริง ๆหรือจะINNER JOINเพียงพอหรือไม่ พวกเขาเป็นประเภทที่แตกต่างกันมากเข้าร่วม

จะไม่ดีกว่าถ้ามันส่งคืนแถวเดียวสำหรับผู้ใช้แต่ละรายและภายในบันทึกนั้นมีรายการอีเมล

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

ในที่สุดฉันคิดว่าปัญหาของคุณอาจได้รับการแก้ไขถ้าคุณเขียนข้อความค้นหาของคุณใกล้เคียงกับสิ่งนี้:

select distinct users.name, users.id, emails.email_address, phones.phone_number
from users
  inner join emails on users.user_id = emails.user_id
  inner join phones on users.user_id = phones.user_id

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

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

เพื่อให้ได้สิ่งที่คุณต้องการคุณต้องใช้แบบสอบถามแยกต่างหากเช่น Mason Wheeler อธิบาย

select * from Phones where user_id=344;

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

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

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

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

ปัญหาที่ 2 แบบสอบถามที่แตกต่างกันแทนที่จะเป็นแบบสอบถามที่มีการเข้าร่วม

ในโพรซีเดอร์ที่เก็บไว้หรืออินไลน์ parameterized sql craft 2 เคียวรีและส่งคืนผลลัพธ์ของทั้งสองแบ็ก ฐานข้อมูลและภาษาส่วนใหญ่รองรับชุดผลลัพธ์หลายชุด

ยกตัวอย่างเช่น SQL Server และ C # IDataReader.NextResult()บรรลุฟังก์ชั่นนี้โดยใช้

คุณขาดอะไรไป หากคุณต้องการทำให้ข้อมูลของคุณเป็นปกติคุณต้องทำเอง

;with toList as (
    select  *, Stuff(( select ',' + (phone.phoneType + ':' + phone.PhoneNumber) 
                    from phones phone
                    where phone.user_id = user.user_id
                    for xml path('')
                  ), 1,1,'') as phoneNumbers
from users user
)
select *
from toList

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

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

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

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

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

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