Author Topic: Add Column ... After  (Read 3354 times)

0 Members and 1 Guest are viewing this topic.

Offline poppy

  • Junior Member
  • *
  • Posts: 108
Re: Add Column ... After
« Reply #15 on: March 18, 2011, 02:26:20 PM »
@poppy
Satu lagi, kalo Poppy mau punya tabel-2 yg rapi, maka stuktur database yang dirapikan dulu...  :laughing3:
setubuh!...eh salah!...setuju!

pak poison dan sammy. tolong tunjukkan dmn salahnya mempunyai tabel dgn field2 bulan dari januari sampai desember : xx01,xx02,xx03 dsb?
walau tabel itu bkn aq yg buat, tp aq siap mengaku salah kl mmg itu bertentangan dgn kaidah yg seharusnya

yakin nih? krn coding dr pak poison itu ada drop table dan rename table segala loch
gmn kl user sdg akses ke table A tiba-tiba di rename menjadi table B, atau di drop begitu saja?
emang sebesar apa data anda?!...yang pernah saya coba dengan data 500k-1m (+- 20 field) g makan waktu 5 detik.
dari cara yang saya bocorin tadi, tinggal putar-puter aja sesuai kebutuhan.

ya sdh kl mmg bs cepat dan tdk bermsalah, tp ttp saja tdk sepraktis mysql. thanks anyway.

Offline poison

  • Hero Member
  • *
  • Posts: 1.631
  • Poison 4 Women
Re: Add Column ... After
« Reply #16 on: March 18, 2011, 02:55:27 PM »
pak poison dan sammy. tolong tunjukkan dmn salahnya mempunyai tabel dgn field2 bulan dari januari sampai desember : xx01,xx02,xx03 dsb?
walau tabel itu bkn aq yg buat, tp aq siap mengaku salah kl mmg itu bertentangan dgn kaidah yg seharusnya
@sammy : sori bro, aq duluan (moga2 aja qt sepaham  :icon_biggrin:)
@ poppy
bukan salah, tapi hanya saja belim mendekati kaidah2 database ( atau biasa disebut Normalisasi).
klo menurut saya, itu bisa anda pecah menjadi 2 table,
1. table master
2. table transaksi
misal  (klo dalam hal akunting)
1. master : Chart Account
2. transaksi : jurnal
nah untuk untuk tanggal yang menyatakan itu untuk transaksi kapan, simpen di transaksi
jadi, yang ada field tanggal di table transaksi

untuk query, bisa diUlik lebih dalem.

ya sdh kl mmg bs cepat dan tdk bermsalah, tp ttp saja tdk sepraktis mysql. thanks anyway.
inilah perbedaannya, jadi pilihan ditangan kita. (ini baru satu perbedaan)
think BIG to get BIG thing

Offline poppy

  • Junior Member
  • *
  • Posts: 108
Re: Add Column ... After
« Reply #17 on: March 18, 2011, 03:15:08 PM »
pak poison dan sammy. tolong tunjukkan dmn salahnya mempunyai tabel dgn field2 bulan dari januari sampai desember : xx01,xx02,xx03 dsb?
walau tabel itu bkn aq yg buat, tp aq siap mengaku salah kl mmg itu bertentangan dgn kaidah yg seharusnya
@sammy : sori bro, aq duluan (moga2 aja qt sepaham  :icon_biggrin:)
@ poppy
bukan salah, tapi hanya saja belim mendekati kaidah2 database ( atau biasa disebut Normalisasi).
klo menurut saya, itu bisa anda pecah menjadi 2 table,
1. table master
2. table transaksi
misal  (klo dalam hal akunting)
1. master : Chart Account
2. transaksi : jurnal
nah untuk untuk tanggal yang menyatakan itu untuk transaksi kapan, simpen di transaksi
jadi, yang ada field tanggal di table transaksi

untuk query, bisa diUlik lebih dalem.


