[Ask] SQL

[wen78]

ada table zzz:

id   nama
1    aaa
2    bbb
3    cccc

DELETE FROM zzz
WHERE id= 2

hasilnya:

id   nama
1    aaa
3    cccc

pertanyaannya, gimana caranya supaya hasilnya jadi:

id   nama
1    aaa
2    cccc

structure id nya:
field: id
type: int
length: 5
AUTO_INCREMENT: x

jadi id auto sendiri(gakberubah dan tetap urut)? bisa gak?
kl bisa settingnya gmn? dah utak atik gak berhasil.

[gajeboh angek]

UPDATE `id` SET `id` = '2' WHERE `id` = 3;

[wen78]

gak bisa automatic ya? musti manual ya?

[gajeboh angek]

mysql sih setau aye gak bisa. kalo sql yang lain gak tau dah.

[tesla]

keknya maksud wen, mo supaya indexnya tetep urut:

Code Select Expand


DELETE FROM zzz WHERE id=?
UPDATE zzz SET id=id-1 WHERE id > ?

? = 2 (atau brp aja)


btw, karena fieldnya pake AUTO INCREMENT, perlu diingat seed dalam DB tidak ter-reset automatically, so harus di reset manual ke index terakhir. misal seed skr 10, setelah di delete 1 ,seharusnya insert berikutnya id=9, tp db akan tetap memberi id=10.
query utk reset seed udah server specific, tiap db server beda querynya.

[Sukma Kemenyan]

primary key di susun ulang ?
hati-hati resource usage'nya gede logh...

eniwei...
habis delete...
update zzz set id=id-1 where id>2; -- negh kalo manual...

mao auto... colokin trigger on update...

[FZ]

Saya pribadi seh saranin data di mysql indexnya gak perlu diubah2 lagi. Lagian kan kalau user kan gak perlu tahu apa yg terjadi di dalam mysql.
Intinya, untuk auto update field itu di lakukan di field baru pada saat pembentukan cursor

[Sumedho]

bener tuh, ngapain renumbering lagi. buat kita sih terlihat rapi tapi nda ada impact kelainnya. bahkan kalau itu dipake ama data lain bisa hancur relationnya.

[FZ]

saya gak tahu ya kalau di bahasa lain.
namun di vfp9 yang pernah saya pake, object grid kan terdiri dari column2,
jadi pada column pertama, record source nya bukan field, namun row grid itu sendiri.

impactnya, pada saat didelete data, kita bahkan tidak membutuhkan update field sama sekali, karena first column itu akan menyesuaikan sendiri isinya berdasarkan grid.row ke berapa

user akan berpikir bahwa seolah2 kita mengupdate field number, padahal tidak. tapi yang pasti program kita akan menjadi lebih kenceng karena tidak ada proses yang mubazir

[johan3000]

saya gak tahu ya kalau di bahasa lain.
namun di vfp9 yang pernah saya pake, object grid kan terdiri dari column2,
jadi pada column pertama, record source nya bukan field, namun row grid itu sendiri.

impactnya, pada saat didelete data, kita bahkan tidak membutuhkan update field sama sekali, karena first column itu akan menyesuaikan sendiri isinya berdasarkan grid.row ke berapa

user akan berpikir bahwa seolah2 kita mengupdate field number, padahal tidak. tapi yang pasti program kita akan menjadi lebih kenceng karena tidak ada proses yang mubazir

kalau di vfp9 tuh ada ?.refresh gitu
sedangkan bila id itu adalah spt no_ACC, atau no_pasien, maka lebih baik
tidak dipakai kembali...(begitu juga dalam dunia perbankan... norek tidak dipakai ulang)...

sedangkan dlm table/grid.... susunan record tersebut tergantung dari index key mana yg
dipakai utk mengurutkan data2 sewaktu display...


Apakah mudah menjelaskan normalisasi (normalized database) 3 tahap dgn
menggunakan contoh SQL ?

[wen78]

problem solve. thx all

[tesla]

betul2... susun index ulang sebaiknya dihindari

[wen78]

