Spreadsheet – Excel, Google Sheets, atau sheet dengan nama lain – adalah alat yang sangat keren dan kuat. Tapi kemudian, begitu juga database. Kapan Anda harus tetap menggunakan spreadsheet? Kapan Anda harus pindah ke database?
Ini adalah lanjutan dari artikel saya sebelumnya “Spreadsheets vs. Databases:Is It Time to Switch?” di mana kami telah membahas kelemahan paling umum dari penggunaan spreadsheet untuk mengatur banyak data. Dalam artikel ini, kita akan mengetahui bagaimana database memecahkan masalah tersebut.
Menggunakan Database untuk Mengatur Data
Moto saya adalah “gunakan teknologi tepat guna untuk kebutuhan Anda”. Jika Anda dapat menjalankan bisnis Anda melalui lembaran, bagus! Jika Anda membutuhkan database sederhana, MS Access bukanlah pilihan yang buruk. Tetapi jika produk ini tidak bekerja untuk Anda, Anda mungkin memerlukan database dan aplikasi web yang disesuaikan. Basis data akan menyimpan data Anda; aplikasi web akan menjadi cara yang mudah digunakan untuk berinteraksi dengan database dan berkomunikasi dengan lapisan data.
Bisnis layanan fiktif kami tidak terlalu rumit, sehingga kami dapat menjalankannya menggunakan model data yang cukup sederhana. Jika Anda melihat gambar di bawah, Anda akan melihat bahwa semua yang kita butuhkan disimpan hanya dalam lima tabel:client_type , client , service , replacement , dan has_service .
Aturan utama desain basis data adalah menyimpan data dunia nyata terkait di satu tempat . Dalam hal ini, kami akan mempertahankan semua client data di tabel klien. Dengan cara ini, kami akan menghindari penyimpanan data yang sama di beberapa lokasi (jenis redundansi buruk yang disebutkan sebelumnya). Jika kami mengubah apa pun yang terkait dengan klien, kami hanya akan melakukannya sekali, di tabel ini. Ini akan sangat meningkatkan kualitas data dan baik untuk performa.
Tabel berikutnya yang berisi data dunia nyata adalah service meja. Sekali lagi, kami dapat menyimpan semua detail yang terkait dengan layanan kami di sini dan kami dapat membuat perubahan pada data dengan cukup efisien.
client tabel dan service tabel adalah entitas dunia nyata yang bisa eksis tanpa yang lain. Namun, membuat database dengan entitas yang tidak terkait tidak terlalu masuk akal – ini seperti memiliki pelanggan tanpa produk atau layanan tanpa pembeli. Jadi kita akan menghubungkan kedua tabel ini menggunakan has_service meja. Untuk menyimpan informasi tentang klien mana yang memiliki layanan mana, kami akan menggunakan kunci asing yang bertindak sebagai referensi ke klien dan layanan tersebut. Kunci asing ini menunjuk kembali ke catatan di tabel layanan dan klien. Kami juga dapat menyimpan informasi tambahan apa pun yang terkait dengan setiap hubungan layanan klien di tabel ini.
client_type tabel digunakan seperti kamus yang menyimpan setiap jenis klien yang mungkin. Sebaiknya simpan segmentasi yang berbeda dalam tabel kamus terpisah (misalnya jika kami memiliki tipe pelanggan dan tipe peran karyawan, kami akan menyimpannya di tabel yang berbeda). Namun, kita hanya membutuhkan satu tabel karena ini adalah model yang sederhana.
Tabel terakhir dalam model kami adalah replacement meja. Kami akan menggunakannya untuk menghubungkan dua layanan:layanan yang ingin kami ganti dan layanan pengganti. Ini memberi kami fleksibilitas untuk menawarkan penggantian kepada klien untuk layanan yang ada (seperti mengubah dari satu paket panggilan seluler ke paket lainnya).
Kelebihan Basis Data
Basis data lebih rumit untuk disiapkan daripada spreadsheet, tetapi ini sebenarnya memberi mereka beberapa keuntungan signifikan dalam hal integritas dan keamanan data:
Kunci dan batasan
Basis data memiliki aturan dan kontrol bawaan yang, jika digunakan dengan benar, akan mencegah sebagian besar masalah kualitas dan kinerja data. Kunci utama (kolom yang secara unik mengidentifikasi setiap catatan dalam tabel) dan kunci asing (kolom yang merujuk ke catatan di tabel lain) sangat penting untuk keamanan data, tetapi mendefinisikan kunci alternatif atau UNIK (yang berisi data unik untuk setiap catatan dalam tabel ) juga sangat membantu.
Dalam database relasional, kunci menghubungkan data dari tabel yang berbeda. Kunci utama tabel selalu UNIK, sedangkan kunci asing merujuk kunci utama dari beberapa tabel lain. Referensi tersebut menghubungkan data dari dua tabel ini (misalnya, kunci asing di has_service tabel menghubungkan data pelanggan dengan layanan yang mereka miliki). Ini juga akan memperingatkan kami jika kami akan menghapus kunci utama yang dirujuk di beberapa tabel lain. Ini akan mencegah kita menghapus record yang masih diperlukan (sebagai referensi) di tabel lain.
Batasan menentukan jenis data yang dapat dimasukkan ke dalam bidang. Kita dapat menentukan bahwa data harus memiliki nilai (NOT NULL), menentukan format untuk nomor telepon, hanya berisi huruf, dan sebagainya. Ini berarti kita dapat menghindari masalah data dari orang yang memasukkan jenis data yang salah di suatu bidang.
Keamanan dan Izin
Fitur database lain yang sangat penting adalah mengontrol akses ke data Anda . Ini memberi Anda kemampuan untuk mengatur tidak hanya siapa yang dapat mengakses database Anda, tetapi juga untuk mengontrol apa yang dapat mereka lihat atau ubah. Ini adalah bagian besar dari keamanan data. Misalnya, Anda dapat menentukan peran pengguna yang memungkinkan karyawan mengubah detail pelanggan tetapi bukan detail layanan. Anda juga dapat menetapkan aturan tentang karyawan yang dapat mengubah atau menghapus data. Ini adalah praktik standar yang baik untuk memastikan bahwa orang hanya memiliki akses ke data yang mereka butuhkan untuk melakukan pekerjaan mereka.
Tentu saja, kita dapat mencoba membuat ulang fungsi-fungsi ini dalam lembaran (setidaknya dalam beberapa cara), tetapi itu pasti akan "menciptakan kembali roda".
Tidak bisakah Kita Menggunakan Spreadsheet?
Tentu saja kami bisa. Kita bisa membuat lembar yang mengikuti pola yang sama yang digunakan dalam model data. Itu akan menyelesaikan banyak masalah data, tapi…
Mereplikasi model data dalam lembaran jelas bukan pilihan yang ideal. Kami akan kehilangan semua keuntungan yang diberikan sistem database kepada kami, semua aturan dan batasan yang menjaga data tetap "sehat", semua hal yang mencegah penghapusan yang tidak disengaja dan kesalahan lainnya. Kami akan kehilangan pengoptimalan dan, jika kumpulan datanya cukup besar, kinerja akan terpukul.
Bahkan jika kami menyelesaikannya, bagaimana dengan berbagi data, mis. memiliki banyak pengguna menggunakan lembar yang sama pada saat yang bersamaan? Apa masalah integritas dan kinerja data yang akan disebabkan oleh hal ini? Ini akan menjadi kebalikan dari menjaga hal-hal sederhana.
Jadi, jika menurut Anda sheet tidak dapat menangani kebutuhan bisnis Anda, Anda mungkin sudah menuju ke database. Jika Anda terjebak dengan data yang disimpan dalam lembar dan Anda ingin pindah ke database, Anda harus:
- Buat model database yang menyimpan data Anda secara optimal.
- Bangun aplikasi dengan database di latar belakang.
- Hapus data Anda, ubah (jika perlu), dan impor ke database.
- Lanjutkan bekerja dengan database saja.
Mana Yang Harus Anda Pilih – Spreadsheet atau Database?
Dalam artikel hari ini, kita telah mempelajari bagaimana database memecahkan masalah dengan menggunakan lembar untuk mengatur banyak data. Saran saya adalah selalu gunakan solusi paling sederhana untuk masalah Anda . Jika spreadsheet akan melakukan pekerjaan dengan benar, gunakanlah. Tetapi jika Anda adalah perusahaan berbasis data, Anda harus mulai menggunakan database ASAP. Semakin lama Anda menunggu untuk membersihkan dan memigrasikan data Anda, prosesnya akan semakin menyakitkan.
