Saat mengakses / memanipulasi data yang kompleks, apakah lebih baik menyimpannya dalam banyak potongan kecil atau satu potongan besar?

Saya sedang membangun aplikasi web yang memanipulasi data yang cukup rumit: tab gitar.

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

Apakah akan lebih efisien bagi kinerja untuk menyimpan data ini sebagai potongan besar, atau memecahnya dan menyimpannya dengan dasar "catatan demi catatan"?

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

Jika saya menyimpannya sebagai blok, kode untuk memanipulasi tab harus jauh lebih kompleks. Jika saya menyimpannya dengan catatan, database harus diakses lebih banyak. Metode mana yang lebih efisien? Secara potensial, banyak pengguna akan memodifikasi data. Saya ingin aplikasi web berkinerja terbaik. Saya akan menggunakan MySQL jika itu mempengaruhi jawaban sama sekali.

database-design

— Gabe Willard
sumber

Lebih baik untuk apa? Menghemat ruang? Kekuatan CPU? IO? Sesuatu yang lain

— Oded

Ya, itu adalah aplikasi web. Banyak pengguna berpotensi memodifikasi data dengan cukup sering. Saya membayangkan banyak faktor seperti yang Anda sebutkan mempengaruhi secara berbeda. Saya tidak begitu akrab dengan spesifik itu; itu sebabnya saya bertanya di sini.

— Gabe Willard

Jika Anda tidak tahu apa yang Anda optimalkan, bagaimana kami bisa menjawab? Masalahnya - bangun dulu, jika Anda memiliki masalah khusus, lalu tanyakan bagaimana cara mengatasinya.

— Oded

Apakah Anda tidak mendesain database sebelum membangunnya? Pertanyaan saya adalah mendesain database. Bukan pemecahan masalah satu pun. Saya belum dalam tahap debugging, dan bahkan jika saya, itu akan pergi ke StackOverflow, bukan Programmer. Per FAQ: Pemrogram mencakup konsep algoritma dan struktur data, pola desain, arsitektur perangkat lunak, rekayasa perangkat lunak ... Tidak mengatasi masalah kemacetan.

— Gabe Willard

+1 masalah yang sangat menarik dan ilustrasi pekerjaan yang baik merupakan kasus penggunaan yang bermanfaat. Buat saya berharap saya punya alasan yang bagus untuk mengembangkan aplikasi tab gitar sekarang.

— Evan Plaice

Jawaban:

Jumlah operasi akan tetap sama. Anda melakukan satu permintaan untuk mendapatkan semua akord untuk sebuah lagu, lalu Anda melakukan satu pembaruan setiap kali perubahan dilakukan. Perbedaannya benar-benar dalam ukuran pembaruan. Dengan metode blok, Anda harus menyimpan seluruh lagu setiap kali Anda mengubah akor. Dengan metode individual, pembaruan Anda akan lebih kecil, dan mungkin secara keseluruhan lebih efisien, meskipun perbedaannya dapat diabaikan.

Satu hal yang perlu dipertimbangkan adalah metode note-by-note lebih dinormalisasi, artinya Anda akan memiliki lebih banyak opsi permintaan terbuka untuk Anda di ujung jalan jika Anda menggunakannya. Misalnya, pemula dapat menyaring chord yang tidak mereka ketahui saat mencari lagu untuk dipelajari, atau Anda dapat mengizinkan pencarian berdasarkan chord pembuka jika seseorang tidak mengetahui judul lagu. Bahkan jika Anda tidak merencanakan fitur-fitur itu sekarang, akan sangat menyusahkan untuk mengubah database Anda jika Anda menginginkan sesuatu seperti itu nanti.

— Karl Bielefeldt
sumber

Secara umum, lebih banyak normalisasi bagus karena beberapa alasan:

Lebih sedikit duplikasi data, yang mengarah ke ukuran basis data fisik yang lebih kecil.
Integritas data yang lebih baik - Anda dapat menggunakan kunci asing untuk memberlakukan persyaratan tertentu.
Kode pembaruan yang lebih sederhana, yang telah Anda identifikasi.
Lebih banyak rute akses yang dapat diindeks ke subset data.

Kerugian ( dijelaskan dengan baik di sini ) meliputi:

Normalisasi menghemat ruang, tetapi ruang murah.
Normalisasi menyederhanakan pembaruan, tetapi bacaan lebih umum.
Kinerja umumnya lebih baik dengan skema yang kurang normal.

Saya akan menyarankan mulai dengan desain yang lebih normal, dan hanya mempertimbangkan denormalisasi jika Anda mengalami masalah kinerja.

— Mike Partridge
sumber

Dengan basis data tab gitar, kesederhanaan, konsistensi, dan kinerja kartu truf. Jadi saya akan pergi dengan skema normalisasi paling sederhana yang bisa saya buat.

— 9000

Jadikan penyimpanan Anda paling mudah untuk dikerjakan, dan cukup sulit untuk gagal. Pergi dengan skema yang cukup dinormalisasi. Pergilah dengan skema yang tidak menghalangi penggunaan selain yang Anda perlukan dalam rilis pertama Anda, jika memungkinkan.

Jika semua yang Anda butuhkan adalah untuk menunjukkan tab untuk lagu tertentu, Anda bisa menyimpan banyak 6-tupel dalam DB berorientasi dokumen (seperti MongoDB), mengambil mereka sebagai satu dokumen.

Dalam RDBMS, saya akan menyimpannya dengan cara yang sama, dalam tabel seperti ini:

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 sangat bagus dalam pertanyaan sederhana seperti yang diperlukan untuk menampilkan lagu:

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

Menggunakan limitdan offset, Anda dapat menampilkan bagian-bagian dari sebuah lagu.

Nantinya akan mudah untuk menautkan tab_columnke tabel yang berisi daftar akor, jika Anda dapat mengenali akor.

Ini mungkin skema yang paling sederhana; Saya akan mulai dengan itu.

— 9000
sumber