membuat table yang efektif part 2

Maaf bila tulisan sebelumnya membingungkan, saya akan mempersingkat di sini. Table efektif sebenarnya bukan hanya masalah di normalisasi. Tapi masalah bagaimana kamu dapat menggunakannya dalam coding kamu. Namanya data/informasi akan saling berkaitan layaknya barang dengan kategori, subkategori, harga pertanggal/periode, warna dan lain-lain. Data itu nantinya tidak hanya ditampilkan saja tapi juga dicari.

Dari pernyatan inilah kita dapat berfikir membuat table yang efektif. Dimana sesuatu yang tidak efektif malah terkadang adalah jawabannya. Kasus ini dapat terbukti pada table yang bersifat statis dan jarang atau tidak pernah mendapatkan update. Dalam kasusku seperti table tipe laporan.

NORMALISASI

adalah metode yang terbaik untuk melakukan efektifitas data. Disini kita mendapatkan apa saja bagian data yang berulang. Misal dalam data barang yang sering berulang adalah kategori. Lalu kita juga menemukan bahwa kategori memiliki sub kategori dan akhirnya kita mampu membuat keterkaitan yang bisa dibilang akan membingungkan untuk kita jabarkan sendiri.

Kesulitan pada user dalam membuat normalisasi adalah karena membutuhkan waktu dan kesabaran membuatnya. Belum lagi ditambah data yang di input masih sedikit dan sulit menemukan masalah didalamnya.

KETERKAITAN DATA.

Data saling terkait, ini berarti berita bagus atau malah buruk. Berita bagus adalah kamu dapat menggunakan kode untuk mengaitkan dengan table lain, tapi berita buruknya kita sering tanpa sadar memutus keterkaitan itu. Selain memutus keterkaitan data, kadang kita melupakan bahwa data yang terkait memiliki kaitan pada data lain.

akibat kurang efektifnya data dan kesalahan persepsi, menimbulkan perkembangan program berikutnya. Padahal perusahaan ingin melakukan perkembangan kedepan dengan program yang ada. Hal terburuk adalah merombak ulang atau malah memakai sistem baru. Tetapi kembali lagi, kita tidak bisa mengatakan bahwa data itu efektif tanpa mengetahui alasan efektifnya.

ALASAN?

Tidak ada banyak alasan dalam berfikir data efektif selain berfikir bagaimana membuat table yang tidak menyulitkan coding. Karena inti dari data efektif adalah tidak menyulitkan programer dan program yang dia buat. Tapi programer sering lupa, sesuatu yang mudah di awal akan rumit di akhir! Terutama bila menyangkut laporan!
Itulah dasar kenapa seorang programer harus berani mencoba-coba hal baru. Dalam hal ini membuat sesuatu yang berbeda dari yang umum dia temui. Disinilah inti tulisan ini akan dimulai, bagaimana saya membuat table yang tadinya memiliki field banyak menjadi lebih ringkas.

TABLE DENGAN BANYAK FIELD

Kenapa tidak, banyak field berarti saya mudah menginputnya. Dan saya sudah tahu dimana akan menginputnya. Tapi kalau fieldnya sampai 50, tentu kita akan kesulitan untuk input maupun menariknya!! Ini terjadi saat saya membangun program pemeriksaan kesehatan yang memiliki field 30. Namun saya sadar bahwa field yang seharusnya lebih dari 30!! sehingga ada beberapa data saya gabung dalam 1 field seperti keterangan mata.

FIELD DENGAN BANYAK DATA

Field keterangan mata itu saya buat dengan format

keterangan mata 1 [break] keterangan mata 2 [break] dst

kemudian saya akan tarik dan pecah isinya dengan explode en walah sudah dapat yang di inginkan.. Tapi ternyata saya salah.. Data yang masuk ternyata berkembang, malah ada keterangan mata yang harusnya berada di posisi 2 jadi posisi 3 dan lainnya. Hal ini tidak termasuk munculnya keterangan lainnya!

Dari konsep inilah saya membuat table yang lebih efektif yaitu saya mampu menggantikan fungsi field tapi hasilnya field?? bingung ? saya akan jelaskan perlahan-lahan.

NAMA INPUT SESUAI FIELD

ada 1 rahasia dalam input data di form. Yaitu nama inputnya selalu sama seperti fieldnya. Terbukti ada input text bernama 'NAME' yang saat di lihat di table terdapat nama filed bernama name. Hal sama juga kulakukan untuk input saya. Namun kedepannya barulah saya sadar bahwa hrs ada cara penarikan data yang lebih mudah.

Nama input lalu saya buat/ganti jadi array seperti

text[name]

saat di bagian update/insert akan saya masukkan array tersebut sesuai dengan fieldnya. Namun ada juga field yang harus di edit dulu isinya agar dapat nilainya sebelum masuk. Tujuannya biasa untuk kendali input agar tidak ada usaha merusak database dari client nakal.

KONSEP AWAL MEMAKAI ARRAY

Saya tidak menyadari bahwa konsep yang kubuat sebenarnya mirip seperti json. Saat itu kubuat sebuah bentuk input ke dalam field dengan format

