การจัดเก็บ JSON ในฐานข้อมูลเทียบกับการมีคอลัมน์ใหม่สำหรับแต่ละคีย์

ฉันกำลังใช้โมเดลต่อไปนี้สำหรับเก็บข้อมูลที่เกี่ยวข้องกับผู้ใช้ในตารางของฉัน - ฉันมี 2 คอลัมน์ - uid(คีย์หลัก) และmetaคอลัมน์ที่เก็บข้อมูลอื่นเกี่ยวกับผู้ใช้ในรูปแบบ JSON

 uid   | meta
--------------------------------------------------
 1     | {name:['foo'], 
       |  emailid:['foo@bar.com','bar@foo.com']}
--------------------------------------------------
 2     | {name:['sann'], 
       |  emailid:['sann@bar.com','sann@foo.com']}
--------------------------------------------------

นี่คือวิธีที่ดีกว่า (ประสิทธิภาพฉลาดการออกแบบที่ชาญฉลาด) กว่ารุ่นหนึ่งคอลัมน์ต่อทรัพย์สินที่ตารางจะมีคอลัมน์มากมายเช่นuid, ,nameemailid

สิ่งที่ฉันชอบเกี่ยวกับโมเดลแรกคือคุณสามารถเพิ่มฟิลด์ได้มากเท่าที่จะทำได้โดยไม่มีข้อ จำกัด

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

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

ปรับปรุง

เนื่องจากไม่มีคอลัมน์มากเกินไปที่ฉันต้องทำการค้นหาจึงควรใช้ทั้งสองแบบหรือไม่ คีย์ต่อคอลัมน์สำหรับข้อมูลที่ฉันต้องการค้นหาและ JSON สำหรับผู้อื่น (ในฐานข้อมูล MySQL เดียวกัน)?

อัปเดต 4 มิถุนายน 2560

เนื่องจากคำถาม / คำตอบนี้ได้รับความนิยมฉันคิดว่ามันคุ้มค่ากับการอัพเดท

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

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

ที่กล่าวว่าแอปพลิเคชั่นบางตัวนั้นสัมพันธ์กันอย่างสมบูรณ์หรือเป็นเอกสาร แอปพลิเคชั่นส่วนใหญ่มีทั้งแบบผสม นี่เป็นตัวอย่างที่ฉันพบว่า JSON มีประโยชน์ในฐานข้อมูลเชิงสัมพันธ์:

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

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

• การจัดเก็บข้อมูลการกำหนดค่าที่ไม่มีสคีมาที่กำหนดไว้ (หากคุณกำลังสร้าง Zapier หรือ IFTTT และจำเป็นต้องจัดเก็บข้อมูลการกำหนดค่าสำหรับการรวมแต่ละครั้ง)

ฉันแน่ใจว่ามีคนอื่นเช่นกัน แต่นี่เป็นเพียงตัวอย่างสั้น ๆ

คำตอบเดิม

หากคุณต้องการเพิ่มเขตข้อมูลได้มากเท่าที่คุณต้องการโดยไม่มีข้อ จำกัด (นอกเหนือจากข้อ จำกัด ขนาดเอกสารที่กำหนดเอง) ให้พิจารณาโซลูชัน NoSQL เช่น MongoDB

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

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

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

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

คนอื่นตอบค่อนข้างดีว่าการแลกเปลี่ยนทางเทคนิคเป็นอย่างไร

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

เนื่องจากหนึ่งในการล่อลวงของการใช้ JSON คือการหลีกเลี่ยงการย้ายสคีมาดังนั้นหากทีมไม่ได้รับการลงโทษทางวินัยมันเป็นเรื่องง่ายมากที่จะติดคู่คีย์ / ค่าอื่นลงในฟิลด์ JSON ไม่มีการโยกย้ายสำหรับมันไม่มีใครจำสิ่งที่มันมีไว้สำหรับ ไม่มีการตรวจสอบเกี่ยวกับเรื่องนี้

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

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

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

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

ลองคิดดูให้ดีว่าข้อมูลของคุณเป็นอย่างไร มันเป็นรากฐานของแอปของคุณ จะมีการใช้ข้อมูลอย่างไรเมื่อเวลาผ่านไป และมีแนวโน้มที่จะเปลี่ยนเป็นอย่างไร