pak poison salah paham, tabel yg aq mo modify itu adalah tabel untuk keperluan laporan.
Utk tansaksi ada lagi tabel header-detailnya, dimana di tabel detailnya ini ada trigger yg selalu mengupdate setiap ada perubahan ke tabel laporan tsb. Sementara utk table chart of accountnya ada tersendiri berisi informasi nomor account,keterangan dan setting lainnya.
Mohon dijelaskan dimana yg masih tdk sesuai dgn normalisasi?

dan juga buat @sammy, mohon petunjuknya.

makasih

Offline yudoek

  • Junior Member
  • *
  • Posts: 357
Re: Add Column ... After
« Reply #18 on: March 18, 2011, 05:06:21 PM »
@poppy: dulu aq juga pernah menemukan program seperti yang kamu bilang, dimana untuk laporan mempunyai tabel sendiri. Seperti ini tabelnya.
... Bln1  bln2  bln3  jmlbln1 jumbln2..bla..bla... Kira2 seperti ini lah.
Tp karena sekarang  aq yg buat, tabel itu aq hapus. Aq ganti dengan query.
 

Offline Sammy

  • Hero Member
  • *
  • Posts: 2.400
Re: Add Column ... After
« Reply #19 on: March 18, 2011, 05:11:36 PM »
Quote
dan juga buat @sammy, mohon petunjuknya.
Halo
Aku tidak terlalu perhatikan pesan-2 sebelumnya, jadi ini berlaku secara umum, ga tahu kalo berlaku utk kamu.

Jika data yg serupa (bln1, bln2 etc) disimpan secara horisontal di tabel (fields) maka
1. Anda berhadapan dg masalah tadi: Anda mencoba menyisipkan field, padahal urutan field ga boleh pengaruh di app.
2. Boros tempat. Bisa saja dari 12 field hanya 1 yg terisi, atau semua kosong.

Jika data disimpan secara vertikal (di tabel baru) maka tabel hanya bertambah besar jika memang ada data. Jika ada data -> kita INSERT, jika tidak -> kita biarkan. Tidak ada tempat yg terbuang.

Ini sedikit sample data utk dilihat. Jika Anda berhadapan dg tabel-2 besar, maka size tabel menjadi pertimbangan. Disamping itu, selalu lebih baik "stick to the rules" yg udah dipakai secara umumm, yaitu normalisasi tabel. Tetapi memang kadang ada perkecualian...

Code: [Select]
#define EMPL "Ahmad Beni Dewi Lia"
CREATE CURSOR employees (empl_id i AUTOINC ,nama c(10),emplomset_id  i)
CREATE CURSOR emplBad (empl_id i AUTOINC ,nama c(10),os_bln1 i,os_bln2 i,os_bln3 i)
CREATE CURSOR emplOmset (emplomset_id i AUTOINC, empl_id i,omset i,bln i)
FOR i=1 TO 4
INSERT INTO employees (nama,emplomset_id) VALUES (GETWORDNUM(EMPL,i%4+1),i+2)
IF i%2=0 && kita skip 2 orang
INSERT INTO emplBad (nama,os_bln1,os_bln2 ,os_bln3 ) VALUES (GETWORDNUM(EMPL,i%4+1),i*25000,i*30000,i*35000)
FOR j=1 TO 3 && 3 bln
INSERT INTO emplOmset (empl_id,omset,bln) VALUES (i,i*ICASE(j=1,25000,j=2,30000,35000),j)
NEXT
ELSE
INSERT INTO emplBad (nama) VALUES (GETWORDNUM(EMPL,i%4+1))
ENDIF
NEXT
SELECT emplBad
LOCATE
BROWSE SAVE NOWAIT LAST 
*BROWSE
SELECT em.nama,eo.omset,CAST(CMONTH(DATE(2000,EVL(eo.bln,1),1)) as c(10)) as bln FROM employees em ;
JOIN emplOmset eo ON em.empl_id=eo.empl_id
Sammy

Offline poppy

  • Junior Member
  • *
  • Posts: 108
Re: Add Column ... After
« Reply #20 on: March 18, 2011, 05:30:12 PM »

