Daftar dan Dapatkan Informasi Update Terbaru!

Best Practice Membangun Desain Database Aplikasi yang Scalable

Durasi Membaca: 4 menit

Tulisan ini adalah kelanjutan dari tulisan saya sebelumnya dalam seri Best Practice Membangun Aplikasi Website dengan Laravel. Sebelum memulai untuk membuat aplikasi atau coding, ada hal yang perlu dipersiapkan oleh pengembang aplikasi website, yaitu database yang akan digunakan. Aplikasi tanpa database sebenarnya tidak menjadi masalah, namun apabila ada kondisi dimana pengguna akan melakukan maintenance seperti merubah properti value website, tentu tidak mungkin dilakukan secara hardcode atau merubah kode setiap kali ada perubahan.

Aplikasi website harus dibuat se-general mungkin

Untuk mendapatkan aplikasi yang general dan mudah untuk dikustomisasi tentu dimulai dari desain database yang baik dan scalable. Saya akan memberikan beberapa contoh kasus kesalahan yang dilakukan pengembang dalam mendesain database. Kesalahan ini mungkin tidak menjadi masalah untuk jangka waktu pendek, namun seiring berkembangnya data dan sistem yang saling terhubung, kesadaran akan kesalahan desain database akan dirasakan sangat mengganggu.

1. UUID sebagai atribut unik / primary key

Kasus pertama kesalahan yang sering dilakukan yaitu pembuatan atribut unik atau primary key dalam tabel di database, dimana pengembang lebih suka membuat id transaksi dengan menggunakan autoincrement. Bagi saya, autoincrement pada dasarnya berguna hanya sebagai index untuk menghitung jumlah row terakhir yang pernah diinput sistem. Dalam hal dijadikan referensi id unik, penggunaan autoincrement sangatlah berisiko. Secara best practice, pengembang aplikasi yang sudah berpengalaman tidak akan menggunakan fungsi autoincrement ini dalam suatu id transaksi. Lalu bagaimana solusinya? Kita mengenal yang namanya universally unique identifier (UUID) yaitu kode unik yang dibangun atas 128-bit angka sebagai identifikasi sistem komputer.

UUID sebagai primary key

Penggunaan UUID akan mengatasi masalah konflik data ketika suatu sistem akan dilakukan integrasi. Saya sendiri mengalami kendala ini dan tersadar ketika akan membuat fungsi export import data antar sistem. Suatu trasanksi yang menggunakan autoincrement ketika akan dilakukan penggabungan dengan data di sistem yang berbeda akan mengalami konflik id transaksi.

2. Penggunaan Desain Relasional Database

Sebelum membahas mengeniai relational database, kita akan membahas mengenai struktur database itu sendiri. Beberapa istilah yang akan ditemui diantaranya:

Database atau Entitas adalah suatu objek yang memiliki atribut dan nilai sehingga memiliki karakteristik khusus. Sebagai contoh ketika akan membuat aplikasi perpustakaan, maka entitasnya adalah Perpustakaan.

Tabel adalah komponen pembentuk database yang memiliki atribut field untuk menampung transaksi. Sebagai contoh untuk entitas perpustakaan akan dibentuk oleh 3 tabel utama yaitu Tabel Buku, Penerbit dan Pengarang.

Field adalah atribut-atribut yang membentuk suatu tabel dimana suatu field akan menampung nilai yang akan mencirikan suatu tabel. Misalnya untuk tabel Buku, akan terdiri atas judul buku, tahun terbit, jumlah halaman, isbn, dll.

Data Value, data value / nilai merupakan satuan data terkecil yang berisi hanya nilai pada field tertentu. Melanjutkan contoh sebelumnya, tabel Buku diisi dengan nilai diantaranya judul buku “Cara Membuat Website”, tahun terbit “2020”, jumlah halaman “200” dan isbn “12328728”.

Record / row merupakan kumpulan data yang terdiri dari sekumpulan field. Record merupakan satuan informasi database yang berisi satu unit data konkrit. Satu record dapat disebut juga dengan 1 transaksi.

Konsep Relational Database

Penggunaan konsep relational database akan sangat membantu kita untuk menghasilkan desain database yang efisien. Relational database akan mengatasi permasalahan redudansi atau duplikasi data serta menciptakan desain database yang terintegrasi dan scalable. Sebagai contoh untuk aplikasi perpustakaan sebelumnya, untuk mendesain database yang berelasi, maka pada Tabel Buku tidak akan diisi dengan nama pengarang buku, namun akan diisi dengan kode pengarang buku. Sedangkan nama pengarang buku berada pada Tabel Pengarang Buku. Dengan metode ini, maka apabila sistem akan mengubah nama pengarang buku tidak perlu mencari judul buku yang dibuat oleh pengarang pada Tabel Buku lalu mengganti nama pengarang buku, melainkan sistem tinggal menggantinya pada Tabel Pengarang Buku. Dengan konsep ini, maka masing-masing tabel pada entitas perpustakaan dapat berdiri sendiri dan tercipta proses pengambilan data dari dan ke database dengan lebih efektif dan efisien. Secara umum konsep relasional database dibagi menjadi 3 yaitu:

One to One (1 to 1)

Relasi database model ini terjadi apabila sebuah data terdapat pada 2 buah tabel, dan hanya diperbolehkan satu data saja pada masing masing tabel (unique record), sama halnya seperti primary key, record yang ada pada model ini tidak boleh ada yang sama.

One to Many (1 to n)

Relasi database model ini membolehkan data yang sama pada tabel kedua, tapi hanya membolehkan data yang bersifat unique (unik) pada tabel pertama. Jadi pada model tabel kedua boleh memiliki beberapa data yang sama.

Many to many (n to m)

Berbeda dengan kedua model diatas, relasi database model ini membolehkan beberapa data yang sama baik pada tabel pertama maupun tabel kedua. Dengan demikian tidak ada unique record di kedua tabel tersebut.

Demikianlah beberapa best practice dalam membangun desain database yang scalable yang dapat saya bagikan. Untuk tutorial selanjutnya, saya akan mulai membahas mengenai instalasi Framework Laravel dengan library dasar yang penting untuk diinstall. Salah satu library yang sudah saya sebutkan yaitu library UUID untuk mengenerate kode unik UUID.

Referensi: mfikri.com, DosenIT.com

You May Also Like

About the Author: Debrian

Belajar dari pengalaman orang lain merupakan cara paling efektif untuk menjadi seorang pakar tanpa bertahun-tahun mengikuti jejak pendahulu. Pondasi sudah dibangun, kita harus melanjutkan pengembangannya.

Leave a Reply

Your email address will not be published. Required fields are marked *