เมื่อเข้าถึง / จัดการกับข้อมูลที่ซับซ้อนควรเก็บไว้เป็นชิ้นเล็ก ๆ หรือก้อนใหญ่ก้อนเดียวดีกว่าไหม

ฉันกำลังสร้างเว็บแอปที่จัดการกับข้อมูลที่ค่อนข้างซับซ้อน: แท็บกีต้าร์

    As a reference, guitar tabs look like this:
Eb|-------------------------------------------------------------------------|
Bb|-------------------------------------------------------------------------|
Gb|--5-5-5-5----------------------------------------------------------------|
Db|--5-5-5-5--3-3-3-3--7-7-7-7--5-5-5-5--2-2-2-2--3-3-3-3--2-2-2-2--5-5-5-5-|
Ab|--3-3-3-3--3-3-3-3--7-7-7-7--5-5-5-5--2-2-2-2--3-3-3-3--2-2-2-2--5-5-5-5-|
Eb|-----------1-1-1-1--5-5-5-5--3-3-3-3--0-0-0-0--1-1-1-1--0-0-0-0--3-3-3-3-|

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

As a use case:
User changes first chord from:       to:
                         Eb|---   Eb|---
                         Bb|---   Bb|---
                         Gb|--5   Gb|--4
                         Db|--5   Db|--4
                         Ab|--3   Ab|--2
                         Eb|---   Eb|---

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

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

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

โดยทั่วไปการปรับสภาพให้ดีขึ้นนั้นมีเหตุผลหลายประการ:

1. การทำสำเนาข้อมูลน้อยลงนำไปสู่ฐานข้อมูลทางกายภาพที่มีขนาดเล็กลง
2. ความสมบูรณ์ของข้อมูลที่ดีกว่า - คุณสามารถใช้ foreign key เพื่อบังคับใช้ข้อกำหนดบางประการ
3. รหัสการปรับปรุงที่เรียบง่ายซึ่งคุณได้ระบุไว้
4. เส้นทางเข้าถึงที่จัดทำดัชนีได้มากขึ้นไปยังชุดย่อยของข้อมูล

ข้อเสีย ( อธิบายไว้ที่นี่ ) รวมถึง:

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

ฉันขอแนะนำให้เริ่มต้นด้วยการออกแบบที่ทำให้เป็นมาตรฐานมากขึ้นและพิจารณา denormalizing เฉพาะเมื่อคุณพบปัญหาเกี่ยวกับประสิทธิภาพเท่านั้น

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

หากสิ่งที่คุณต้องการคือการแสดงแท็บของเพลงใดเพลงหนึ่งคุณสามารถเก็บ 6-tuples จำนวนมากในฐานข้อมูลที่มุ่งเน้นเอกสาร (เช่น MongoDB) ดึงพวกเขาเป็นเอกสารเดียว

ใน RDBMS ฉันจะเก็บมันในทำนองเดียวกันในตารางดังนี้

table tab_column (
  song_id integer not null foreign key references song(id),
  ordinal integer not null, -- position in the tabulature
  s1 number(2), -- position on 1st string
  ...
  s6 number(2),
  primary key(song_id, ordinal)
)

RDBMS มีข้อความค้นหาง่าย ๆ เช่นเดียวกับที่จำเป็นในการแสดงเพลง:

select * from tab_column
where song_id = :song_id
order by ordinal;

การใช้limitและoffsetคุณสามารถแสดงบางส่วนของเพลง

หลังจากนั้นมันจะง่ายต่อการเชื่อมโยงtab_columnไปยังตารางที่แสดงรายการคอร์ดหากคุณสามารถจดจำคอร์ดได้

นี่อาจเป็นสคีที่ง่ายที่สุดเท่าที่จะเป็นไปได้ ฉันจะเริ่มต้นด้วย