terima kasih pak sammy
aq setuju bila maksud pak sammy itu table ttg omset salesman setahun or tabel absensi karyawan atau macam itu, krn querynya tdk tll rumit.
tp table yg aq mo update ini table summary accounting per tahun utk keperluan lap2 akunting macam bal.sheet or income.statement setahun.
walaupun bisa, tp ribet kalau dibuat pakai query.

anyway, sptnya aq dah ada cara utk masalah aq ini, aq mo pake view aja dech yg lebih gampang dibuat dan gampang di modify (drop & create).

makasih semuanya

Offline fansul

  • Hero Member
  • *
  • Posts: 894
Re: Add Column ... After
« Reply #21 on: March 18, 2011, 06:05:10 PM »
saya juga sering bikin laporan dengan field bln_01,bln_02, dst. hanya table ini tidak di update waktu input data dari table transaksi (trigger).
saya bikin procedure kecil untuk proses data kedalam table tersebut, karena data tidak banyak +/- 10rb row / bulan
hampir tidak kelihatan tunggunya.untuk menpercepat proses kadang2 juga dibuat view yang datanya udah setengah jadi.

Offline Sammy

  • Hero Member
  • *
  • Posts: 2.400
Re: Add Column ... After
« Reply #22 on: March 18, 2011, 06:36:10 PM »
Memang saya dengar dari beberapa sumber bahwa uth kepentingan laporan terkadang tabel di-denormalisasi dengan sengaja, antara lain dengan tujuan membuat SQL queries menjadi lebih sederhana.
Jadi, bukannya kita tidak boleh pakai sistem begitu (fld1, fld2 etc), melainkan kita harus mengerti bahwa ada alternatif normalisasi. Manakah yg dipakai utk tabel-2 yang mana adalah keputusan programmer (dan mungkin kadang-2 permintaan dari klien yg kita harus turuti).
Sammy

Offline foxy

  • Fox-id M.V.P
  • Hero Member
  • *
  • Posts: 3.605
    • Foxy Land
Re: Add Column ... After
« Reply #23 on: March 19, 2011, 01:00:00 AM »
Pertama kali, perlu dimengerti bahwa ada database yang didesain untuk transaksi (atau juga dikenal dengan OLTP = On-line Transaction Processing) -- dan ada juga database yang didesain untuk analisis (juga dikenal dengan OLAP = Online Analytical Processing). Database yang didesain untuk OLAP, memang bisa terlihat tidak normal kalau dilihat dari kacamata OLTP. Tapi, memang aturan dan paradigma yang digunakan untuk mendesain database OLAP berbeda. Jadi, sebenarnya, semua kembali ke kebutuhan. Apa yang Anda butuhkan? Kalau yang Anda butuhkan adalah untuk analisis, mungkin yang @ts lakukan untuk membuat tabel baru sudah betul (btw, seharusnya juga database-nya terpisah. Database OLAP jangan disatukan dengan OLTP). Biasanya cikal-bakal kebutuhan akan database OLAP diawali dengan permintaan management untuk menampilkan data dalam bentuk row di atas (jadi kolom), dan kolom menjadi  baris (row atau isi data). Proses ini kita kenal dengan cross-tab. Prinsipnya, kalau di reporting, Anda banyak menggunakan partition dan cross-tab, kemungkinan besar, sudah waktunya Anda membangun OLAP server.

Kalau mengenai judul thread ini, saya harus setuju dengan rekan-rekan yang lain. Ngapain Anda 'merapikan' susunan kolom setelah tabel itu dibuat (dan apalagi-- sudah ada data-nya). Kalau Anda menjalankan Analytical Engine di server database Anda, saya rasa (CMIIW--) perubahan itu akan me-reset data anaytical server. Mendingan juga ngurusin indexing database yang sudah jelas-dan-pasti akan memperbaiki performance database....

hth,
foxy

hth,
foxy

This post is provided as is. Feel free to use all the codes and information, however understand that I don't have any obligations to fix any bug(s) or follow up this subject.