Normalisasi memang mutlak diperlukan dalam desain database, tapi setelah table2
tersebut telah di normalkan, ada beberapa pengecualian2 yang mungkin cukup
bijak dan perlu di petimbangkan kembali untuk dikembalikan ke kondisi tidak
normal. Kecepatan akses key jadi salah satu alasan kenapa harus ada duplikasi
data. Repot juga kalo server yang paling bagus sekalipun harus menampung
trilyunan data dengan load traffic yang sangat tinggi tanpa dibantu dengan
sumber daya client dalam pengolahannya. mungkin ini yang dimaksut saudara Lai
Min Feng. Sepertinya kita sebagai programer dan system analis juga harus
berhitung dengan banyakya client dan load data yang nantinya akan dimanage.
Kalo gak salah ada juga teori yang menyebutkan kalo pengolahan database juga
tidak melulu memakai normalisasi penuh, mungkin ada penyimpangan2 yang bisa
ditoliler sebagai pertimbangan tertentu.
Regard
r3dc377
----- Original Message -----
From: Lai Min Feng
To: [email protected]
Sent: Friday, May 18, 2007 12:19 PM
Subject: RE: [Programmer-VB] Re: Normalisasi
hehe...sepertinya salah ngerti pula maksud saya (atau saya yang salah
ngerti ? :p )...
anyway.. saya bukan menganjurkan tanpa normalisasi...
tapi normalisasi, dengan sedikit pelanggaran (atau mgkn sebenernya
normalisasi jg ya ? soalnya setau saya ada normalisasi lanjutannya lagi
setelah selesai memecah2 semuanya..)
coba liat contoh sederhana saya di email sebelumnya. apa mkgn dengan
normalisasi habis2an(tanpa table trstok, hanya dengan sql join) bisa lebih
cepat querynya ? menurut saya sih tidak.. pada akhirnya semua orang akan
memakai table trstok seperti itu...
oh ya... satu lagi... anda mengatakan untuk memakai trigger... setau saya
trigger itu sudah tidak dianjurkan dalam database warehousing (kalu gak salah
namanya), atau kalu emang perlu banget pake, itu perlu design yang sangat
hati2... hal ini sudah diakui pula oleh teman2 saya yang bekerja di bidang
database, bahkan salah satunya pernah bekerja di microsoft
> kalau soal view, menurut saya, jauh lebih enak, apalagi kalau sistem
aplikasinya adalah client - server, dari sisi client, aplikasi tidak perlu
meng-eksekusi banyak kode, bayangkan saya kalau script sqlnya di
> tuangkan di aplikasi client dan table yang harus di joint lebih dari 5
table dan tiap table punya column yang sampe 10, dan resultnya bisa
jutaan.....wah....bisa mampus juga tuh client.
kan kalu pake syntax sql yang dibangun di client, sama aja hasilnya, toh
namanya syntax sql (select, update, delete) akan dijalankan di server jg
(kecuali kaya kata bapak someone, bahwa dia lakukan loopingnya di client, nah
ini yang bisa bikin lama)
aplikasi enterprise ?? hmm.. gak tau d...
ini banyak persepsinya.. ada orang bikin program kecil2an aja dah bilang2
aplikasi enterprise...
ada orang yang programnya dah mencakup banyak banget bidang dalam satu
persh pun, masih bilang bahwa itu bukan aplikasi enterprise...
jadi ya.. no comment d yang ini...
tapi ya... semuanya kembali lagi ke masing2..
kalu anda merasa lebih enjoy dengan cara yang anda lakukan, dan itu jalan,
tentunya silakan diteruskan...
saya sudah ok dan telah membangun banyak aplikasi yang berjalan dengan cara
saya.. jadi ya... saya akan tetap melanjutkan cara saya :)
=======================
http://www.fire888.com
-----Original Message-----
From: [email protected] [mailto:[EMAIL PROTECTED] Behalf Of
Suryo
Sent: Friday, May 18, 2007 11:26 AM
To: [email protected]
Subject: Re: [Programmer-VB] Re: Normalisasi
hehehee sepertinya kalau yang bung lai min feng sebutkan di bawah
ini adalah contoh dari normalisasinya hehehehehe, kalau table trstok lebih
seperti ke stock card :-), tapi paling tidak itu sudah menuju ke
normalisasi, hanya saja masih kurang cukup :-)
kalau soal normalisasi, sudah pasti seluruh system analyst akan membuat
databasenya dengan normalisasi karena itu sudah standard dari pembuatan
sebuah database, dan terus terang baru kali ini saya membaca ada yang
menganjurkan untuk melanggar hehehehehehe, mungkin kalau ada yang pengen
ngelanggar di karenakan, tanpa adanya normalisasi, tentunya buat SQL query
jauh lebih gampang kan ?? (menurut saya )
lagi pula untuk untuk performance, saya pikir dengan normalisasi malah
lebih baik, apalagi kalau di dukung script sql dengan join yang baik pula.
kalau soal view, menurut saya, jauh lebih enak, apalagi kalau sistem
aplikasinya adalah client - server, dari sisi client, aplikasi tidak perlu
meng-eksekusi banyak kode, bayangkan saya kalau script sqlnya di tuangkan
di aplikasi client dan table yang harus di joint lebih dari 5 table dan
tiap table punya column yang sampe 10, dan resultnya bisa
jutaan.....wah....bisa mampus juga tuh client.
nah sekarang kalau kita sudah membicarakan normalisasi, sebisa mungkin
fasilitas yang ada di dalam DBMS di pakai, seperti view, store procedure &
trigger. nah apalagi kalau semua fasilitas di gunakan trus aplikasi di
bangun untuk basis n-tier....wah lebih mantap lagi tuh hehehehehehehehe
Sekali lagi, tentunya saya akan lebih memilih / menganjurkan untu
menggunakan / membuat database dengan normalisasi. tanpa normalisasi, jika
kena di aplikasi kelas enterprise..........heheheheheheh no comment deh :-)
----- Original Message -----
From: Someone
To: [email protected]
Sent: Monday, May 14, 2007 8:52 AM
Subject: [Programmer-VB] Re: Normalisasi
Trimakasih untuk (Ibu or Bp. ??) Lai min Feng dan Bp. Arief Wibowo
yang sudah membantu memberikan opini.. permasalahan dari kerepotan
saya adalah.. computer client di kantor saya sangat minim
spesifikasi.. sehingga saya hanya mengandalkan kecepatan server SQL
untuk pengolahan data dan saya menghindari pengolahan data di
client, karena saya sudah uji coba pengolahan data di client
membutuhkan waktu lama dari pada kalau saya menggunakan resource
server.. dan saya masih belum menemukan formula atau trik dalam
mengatasi masalah saya sehingga saya banyak menggunakan view..
kasusnya.. di dalam database customer hanya ada 1 customer 1 sales..
tapi prakteknya 1 sales boleh menjual ke banyak customer, saya
menemui masalah di analisa dan history penjualan, karena prinsipnya
1 kode customer milik 1 kode sales.. itu sebabnya saya menggunakan
view dalam view.. kalau saya melakukan pengolahan dengan menarik
data per table customer,table sales dan transaksi, lalu saya olah di
client dan hasilnya saya insert ke SQL table.. akan lama hasilnya.
Mohon pencerahan.
Best Regards,
Someone
#ygrp-mlmsg { FONT-SIZE: small; FONT-FAMILY:
arial,helvetica,clean,sans-serif}#ygrp-mlmsg TABLE { }#ygrp-mlmsg SELECT {
FONT: 99% arial,helvetica,clean,sans-serif}INPUT { FONT: 99%
arial,helvetica,clean,sans-serif}TEXTAREA { FONT: 99%
arial,helvetica,clean,sans-serif}#ygrp-mlmsg PRE { FONT: 100% monospace}CODE
{ FONT: 100% monospace}#ygrp-mlmsg { LINE-HEIGHT: 1.22em}#ygrp-text {
FONT-FAMILY: Georgia}#ygrp-text P { MARGIN: 0px 0px 1em}#ygrp-tpmsgs
{ CLEAR: both; FONT-FAMILY: Arial}#ygrp-vitnav { FONT-SIZE: 77%; MARGIN:
0px; PADDING-TOP: 10px; FONT-FAMILY: Verdana}#ygrp-vitnav A { PADDING-RIGHT:
1px; PADDING-LEFT: 1px; PADDING-BOTTOM: 0px; PADDING-TOP: 0px}#ygrp-actbar {
CLEAR: both; MARGIN: 25px 0px; COLOR: #666; WHITE-SPACE: nowrap; TEXT-ALIGN:
right}#ygrp-actbar .left { FLOAT: left; WHITE-SPACE: nowrap}..bld {
FONT-WEIGHT: bold}#ygrp-grft { PADDING-RIGHT: 0px; PADDING-LEFT: 0px;
FONT-SIZE: 77%; PADDING-BOTTOM: 15px; PADDING-TOP: 15px; FONT-FAMILY:
Verdana}#ygrp-ft { PADDING-RIGHT: 0px; BORDER-TOP: #666 1px solid;
PADDING-LEFT: 0px; FONT-SIZE: 77%; PADDING-BOTTOM: 5px; PADDING-TOP: 5px;
FONT-FAMILY: verdana}#ygrp-mlmsg #logo { PADDING-BOTTOM: 10px}#ygrp-vital
{ PADDING-RIGHT: 0px; PADDING-LEFT: 8px; MARGIN-BOTTOM: 20px;
PADDING-BOTTOM: 8px; PADDING-TOP: 2px; BACKGROUND-COLOR: #e0ecee}#ygrp-vital
#vithd { FONT-WEIGHT: bold; FONT-SIZE: 77%; TEXT-TRANSFORM: uppercase;
COLOR: #333; FONT-FAMILY: Verdana}#ygrp-vital UL { PADDING-RIGHT: 0px;
PADDING-LEFT: 0px; PADDING-BOTTOM: 0px; MARGIN: 2px 0px; PADDING-TOP:
0px}#ygrp-vital UL LI { CLEAR: both; BORDER-RIGHT: #e0ecee 1px solid;
BORDER-TOP: #e0ecee 1px solid; BORDER-LEFT: #e0ecee 1px solid; BORDER-BOTTOM:
#e0ecee 1px solid; LIST-STYLE-TYPE: none}#ygrp-vital UL LI .ct {
PADDING-RIGHT: 0.5em; FONT-WEIGHT: bold; FLOAT: right; WIDTH: 2em; COLOR:
#ff7900; TEXT-ALIGN: right}#ygrp-vital UL LI .cat { FONT-WEIGHT:
bold}#ygrp-vital A { TEXT-DECORATION: none}#ygrp-vital A:hover {
TEXT-DECORATION: underline}#ygrp-sponsor #hd { FONT-SIZE: 77%; COLOR:
#999}#ygrp-sponsor #ov { PADDING-RIGHT: 13px; PADDING-LEFT: 13px;
MARGIN-BOTTOM: 20px; PADDING-BOTTOM: 6px; PADDING-TOP: 6px; BACKGROUND-COLOR:
#e0ecee}#ygrp-sponsor #ov UL { PADDING-RIGHT: 0px; PADDING-LEFT: 8px;
PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-TOP: 0px}#ygrp-sponsor #ov LI {
PADDING-RIGHT: 0px; PADDING-LEFT: 0px; FONT-SIZE: 77%; PADDING-BOTTOM: 6px;
PADDING-TOP: 6px; LIST-STYLE-TYPE: square}#ygrp-sponsor #ov LI A { FONT-SIZE:
130%; TEXT-DECORATION: none}#ygrp-sponsor #nc { PADDING-RIGHT: 8px;
PADDING-LEFT: 8px; MARGIN-BOTTOM: 20px; PADDING-BOTTOM: 0px; PADDING-TOP: 0px;
BACKGROUND-COLOR: #eee}#ygrp-sponsor .ad { PADDING-RIGHT: 0px; PADDING-LEFT:
0px; PADDING-BOTTOM: 8px; PADDING-TOP: 8px}#ygrp-sponsor .ad #hd1 {
FONT-WEIGHT: bold; FONT-SIZE: 100%; COLOR: #628c2a; LINE-HEIGHT: 122%;
FONT-FAMILY: Arial}#ygrp-sponsor .ad A { TEXT-DECORATION: none}#ygrp-sponsor
.ad A:hover { TEXT-DECORATION:
underline}#ygrp-sponsor .ad P { MARGIN: 0px}o { FONT-SIZE:
0px}..MsoNormal { MARGIN: 0px}#ygrp-text TT { FONT-SIZE: 120%}BLOCKQUOTE
{ MARGIN: 0px 0px 0px 4px}..replbq { }
---------------------------------
No need to miss a message. Get email on-the-go
with Yahoo! Mail for Mobile. Get started.