{nama variable}={isi variable}[break/]

tujuannya adalah mengubah isi dari tulisan itu menjadi variable yang nantinya bisa digunakan untuk pencarian. Keuntungannya saya dapat melakukan input banyak dan field yang digunakan tidaklah banyak. Tapi apakah cara ini benar? ternyata tidak.. ada alasan kenapa cara ini salah

Alasan pertama adalah pencarian data sebuah data di taro di field sebenarnya bertujuan agar dia mudah di cari. Dengan meletakkannya bersama-sama dengan variable lainnya, maka kita akan kesulitan mencarinya. Alasan kedua ukuran dari table lebih besar daripada yang memakai field banyak, pada awalnya memang tidak terlihat tetapi sejalan dengan waktu maka ukuran akan besar dan akhirnya membacanya jadi lambat

KONSEP DUA MEMILAH FIELD

Tidak mudah menemukan field yang sesuai dengan table yang ingin kita buat. Tetapi bukan berarti table yang dibuat gagal. Setelah menemukan masalah pada konsep table di atas, saya memilih field mana yang akan dijadikan kunci dan bisa di cari, maka didapat yaitu

• nama
• tanggal lahir
• kelamin
• dan lain-lain

Berkat pemilahan data, saya mampu mencari data yang dibutuhkan dan user jadi mudah menemukan data yang akan dia edit nantinya. Tidak lupa bila form berkembang dan data makin banyak, akan mudah bagi table untuk mengikuti. Namun kembali lagi, diperhatikan apakah yang baru adalah data yang akan dicari atau tidak.
Namun keadaan tidak pernah semudah perkiraan. Tapi entah kenapa 2 bulan kemudian mendadak data menjadi lambat?!? setelah itu kuperiksa dan kutemukan bahwa lambat ini karena data tiap row (baris) sangat besar.. sehingga mempengaruhi pencarian.

KONSEP TIGA MEMBAGI TABLE

Membuat sub dari data adalah pemikiran yang tak pernah terlintas. Dalam data saya melihat sumber masalah dari field bertipe text yang membuat ukuran besar dan memperlambat pencarian data. Bila melihat dari program kita melihat bahwa sebenarnya yang ada di text bukanlah data yang akan di cari, tetapi bila dari luar semuanya adalah satu kesatuan.. Disinilah baru terpikir bagaimana memisahkan data di table dengan menghadirkan table sub yang berisi text. Dimana text ini baru akan di ambil isinya bila diperlukan, selain itu table utama akan digunakan untuk pencarian.
Namun ide dan masukan terus berkembang, hingga saya menemukan bahwa walaupun cara saya efektif dengan segala model pemisahan tersebut, saya harus mengakui bahwa cara ini hanya saya sendiri yang mengetahui.. Itu sebabnya saya mendapatkan cara memanfaatkan JSON

JSON DI TABLE SUBDATA

alasan memakai json karena memang json menjadi format yang sering kutemui bila memakai jquery (selain format lainnya), alasan lainnya adalah karena ingin programer berikutnya tidak kesulitan memperbaiki data saya nanti. Kita tidak pernah tahu apakah kita mampu memperbaiki nanti, entah apakah kita sehat dan mampu memperbaiki atau kita ada di tempat lain sehingga sulit di hubungi?

untuk memakai json sangat mudah:

• masukkan data yang ingin di input ke array dengan kata kunci
• konversi data tersebut memakai json lalu input kedalam field text

sedang untuk memanggilnya hanya cukup konversi json tersebut. Namun akhirnya saya menemukan sesuatu yang menyulitkan, yaitu ternyata isi dari data json ini harus bisa di pakai dalam pencarian?!? Untuk itulah saya menemukan cara memakai 3 table. Namun sampai tulisan ini dibuat, saya tidak pernah memakai cara itu karena tidak pernah ada waktu explore ilmunya.

3 TABLE

saya cuma kasi sederhananya saja. Ada 3 table yang diperlukan yaitu 

• table data (yang berisi id, tanggal input dan nama (biasanya nama pengenalnya) )
• table data_value. Berisi id dari data, id dari table variable dan nilainya
• table variable. berisi id dan nama variablenya.

konsepnya.. semua data dimasukkan ke table data untuk mendapatkan idnya.. lalu idnya dipake buat masuk ke data_value dan merujuk pada tipe variablenya (nama, no dll). Untuk programer menengah terlihat ini adalah metode bagus untuk menghadapi data yang kian bertambah jumlah field, tapi untuk yang master mungkin menolak karena terlalu menyulitkan dalam codingnya.

KESIMPULAN

Untuk mendapatkan table yang efektif tidak bisa dalam 1 waktu!!saya sendiri membutuhkan 3 langkah agar menemukan yang efektif. Setiap langkah bukan mencari kemunduran tetapi mencari kenapa memakai konsep ini, kenapa tidak memakai konsep yang sana.

Sama seperti anda membuat table, kesalahan pasti akan terjadi. Tetapi jangan buat kesalahan itu tidak diselesaikan, perbaiki dan juga jangan lupa di backup datanya. Kita tak pernah tahu apa yang akan terjadi pada database yang sedang kita gunakan.