ศาสตราจารย์บอกให้เราจัดเก็บวัตถุ Java ต่อเนื่องเป็น blobs แทนที่จะกำหนดตารางเชิงสัมพันธ์

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

id (int)  |   Serialized Object (blob)
   1               10010110110

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

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

หลักสูตรการตั้งชื่อการออกแบบซอฟแวร์

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

ตัวแบบไม่ได้มีการเคลื่อนไหว แต่อย่างใด

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

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

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

- การแก้ไขหลังจากอ่านคำตอบอื่น ๆ

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

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

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

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

ตอนนี้คุณมีสองตัวเลือกพื้นฐาน:

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

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

คำตอบของ Justin Cave บอกว่าคุณควรเลือกตัวเลือกที่สอง ฉันคิดว่านี่จะเป็นความผิดพลาดครั้งใหญ่

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

ที่จริงแล้วปัญหาของวัตถุ Java ที่ทำเป็นอนุกรมในฐานข้อมูลเชิงสัมพันธ์นั้นลึกกว่าที่คิด มันสัมผัสกับแกนหลักของ 1NF คือ โดเมนของแอตทริบิวต์คืออะไร . หากคุณมีความสนใจจริงๆในหัวข้อที่มีบทความดีดีโดย CJ วันของเขาในวันที่ในฐานข้อมูลงานเขียน 2000-2006

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

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

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

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

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

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

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

มีประโยชน์ในการทำสิ่งนี้ที่ฉันไม่ได้คิด?

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

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

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

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

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

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

Justin Cave ถูกต้องว่าสิ่งนี้สามารถนำไปสู่ข้อมูลที่ซ้ำซ้อน แต่ขึ้นอยู่กับวิธีการออกแบบฐานข้อมูลของคุณ

วิธีการซีเรียลไลซ์วัตถุทั้งหมดให้เป็นหยดนั้นไม่เป็นเรื่องอุกอาจเหมือนคนส่วนใหญ่ที่คิดว่าเป็น ในความเป็นจริงสำหรับบางโปรแกรมนี้สามารถออกแบบที่ดีที่สุดที่คุณสามารถทำตามที่ผมอธิบายที่นี่: /programming//a/12644223/1121352

อันที่จริงการทำให้วัตถุเป็นอนุกรมทำให้เกิดประโยชน์อย่างน้อยสองอย่าง:

1- ลดความต้านทานไม่ตรงกัน : Java บางประเภทไม่สามารถใช้ได้ใน SQL โดยเฉพาะถ้าคุณใช้คลาสและประเภทที่กำหนดเองจำนวนมากดังนั้นการแปลงไปมาจากวัตถุ Java ไปเป็น SQL อาจทำให้เกิดความยุ่งยากอย่างมาก

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

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

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

ในฐานะที่เป็นบันทึกด้านข้างมีความพยายามไม่กี่ครั้งจากผู้สร้าง DB บางคนในการผสมผสานความสัมพันธ์และโมเดลวัตถุเข้าด้วยกันเช่นประเภทข้อมูล JSON ในPostSQLและ PostgreSQL เพื่อให้คุณสามารถประมวลผล JSON ได้โดยตรงเช่นคอลัมน์เชิงสัมพันธ์ใด ๆ และ SQL3 และ OQL Query Language) เพื่อเพิ่มวัตถุ (จำกัด ) ที่รองรับลงใน SQL

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

/ แก้ไขหลังจากอ่านความคิดเห็น: แน่นอนถ้าข้อมูลของคุณต้องสามารถค้นหาได้ ("queryable") คุณไม่ควรจัดเก็บข้อมูลของคุณเป็นหยด แต่ถ้าบางส่วนของข้อมูลของคุณไม่ได้หมายถึงสามารถค้นหาได้แต่เป็น meta-data บางชนิดดังนั้นการจัดเก็บข้อมูลส่วนนี้เป็นวัตถุภายใน blob อาจเป็นทางออกที่ดีโดยเฉพาะถ้า meta-data มีโครงสร้างที่ยืดหยุ่น และสามารถเปลี่ยนจากวัตถุเป็นวัตถุ

เรามาดูตัวอย่างการปฏิบัติกันเมื่อฉันได้ทำสิ่งนี้ในอดีต

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

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

• ประการแรกถ้าสิ่งนี้ล้มเหลวก็ไม่ได้เป็นเรื่องไม่สำคัญ

  • ตัวอย่างเช่นถ้าครั้งแรกที่มีคนใช้แอปพลิเคชันรุ่นใหม่มันจะลืมหน้าต่างที่พวกเขาเปิดดังนั้นอะไร ...

• ดังนั้นจึงมีทางเลือก 100% หากวัตถุเปลี่ยนดังนั้นเราจึงไม่สามารถอ่านบล็อกได้

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

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

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

ปัจจัยที่สำคัญมาก: การทำให้เป็นอนุกรมของ Java (สิ่งหนึ่งที่เปิดใช้งานโดยการนำไปใช้Serializable) เป็นรูปแบบที่แย่มากในตัวเองดังนั้นคุณไม่ควรใช้มันสำหรับการจัดเก็บวัตถุถาวร

ข้อเสียของการทำให้เป็นอันดับจาวา ได้แก่ :

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

ดังนั้นหากคุณใช้รูปแบบการทำให้เป็นอนุกรมอื่น ๆ คุณจะได้รับการจัดเก็บ Key-Value ที่ดีถ้าคุณใช้การทำให้เป็นอันดับ Java คุณจะได้รับความยุ่งเหยิง

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

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

อย่าไปเสียเวลาว่างกับฐานข้อมูลความเร็วและหน่วยความจำหากไม่ใช่ปัญหา

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

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

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

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