primary key di susun ulang ?
hati-hati resource usage'nya gede logh...

maksudnya resource gede? bandwith internet gede apa proses nya berat?

id nya gak sebagai index ato primary key, tp sebagai no urut aja kok. gak berat khan?
soalnya lg cari akal supaya gak usah pake penampung data sementara, jadi lsg tarik dr database & tampilkan

1 lagi,
kl ada 10rb record dalam 1 table(tanpa normalisasi), dan dibandingkan dengan ada 100 table yg masing2 ada 100 record dlm tiap table(normalisasi). mana yg lebih cepat dalam proses search?

diasumsikan yg 10rb record dalam 1 table(tanpa normalisasi) ada di record ke 9999 dan yg 100 table yg masing2 ada 100 record ada di table ke 100 record ke 99.
mana yg lebih cepat dlm proses search? mungkin perbedaanya hanya 1/1000sec, tp pengen tau mana yg lebih cepat?
soalnya proses copy file(write), 1 file 1GB dengan 1000 file masing2 1MB, kayanya lebih cepat copy 1 file 1GB d.

[FZ]

may be hendaknya begini seh bro, kalau mau programming pakelah komp dengan spek jelek.
jika bisa menghasilkan aplikasi kenceng dengan spek jelek, itu cool bro.. programmernya jenius
namun sebaliknya, jika kita build suatu coding asal jadi saja, jalan seh jalan, namun banyak looping yang gak perlu.. mungkin kalau dijalan di komp cepat.. gak masalah.. kalau dijalankan di komp lambat.. bisa2 hang.. makanya hendaknya perlu "kerampingan" dalam hal coding..

bukan cowok aja suka cewek ramping.. komputer juga suka script ramping.. lebih "sexy"

mengenai masalah normalisasi, pendapat saya pribadi, hasil normalisasi akan lebih lambat sedikit, karena membutuhkan waktu untuk join joinan dulu dibanding table murni non normalisasi.
namun efek buruknya ada kalau gak normalisasi, keamanan data maybe sulit terjamin ya. karena jumlah file terlalu gede, jadi kalau mati lampu, atau user terminated mendadak apakah karena komp hang, dll maka kecenderungan database menjadi rusak dan corrup itu gede..

btw jawaban saya hanya sebatas pengalaman saya sebagai programmer foxpro yang masih amatiran.. gak pernah kuliah soal normalisasi.. blablabla.. cuma tau2 gitu aja.. jadi kalau ada salah tolong dikoreksi..

[tesla]

maksudnya resource gede? bandwith internet gede apa proses nya berat?

cpu usage nya yg gede karena prosesnya jadi byk...

id nya gak sebagai index ato primary key, tp sebagai no urut aja kok. gak berat khan?
soalnya lg cari akal supaya gak usah pake penampung data sementara, jadi lsg tarik dr database & tampilkan

sebenarnya saya jg ada pake yg beginian di beberapa table header-detail di bagian detail, dimana detailnya adalah data berurutan. misalnya di table penjualan, ada item produk, yg justru indexnya perlu kek gini... yg saya perhatikan cuma table kek begini imo adalah jumlah recordnya, ga mungkin besar. palingan utk 1 lembar faktur, item index max 20...

1 lagi,
kl ada 10rb record dalam 1 table(tanpa normalisasi), dan dibandingkan dengan ada 100 table yg masing2 ada 100 record dlm tiap table(normalisasi). mana yg lebih cepat dalam proses search?

diasumsikan yg 10rb record dalam 1 table(tanpa normalisasi) ada di record ke 9999 dan yg 100 table yg masing2 ada 100 record ada di table ke 100 record ke 99.
mana yg lebih cepat dlm proses search? mungkin perbedaanya hanya 1/1000sec, tp pengen tau mana yg lebih cepat?
soalnya proses copy file(write), 1 file 1GB dengan 1000 file masing2 1MB, kayanya lebih cepat copy 1 file 1GB d.

table tanpa normalisasi byk data redudant (berulang), ini akan bikin boros space, bandwith & makan cpu usage.
so normalisasi aja lah.