เพียงแค่โยนมันออกไป แต่ WordPress มีโครงสร้างของสิ่งต่าง ๆ (อย่างน้อย WordPress เป็นสถานที่แรกที่ฉันสังเกตเห็นมันอาจมาจากที่อื่น)

อนุญาตให้ใช้คีย์ที่ไม่ จำกัด และค้นหาได้เร็วกว่าการใช้ JSON blob แต่ไม่เร็วเท่ากับโซลูชัน NoSQL บางตัว

uid   |   meta_key    |   meta_val
----------------------------------
1         name            Frank
1         age             12
2         name            Jeremiah
3         fav_food        pizza
.................

แก้ไข

สำหรับการจัดเก็บประวัติ / หลายปุ่ม

uid   | meta_id    |   meta_key    |   meta_val
----------------------------------------------------
1        1             name            Frank
1        2             name            John
1        3             age             12
2        4             name            Jeremiah
3        5             fav_food        pizza
.................

และค้นหาผ่านบางสิ่งเช่นนี้:

select meta_val from `table` where meta_key = 'name' and uid = 1 order by meta_id desc

ข้อเสียเปรียบของวิธีการเป็นสิ่งที่คุณพูดถึง:

มันทำให้ช้ามากในการค้นหาสิ่งต่าง ๆ เนื่องจากแต่ละครั้งที่คุณต้องการทำการค้นหาข้อความ

ค่าต่อคอลัมน์แทนตรงกับสตริงทั้งหมด

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

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

โดยทั่วไปรุ่นแรกที่คุณใช้เรียกว่าเป็นที่เก็บเอกสาร คุณควรมีลักษณะที่เป็นที่นิยมฐานข้อมูลเอกสารตาม NoSQL เช่น MongoDB และ CouchDB โดยทั่วไปในฐานข้อมูลของเอกสารคุณจัดเก็บข้อมูลในไฟล์ json แล้วคุณสามารถค้นหาไฟล์ json เหล่านี้ได้

แบบที่สองคือโครงสร้างฐานข้อมูลเชิงสัมพันธ์ที่เป็นที่นิยม

หากคุณต้องการใช้ฐานข้อมูลเชิงสัมพันธ์เช่น MySql ฉันขอแนะนำให้คุณใช้รุ่นที่สองเท่านั้น มีจุดในการใช้ MySQL และการจัดเก็บข้อมูลในรูปแบบแรกคือ

ที่จะตอบคำถามที่สองของคุณไม่มีทางที่จะตั้งชื่อแบบสอบถามเช่น 'foo' ถ้าคุณใช้รุ่นแรก

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

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

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

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

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

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

แก้ไข:

เนื่องจากไม่มีคอลัมน์มากเกินไปที่ฉันต้องทำการค้นหาจึงควรใช้ทั้งสองแบบหรือไม่ คีย์ต่อคอลัมน์สำหรับข้อมูลที่ฉันต้องการค้นหาและ JSON สำหรับผู้อื่น (ในฐานข้อมูล MySQL เดียวกัน)?

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

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

บางครั้งการเข้าร่วมบนโต๊ะจะเป็นการโอเวอร์เฮด สมมติว่าสำหรับ OLAP ถ้าฉันมีสองตารางหนึ่งตารางคือ ORDERS และอีกอันคือ ORDER_DETAILS สำหรับการรับรายละเอียดการสั่งซื้อทั้งหมดเราต้องเข้าร่วมสองตารางนี้จะทำให้แบบสอบถามช้าลงเมื่อไม่มีแถวในตารางเพิ่มขึ้นให้พูดเป็นล้านหรือมากกว่านั้น .. การเข้าร่วมซ้าย / ขวาช้ากว่าการรวมภายใน ฉันคิดว่าถ้าเราเพิ่มสตริง JSON / วัตถุในรายการ ORDERS ที่เกี่ยวข้องเข้าร่วมจะถูกหลีกเลี่ยง เพิ่มการสร้างรายงานจะเร็วขึ้น ...

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

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

db.mycollection.find(
    {
      name: 'sann'
    }
)

ตามที่คนอื่น ๆ ได้ชี้ให้เห็นว่าแบบสอบถามจะช้าลง ฉันขอแนะนำให้เพิ่มอย่างน้อยคอลัมน์ '_ID' เพื่อสอบถามแทน