Khi truy cập / thao tác dữ liệu phức tạp, tốt hơn là lưu trữ nó trong nhiều phần nhỏ hoặc một khối lớn?

Tôi đang xây dựng một ứng dụng web xử lý dữ liệu khá phức tạp: tab guitar.

    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-|

Sẽ hiệu quả hơn đối với hiệu suất khi lưu trữ dữ liệu này như một khối lớn, hoặc phá vỡ nó và lưu trữ trên cơ sở "ghi chú bằng ghi chú"?

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|---

Nếu tôi lưu trữ dưới dạng một khối, mã để thao tác các tab sẽ phải phức tạp hơn nhiều. Nếu tôi lưu nó bằng ghi chú, cơ sở dữ liệu sẽ phải được truy cập nhiều hơn nữa. Phương pháp nào hiệu quả hơn? Có khả năng, rất nhiều người dùng sẽ sửa đổi dữ liệu. Tôi muốn ứng dụng web hoạt động tốt nhất. Tôi sẽ sử dụng MySQL nếu điều đó ảnh hưởng đến câu trả lời.

Số lượng các hoạt động sẽ là như nhau một trong hai cách. Bạn thực hiện một truy vấn để nhận tất cả các hợp âm cho một bài hát, sau đó bạn thực hiện một cập nhật mỗi khi có thay đổi. Sự khác biệt là thực sự trong kích thước của các bản cập nhật. Với phương pháp chặn, bạn phải lưu toàn bộ bài hát mỗi khi thay đổi hợp âm. Với phương pháp riêng lẻ, các cập nhật của bạn sẽ nhỏ hơn và có thể hiệu quả hơn về tổng thể, mặc dù sự khác biệt có thể không đáng kể.

Một điều khác cần xem xét là phương pháp ghi chú được bình thường hóa hơn, có nghĩa là bạn sẽ có nhiều tùy chọn truy vấn mở ra cho bạn hơn nếu bạn sử dụng nó. Ví dụ: người mới bắt đầu có thể lọc các hợp âm mà họ không biết khi tìm kiếm bài hát để học hoặc bạn có thể cho phép tìm kiếm dựa trên hợp âm mở nếu ai đó không biết tên bài hát. Ngay cả khi bạn không lập kế hoạch cho các tính năng đó ngay bây giờ, sẽ rất khó để thay đổi cơ sở dữ liệu của bạn nếu bạn muốn một cái gì đó như thế sau này.

Nói chung, bình thường hóa nhiều hơn là tốt cho một số lý do:

1. Sao chép dữ liệu ít hơn, dẫn đến kích thước cơ sở dữ liệu vật lý nhỏ hơn.
2. Tính toàn vẹn dữ liệu tốt hơn - bạn có thể sử dụng khóa ngoại để thực thi các yêu cầu nhất định.
3. Mã cập nhật đơn giản hơn, mà bạn đã xác định.
4. Nhiều tuyến truy cập có thể lập chỉ mục để tập hợp dữ liệu.

Nhược điểm ( được mô tả tốt ở đây ) bao gồm:

1. Bình thường hóa tiết kiệm không gian, nhưng không gian là rẻ.
2. Chuẩn hóa đơn giản hóa các bản cập nhật, nhưng đọc là phổ biến hơn.
3. Hiệu suất thường tốt hơn với các lược đồ ít chuẩn hóa.

Tôi sẽ đề nghị bắt đầu với một thiết kế bình thường hơn, và chỉ xem xét việc không chuẩn hóa nếu bạn gặp vấn đề về hiệu suất.

Làm cho bộ lưu trữ của bạn dễ dàng nhất để làm việc và đủ cứng để vặn lên. Đi với một lược đồ hợp lý hóa bình thường. Đi với một lược đồ không loại trừ các cách sử dụng khác với bạn sẽ cần trong bản phát hành đầu tiên, nếu có thể.

Nếu tất cả những gì bạn cần là hiển thị các tab cho một bài hát cụ thể, bạn có thể lưu trữ rất nhiều bộ 6 trong một DB hướng tài liệu (như MongoDB), tìm nạp chúng dưới dạng một tài liệu.

Trong một RDBMS, tôi sẽ lưu trữ nó tương tự, trong một bảng như thế này:

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 rất giỏi trong các truy vấn đơn giản như truy vấn cần thiết để hiển thị một bài hát:

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

Sử dụng limitvà offset, bạn có thể hiển thị các phần của một bài hát.

Sau đó, sẽ dễ dàng liên kết tab_columnđến một bảng liệt kê các hợp âm có tên, nếu bạn có thể nhận ra một hợp âm.

Đây có lẽ là lược đồ đơn giản nhất có thể; Tôi sẽ bắt đầu với nó.