При доступе к сложным данным / манипулировании ими лучше хранить их в виде множества маленьких фрагментов или одного большого фрагмента?

Я создаю веб-приложение, которое манипулирует довольно сложными данными: вкладками гитары.

    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. Лучшая целостность данных - вы можете использовать внешние ключи для обеспечения соблюдения определенных требований.
3. Более простой код обновления, который вы определили.
4. Более индексируемые маршруты доступа к подмножествам данных.

Недостатки ( хорошо описаны здесь ) включают в себя:

1. Нормализация экономит пространство, но пространство дешево.
2. Нормализация упрощает обновления, но чтения более распространены.
3. Производительность обычно лучше с менее нормализованными схемами.

Я бы предложил начать с более нормализованного дизайна и рассмотреть вопрос о денормализации только в случае проблем с производительностью.

Сделайте хранилище легким в работе и достаточно жестким, чтобы его испортить. Перейти с разумно нормализованной схемой. Используйте схему, которая не исключает использования, отличного от того, которое вам понадобится в первом выпуске, если это возможно.

Если все, что вам нужно, это показать вкладки для определенной песни, вы можете хранить много 6 кортежей в БД, ориентированной на документы (например, MongoDB), выбирая их как один документ.

В РСУБД я бы сохранил это аналогично в таблице, подобной этой:

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

СУРБД хороши в простых запросах, подобных тем, которые нужны для показа песни:

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

Используя limitи offset, вы можете показать части песни.

Позже будет легко связать tab_columnтаблицу со списком именованных аккордов, если вы сможете распознать аккорд.

Это, вероятно, самая простая из возможных схем; Я бы начал с этого.