ฉันจะรู้ได้อย่างไรว่าข้อมูลของฉันมีความสัมพันธ์หรือเชิงวัตถุโดยธรรมชาติ

แค่อ่านบรรทัดเหล่านี้ -

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

• หากข้อมูลของคุณเป็นแบบเชิงสัมพันธ์ค่าใช้จ่ายของฐานข้อมูลเชิงสัมพันธ์จะคุ้มค่า

จาก-

http://seldo.com/weblog/2011/06/15/orm_is_an_antipattern

ดังนั้นฉันจะรู้ได้อย่างไรว่าข้อมูลของฉันสัมพันธ์ในลักษณะเชิงวัตถุหรือไม่?

เมื่อเสี่ยงต่อการถูกยิงเป็นชิ้น ๆ ฉันจะลองใช้คำจำกัดความภาษาอังกฤษธรรมดา ๆ

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

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

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

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

ข้อมูลมีทั้ง

(การพูดอย่างเคร่งครัดมันไม่สามารถคัดค้านในธรรมชาติได้เพราะมันขาดพฤติกรรม แต่เราจะไม่ทำแบบนี้)

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

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

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

แน่นอนคุณสามารถจัดเก็บข้อมูลได้ทั้งสองกรณีด้วยเหตุผลต่าง ๆ แต่มีข้อเสียของตัวเอง

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

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

ฉันคิดว่าบรรทัดสำคัญจากบทความคือ:

"Likewise, sometimes the output will be a single object X, which is easy to represent. But sometimes the output will be a grid of aggregate data, or a single integer count"

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

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