Отримуючи доступ / маніпулюючи складними даними, краще зберігати їх у багатьох невеликих шматочках або в одному великому шматку?

Я будую веб-додаток, який маніпулює досить складними даними: вкладками гітари.

    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), отримуючи їх як один документ.

У 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із таблицею, у якій перелічені названі акорди, якщо ви зможете розпізнати акорд.

Це, мабуть, найпростіша можлива схема; Я б почав з цього.