Wenn Sie auf komplexe Daten zugreifen oder diese bearbeiten, ist es besser, sie in vielen kleinen Teilen oder einem großen Teil zu speichern?

Ich baue eine Web-App, die ziemlich komplexe Daten manipuliert: Gitarren-Tabs.

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

Wäre es für die Leistung effizienter, diese Daten als großen Block zu speichern oder sie aufzuteilen und "Note für Note" zu speichern?

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

Wenn ich es als Block speichere, müsste der Code zum Bearbeiten der Registerkarten viel komplexer sein. Wenn ich es Note für Note speichere, muss viel mehr auf die Datenbank zugegriffen werden. Welche Methode ist effizienter? Möglicherweise werden viele Benutzer die Daten ändern. Ich möchte die leistungsstärkste Web-App. Ich werde MySQL verwenden, wenn dies die Antwort überhaupt beeinflusst.

Die Anzahl der Operationen wird in beiden Fällen gleich sein. Sie führen eine Abfrage durch, um alle Akkorde für einen Song abzurufen, und führen dann bei jeder Änderung eine Aktualisierung durch. Der Unterschied liegt wirklich in der Größe der Updates. Bei der Blockmethode müssen Sie bei jedem Akkordwechsel den gesamten Song speichern . Mit der einzelnen Methode werden Ihre Aktualisierungen kleiner und insgesamt wahrscheinlich effizienter, obwohl der Unterschied vernachlässigbar sein kann.

Eine andere zu berücksichtigende Sache ist, dass die Note-für-Note-Methode normalisierter ist, was bedeutet, dass Ihnen später mehr Abfrageoptionen zur Verfügung stehen, wenn Sie sie verwenden. Anfänger können beispielsweise Akkorde herausfiltern, die sie bei der Suche nach einem zu lernenden Song nicht kennen, oder Sie können die Suche anhand der Eröffnungsakkorde zulassen, wenn jemand keinen Songtitel kennt. Selbst wenn Sie diese Funktionen jetzt nicht planen, ist es sehr schwierig, Ihre Datenbank zu ändern, wenn Sie später so etwas möchten.

Im Allgemeinen ist eine stärkere Normalisierung aus mehreren Gründen gut:

1. Weniger doppelte Daten, was zu einer geringeren Größe der physischen Datenbank führt.
2. Bessere Datenintegrität - Sie können Fremdschlüssel verwenden, um bestimmte Anforderungen durchzusetzen.
3. Einfacherer Update-Code, den Sie identifiziert haben.
4. Indizierbarere Zugriffswege zu Teilmengen von Daten.

Nachteile ( hier gut beschrieben ) sind:

1. Normalisierung spart Platz, aber Platz ist billig.
2. Die Normalisierung vereinfacht Aktualisierungen, Lesevorgänge sind jedoch häufiger.
3. Bei weniger normalisierten Schemata ist die Leistung im Allgemeinen besser.

Ich würde vorschlagen, mit einem normalisierten Design zu beginnen und nur dann eine Denormalisierung in Betracht zu ziehen, wenn Sie auf Leistungsprobleme stoßen.

Machen Sie Ihren Speicher am einfachsten zu bearbeiten und hart genug, um Fehler zu machen. Gehen Sie mit einem einigermaßen normalisierten Schema. Verwenden Sie ein Schema, das andere Verwendungen als die, die Sie in Ihrer ersten Version benötigen, wenn möglich nicht ausschließt.

Wenn alle müssen Sie Registerkarten zeigen für ein bestimmtes Lied ist, könnten Sie speichern viele 6-Tupel in einer dokumentenorientierten DB (wie MongoDB), so dass sie als ein Dokument abgerufen werden .

In einem RDBMS würde ich es ähnlich in einer Tabelle wie dieser speichern:

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 eignen sich gut für einfache Abfragen wie die, die zum Anzeigen eines Songs benötigt werden:

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

Mit limitund offsetkönnen Sie Teile eines Songs anzeigen.

Später ist es einfach, eine Verknüpfung tab_columnzu einer Tabelle herzustellen, in der benannte Akkorde aufgelistet sind, wenn Sie einen Akkord erkennen können.

Dies ist wahrscheinlich das einfachste mögliche Schema. Ich würde damit anfangen.