One Down…

So I’ve just finished presenting my ER Diagram, and as usual, my lecturer is puzzled by my extra complicated diagram. (it’s not that complicated. Really, But I was forced to make it complicated thanks to annoying notification of referential integrity in Ms. Access. Yes, Ms. Access is created by programmers that hope that we create good database design)

And guess what, I’m so proud of my perfect database design, It enforces referential integrity super well. I can explain any case about my design, every single thing about the relationship, it covers all problem in the case. But… well, it’s a way too idealist design for me. People said that there’s a first time for everyone, and this is the first one for me creating this very perfect idealist design. So I’m kinda excited. lol.

but then, the lecture asked:
Why do you have to put 3 tables when you can make 1 table?

And then I said, “but sir, these tables has different attributes…” (and when you create two tables with different column, you know you’ll get null everywhere).

He said “then you can just join it”

Gw bengong… (dalam pikiran gw saat bengong: oh iya, benar juga, meskipun bikin null, tapi jauh lebih gampang kalau bikin satu table aja… dan kenyataannya di kehidupan nyata, gw mungkin tidak akan pusing-pusing memisahkannya jadi 3 table, hmm, bagaimana menjelaskan ke dia bahwa gw tidak suka null value di dalam table gw?)

dan tiba-tiba teman gw dengan idealisnya menjawab, tapi sir, nanti ada null column donk…

Hoh, nice, kita butuh manusia idealis untuk kehidupan. Jadilah gw bilang, iya sir, tadinya kita memang mo gabungin jadi satu aja, tapi kita consider masalah null ini dan kita pikir ini tidak akan bagus untuk presentasi..
(maksudnya adalah, kita tidak akan bisa menemukan alasan yang tepat untuk membenarkan si null column ini kalau ditanya. ha ha. but in the real life, i don’t care about the null. it’s a good trade off for the complicatedness… although not good for the long term use sih :P :P :P. But I bet this lecture thinks that the business is in small scale — and i think so too — and therefore, no need to think that hard to reduce all null~. Just keep it simple~, stupid)

and the teacher said, “okay, so it’s a good practice…”, and I added “but in the real life, i definitely wouldn’t bother to create something like this”

and then I think, wait, if everyone thinks like me, then the database design in every company would have been in a very bad design now…?? This is definitely not good for the company. So from now on I’ve decided: Even if you decide to Keep It Simple, I myself as programmer and database designer and as a student, still cannot allowed any null values in my table. :D

Cheers to idealism!

Advertisements

9 thoughts on “One Down…

  1. jawabannya adalah tergantung.. kalo untuk super super great design 3 table itu perlu, tapi kalo untuk keperluan datawarehouse/reporting, harus dibikin se-flat mungkin a.k.a join jadi 1 table.. =D

    -kijang-

  2. eh iya. gw baru ingat kata sir Munawar kita yang sakti itu. “ketika masih awal, kita belajar normalization, ketika kita mau tuning, kita malah belajar denormalization” . hahaha. gw sampai sekarang masih nggak ngerti, rasa2nya gw tidak suka kompromi soal denormalization… :(… haha. tapi mungkin bakal perlu kali ya kalau udah di level advanced :P…

  3. kata siapa null not good for long term dan bukan design yang bagus?
    hehe.. itu kan kata buku database generasi jaman jebot yang penulisnya cuman ngerti SQL-style relational database.

    buktinya BigTable http://labs.google.com/papers/bigtable.html aja mendukung orang bikin table sedikit, banyak null (sparse) gak apa2 (karena null kan gak makan tempat). dari segi design juga malah lebih bagus scalabilitynya kalo mau disharding databasenya.

    coba aja kalo databasenya jutaan row, trus lu pake 3 table, trus tiap kali query harus dijoin, mati aja :P

    -Kurniady

  4. ho oh. yang lu bilang itu kan denormalization. pelajaran gw lagi normalization sih (pelajaran semester 3). jadi ya nggak boleh ada null values. Ketika harus dituning (pelajaran semester 5), kita diencourage untuk bikin table sedikit (didenormalize) biar accessing timenya lebih cepat. Tapi tetep aja gw nggak sreg :|. seharusnya null nya juga nggak ada donk untuk design yang bagus?

  5. Bukannya BigTable sengaja dibikin jadi 1 big table, karena BigTable gak bisa join ;)). Jadi mo gak mao semua di tumplekin jadi 1 big table :P.

    Kalo menurut gw, untuk OLTP bagus pake 3 table. Untuk OLAP bagus pake 1 table. Jadi pilihlah design yang sesuai dengan problem anda.

    Mana ada OLTP dituning jadi 1 big table bisa lebih bagus? Yang ada itu OLTP dicopy, dicleaning, diconvert jadi 1 big table untuk OLAP (untuk tujuan yang berbeda : offline analytic). Tapi kalo untuk data entry, yang paling bagus tetep 3 separate tables untuk minimize redundancies.

  6. @FH: setelah baca comment lu, gw baru sadar… gw belum pernah dapat project OLAP… project tuning gw yang terakhir itu pakai OLTP skala agak besar doang… pantesan aja gw gak pernah dapat gambaran yang bener soal design datawarehousing, reporting, OLAP, whatever.

    OKEH! gw akan lebih banyak belajar…!!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s