[TIPS] Membuat aplikasi sebagai profesi (secara profesional)

[sensaribar]

Sory nih jangan tersinggung yah, Sekedar Masukan saja bukan mau debat

tentu saja tidak mas Leosan88  :lol:

Sejauh ini aku pake surrogate key tidak ada masalah.
Memang sih jumlah transaksi di aplikasiku setiap harinya tidak banyak, paling sekitar 3000an.  
Masukan mas Leosan memang harus dipertimbangkan.
Transaksi 1 juta sehari ??  :roll:

Mudah-mudahan mas Foxy ada solusi nih, soalnya beliau kan yang udah pake lama.  :oops:

Yang aku suka dari surrogate key adalah otomatis memecahkan masalah saya ketika masih pake kode yang bermakna.

Menurut teori yang aku baca, keuntungannya :
- lebih stabil, karena tabel terkait tidak terkena dampak perubahan
- lebih hemat diskspace, karena hanya satu atribut numerik sederhana
- otomatis memecahkan masalah pada inteligent key

Saya yakin tidak ada yang sempurna di dunia ini, termasuk surrogate key.
Saya berharap rekan-2 yang sudah pake lebih lama lagi bisa sharing dong.

rgds,

[fish]

hek, tadi dapet nada protes dari mas leosan, masalah surrogate key

ini nurut fish:
surrogate key memang istilahnya "harus" dipakai
malah sebenarnya, rule of thumbs: "setiap tabel harus mempunyai primary key, walaupun merupakan tabel transaksi" nah lo
[n] Someone who takes the place of another person
itu amat sangat HIDDEN, bahkan user ga perlu tau kalo di tabel doi ada surrogate key tersebut

ada yang protes dulu waktu ngikut makan di seberang:

saya ngedit datanya jadi susah, masa tabel isinya:
"_XXX _XXX2 _XXX3 1 2" susah bo!
kan lebih enak "TIPE_PRODUK1 TIPE_JUAL2 KODE_PRODUK 1 2"

ya jawabnya simpel kan:
"saya bikin program bukan buat langsung diakses tabelnya kok..."

jadi ada beberapa field yang memang user sendiri tidak perlu tahu gunanya, cukup kita saja hehehe... hanya pastikan, dokumentasi memadai

surrogate key, harap dibuat dengan menggunakan "unlimited" key generation, yang kalo bisa "fast, reliable, unique"
jangan kawatir bahwa surrogate key harus bisa "terbaca" oleh user, karena surrogate

jadi contoh: SYS(2015)

untuk autonumber aja, tidak dianjurkan dijadikan sebagai surrogate key karena, autonumber mempunyai keterbatasan pada long int, yaitu: 2 milyar nomor

sedangkan sys(2015) -> digenerate dari waktu komputer,yang notabene adalah WAKTU, dimensi ke 4... unlimited

tapi penggunaan surrogate key sendiri bila menggunakan SYS(2015) sendiri masih terbentur pada keterbatasan, yaitu masalah CLIENT
karena sys(2015) sendiri masih digenerate dari TIME (komputer client) dimana misal 2 client input pada saat yang bersamaan, bisa terjadi surrogate key yang DOBEL (walau kemungkinan kecil)

atau anda dapat membuat generator buat surrogate key anda sendiri, yang penting diusahakan: UNLIMITED

jadi jangan ragu untuk menggunakan surrogate key, gunakan apabila anda rasa memerlukan, apabila tidak yakin, jangan gunakan, bantulah programmer yang akan meneruskan pekerjaan anda nantinya hehehe...

ps:
windows sendiri sudah menyediakan fasilitas untuk unique key ini, yang diberi nama Globally Unique IDentifier (GUID)
GUID ini, digenerate dari data TIME + NETWORK ADDRESS
(walaupun anda tidak punya NETWORK CARD, windows punya ID tersendiri untuk LOOPBACK ADAPTER)

GUID ini terdiri dari 16 byte data (wow!) dan kalau diextract, bisa njebluk jadi 36-38 byte, tapi konon, dikatakan bahwa bakal ada duplikasi UID dalam 1 banding ber trilliun-triliun generate, cukup memadai bukan?

berikut cara untuk mendapatkan GUID:

[foxpro]&&-- returns GUID
lparameters tlConvert as Logical, tlEnclose as Boolean

declare integer CoCreateGuid in "ole32.dll" as dllCoCreateGuid string @

local lcGuid, lcTemp, liCnt
lcGuid = replicate(chr(0), 16)

=dllCoCreateGuid(@lcGuid)

&&-- this is just quick extract, the real ones doesn't work this way
if tlConvert then
  lcTemp = ""
  for liCnt = 1 to 16 step 1
    lcTemp = lcTemp + right(transform(asc(substr(lcGuid, liCnt, 1)), "@0"), 2)
    if inlist(liCnt, 4, 6, 8, 10) then
      lcTemp = lcTemp + "-"
    endif
  endfor
  lcGuid = lcTemp
endif

if tlEnclose then
  lcGUID = "{" + lcGUID + "}"
endif

return lcGuid[/foxpro]


sedangkan di SQL Server, anda dapat menggunakan perintah: NEWID() untuk mendapatkan GUID ini

maz taz, iki code script foxprone kok rodo ngaco yo, dadi metu dobel2 wae
piye seminare?

[Feihung]

wah, TQ mas Foxy & mas Fish....
dapet ilmu baru nih

[eddy]

Wah terima kasih semuanya.  Jadi dapat masukan baru nih.

Tapi ada pertanyaan.
Misalnya tabel transaksi header & detil
.
Kalo pake surrogate key, berarti langkahnya lebih panjang yah,
1. Cek apakah nomor transaksi sudah ada ?
2. Generate Surrogate Key.

Untuk menghubungkan header sama detilnya jadi yang kita
pakai yang surrogate key ato nomor transaksi ?

Thanks

[taz]

surgorate key...hem...kaadang pake, kadang tidak  
kalo dari kesimpulan saya:
1. PK -> Must have
2. Surgorate Key -> some time, tergantung kebutuhan.
buat saya ini saya gunakan buat tabel yang DIPASTIKAN tidak ada data yang banyak, tapi sering digunakan DAN tidak sering terjadi perubahan data, seperti TIPE PERKERJAAN misalanya
3. GUID -> platform independent.
untuk saya, yang sering pake mySQL dan ORACLE, hampir selalu server pake UNIX (LINUX, FREEBSD dll), jadi ada implementasi GUID yang lain, akan tetapi generate ID dari database yang menggunakan OS UNIX lebih / sama dengan yang di generate oleh sistem itu sendiri (dalam beberapa kasus malah lebih baik, terutama jika servernya nggak cuman satu/saling sinkronisasi / pake GRID Computing di ORACLE)
SO...
tergantung kebutuhan lah...
eniwei, saya kurang setuju dengan kang fish tentang :

saya ngedit datanya jadi susah, masa tabel isinya:
"_XXX _XXX2 _XXX3 1 2" susah bo!
kan lebih enak "TIPE_PRODUK1 TIPE_JUAL2 KODE_PRODUK 1 2"

kang fish penganut faham hardcore programmer yah      
di lingkungan saya, metode tersebut kurang cocok di terapkan, karena jika saya terapkan, walaupun ada dokumantasinya dari saya, tetapi si dokumentator bagian produksi bisa protes nek!    (yup, dokumentasi bagian produksi ada sendiri, bug testing ada sendiri, dokumentasi project IE: manual ada sendiri).
kalo develop untuk kepentingan sendiri sih begitu. saya setuju bahwa itu tidak untuk konsumsi user (tentu donk! masak ada sih sistem kita tunjukin ke user, harusnya menejemen itu kita buatkan aplikasi sendiri TANPA informasi secara teknis ke user, misalnya PROSES BACKUP/RESTORE database; nggak perlu banget kan kita pake mySQL-Front trus kita kasih ke user? LOL)

maz taz, iki code script foxprone kok rodo ngaco yo, dadi metu dobel2 wae

sori bro, versi ALPHA gitu loh    lom sempet ngebetulin. kalo baris QUOTE bisanya detect "//" (masih kaya PHP asli   ) itu saya ganti "&&" biar nggak ngaco banget  

piye seminare?

check u'r email plz

[fish]

dudu hardcore, itu client yang tanya hehehe...

pake surrogate key bukan berarti nambah kerjaan, ok, memang nambah yah... beberapa baris(?), tapi keuntungannya ada, apalagi ditambah dengtan time stamp field
SURROGATE + TIMESTAMP -> update cepet
ditambah index pada DELETED, tambah cepet berarti

misal gini:
surrogate + timestamp -> index xCheckUpdate

misal anda sedang edit data faktur nomor 1
gimana anda check apakah record ybs sudah berubah?

kalau skenario VFP, anda bisa aja dengan LOCKING record
gimana kalau skenario SQL Server? SQL server itu cursor based, bukan record based? nah lo...

kalau anda punya index xCheckUpdate itu,
anda tinggal cari SEEK(this.cSurrogate + this.cTimeStamp, "TABELKU", "xCheckUpdate")
kalo .f. berarti data tersebut udah diobok-obok ama user lain
kalo .t. berarti data masih... ehm... ting-ting

contoh:
asumsi tabel:

FAK002 CUS1000 USE007 -> tabel FAKTUR
FAK002 PRO1000 1 -> tabel FAKTUR_LINEITEM Row 1
FAK002 PRO1001 2 -> tabel FAKTUR_LINEITEM Row 2
FAK003 PPO1002 3 -> tabel FAKTUR_LINEITEM Row 3

case: PRO1001 akan diganti quatinty-nya menjadi 100

skenario VFP:
SQL update yang "ideal" untuk updating, adalah kira2 seperti ini (perhatikan nQty di SQL-Update):

Code: [Select]


if indexseek("FAK002" + "PRO1001", .t., [FAKTUR_LINEITEM], "xNoFak") then
 if nQty # 2 then
   messagebox("Data sudah dirubah oleh user lain")
   return .f.
 endif
endif

update [FAKTUR_LINEITEM]
set nQTY = 100
where
cFAK = "FAK002"
and cPro = "PRO1001"
and nQty = 2

iya kan? kalau anda tanya kok nQTY dimasukkan sih?
jawabannya: itu adalah updatable field, jadi harus di cek, sehingga kalau ada perubahan oleh user lain, perubahan itu tidak ditimpa oleh anda (sort of...) code diatas, ngecek nQty 2x

nah sekarang kita ganti tabel tersebut dengan penambahan surrogate + timestamp

SURRO11 FAK002 CUS1000 USE007 TIME11

SURRO11 SURRO21 FAK002 PRO1000 1 TIME21
SURRO11 SURRO22 FAK002 PRO1001 2 TIME22
SURRO11 SURRO23 FAK003 PPO1002 3 TIME23

SURRO11 -> surrogate key dari FAKTUR
SURRO2x -> surrogate key FAKTUR_LINEITEM

TIME21 -> timestamp FAKTUR_LINEITEM (bisa gunakan SYS(2015), DTOS() terserah anda)

nah sekarang kita mau update data Row2

Code: [Select]

if !indexseek("SURRO22" + "TIME22", .f., [FAKTUR_LINEITEM], "xCheckUpd") then
  messagebox("Data sudah dirubah oleh user lain")
return .f.
endif

*-- update
update [FAKTUR_LINEITEM]
set nQty = 100
where
uSuro = "SURRO22"
and uTStamp = "TIME22"

plus keuntungan penggunaan surrogate + timestamp:
"Data mana yang sudah diupdate dari terakhir backup?"

Code: [Select]


select * from [FAKTUR_LINEITEM]
where uSuro + uTStamp not in (
select uSuro + uTStamp from [BACKUP_FAKTUR_LINEITEM] where !deleted())
and !deleted()


easy job

jadi silahkan anda mau pake yang mana... saya tidak memaksakan penggunaan surrogate key + timestamp hehehe, yang penting ya itu, bantulah programmer setelah anda
ya jeleknya pake surro + time... file tabelnya jadi gede (tapi sekarang harddisk udah sampe > 120 gb..., jadi inget dulu harddisk pertama g cuma 512 MB)

ps: code diatas hanya contoh, tidak dicek menggunakan aplikasi, jadi kalo ada error ketik2 ato error pas jalan ya maklum aja ye..

[aris_ah]

wah nice tips mr.fish.....
aku jadi kepikiran klo metode yg barusan (suro+timestamp)  bisa aku pake buat validate stok barang pada saat di update jumlahnya oleh user...

selama ini aku masih cari-cari jalan untuk lock / unlock pada saat proses update.
nah dengan cara suro+timestamp bisa dijadikan kondisi / meng-validate record tersebut..

thank ur tips mr.fish......

[armen_sakti]

wah...  Seru nih

Tapi saya suka baca aja tidak banyak yang dapat saya tambahkan. Kecuali

saya tidak memaksakan penggunaan surrogate key + timestamp hehehe, yang penting ya itu, bantulah programmer setelah anda
ya jeleknya pake surro + time... file tabelnya jadi gede (tapi sekarang harddisk udah sampe > 120 gb..., jadi inget dulu harddisk pertama g cuma 512 MB)

Pernah th 2001-2002 saya terapkan metoda surrogate key + timestamp, ada sisi bagusnya juga ada jeleknya. Bagusnya sudah diuraikan mr. Fish sebelumnya. Dilain sisi, Hardware Resource client saya masih saat itu menggunakan server P3 550, MM 256, HD 20 GB. Server ini terkoneksi 25 Workstation P I, 233 MMX, mm 32 , hd , 10 gb. Transaksi 800- 1 jt rb record per bulan. Alangkah lambatnya prosesing saat itu, hingga akhirnya saya tidak pakai lagi timestamp, cuman surrogate key aja. Namun saat ini, surrogate key + timestamp tidak jadi alasan lagi untuk tidak memakainya. Hanya masalahnya si Owner tidak bersedia Upgrade System dan Hardwarenya....he...he...he..

ps.
mas Foxy, sepertinya ini sudah meluas artikelnya... :lol:

[foxy]

Heya guys!

Thanks for your reply. I take that as an encouragement to give more.

Anyway, saya akan coba ikutan di issue mengenai surrogate primary key (kita singkat SPK aja ya...).
Seperti yang sudah saya disclaim; saya percaya bahwa setiap profesional mempunyai preference dan pemikiran sendiri. Karena itu, terserah Anda apakah mau pakai SPK atau tidak. Kalau saya, saya selalu pakai SPK di semua tabel. Tipe-nya ada yang int, ada yang long int. Pernyataan leosan88 memang betul. Kalau satu hari 1 juta transaksi memang SPK itu akan overflow dalam waktu singkat. Tapi terus terang saya belum cukup beruntung untuk punya client dengan 1 juta transaksi sehari Sejauh ini client saya yang punya transaksi insertion pada tabel child level terdalam  paling banyak cuman 12,000 insertion per hari (itu jumlah terbesar dalam 2,5 tahun terakhir). Jadi kalau saya ambil 10,000 aja. Itu berarti field integer akan overflow dalam:
2 milyar++ / 12,000 = 166,666++ hari. Kita ambil aja 160,000.

Kalau diasumsi client saya buka full 365 hari setaun, itu berarti overflow akan terjadi dalam waktu 160,000 / 365 = 438++ tahun.
Dengan kata lain, saya sangat positif sekali overflow itu tidak akan pernah terjadi. Bahkan dengan transaksi 10 kali lipat itu pun, saya masih berani menjamin integritas database-nya. Jadi memang kembali lagi ke requirement-nya.

Penggunaan SYS(2015) seperti post fish (hey ya fish... how's BEC?) juga punya kelemahan yang sudah di sampaikan di post itu juga. Penggunaan GUID cukup OK. tapi menurut saya penggunaan space 38 byte (extracted) untuk sebuah primary key akan menurunkan performance. IMO, semua sistem komputer akan lebih mudah dan lebih cepat mengolah digit (integer) daripada string (character). Jadi, saya hanya menggunakan GUID kalau database-nya terdistribusi (maksud terdistribusi; contoh simplenya adalah aplikasi POS di 10 lokasi, jalan secara offline dan punya dbc sendiri. Setiap sore apps ini meng-upload data transaksi ke server via DUN. Karena table sales dan detail_sales menggunakan GUID sebagai SPK, maka saat di upload, bisa langsung APPEND FROM tanpa kuatir conflict).

That's about the issue, now about the second part of the article.
Di waktu luang, saya sudah buat artikel yang kedua. Tinggal dikit lagi, karena di artikel itu saya juga mencoba menunjukkan proses normalisasi, dan kemarin malam sudah sampai 2NF. Target saya artikel dua itu sampai selesai pembahasan mengenai design struktur database. Artikel-nya sampai sekarang bahkan sudah lebih panjang daripada artikel pertama. Nggak tau nih, menurut mas Taz lebih baik di-post kemana. Mudah-mudahan bisa beres dalam dua-tiga hari lagi.

WBR,

Foxy

[fish]

hey ya fish... how's BEC?

sudah ga di BEC / Istana Group lagi, udah 1 tahun lebih mengelandang di jalan2 bandung aja
jadi cowok panggilan aja sekarang kesana, kesini, bayaran murah, dijamin bebas penyakit huehehehe...

[foxy]

sudah ga di BEC / Istana Group lagi, udah 1 tahun lebih mengelandang di jalan2 bandung aja
jadi cowok panggilan aja sekarang kesana, kesini, bayaran murah, dijamin bebas penyakit huehehehe...

Wah, kelau fish menggelandang di jalan, bahaya dong. Bisa ditangkep jadi ikan bakar bumbu cobek

Gini aja, masih ada waktu ngajarin saya private gimana caranya bikin aplikasi web based n-tier berbasis COM+ nggak? Kalau minat, ada pabrik chemical di bandung yang mau bayarin nih... Dia mau bikin MRP. Saya pikir, daripada desktop application, sekalian deh, dia disuruh ngebayarin fish untuk ngajarin saya web based apps... PM me if you are interested

WBR,
Foxy

[fish]

aduh ma kasih tawarannya

kalo itu sih ga usah bayar (nah ini kata orang saya tu goblok pisan! huehahaha)
karena saya sedang nyiapin 1 project free tentang peminjaman buku, sekalian ama lagi bikin website pribadi, yang rencananya nanti akan ada "forum" yang ngisinya lewat aplikasi, ntar di akan dipublish APInya

kalo ga sabar, bisa coba API Google, tapi itu cuma 1 arah, cuma bisa request tanpa bisa nge-save
linknya kalo ga salah http://api.google.com
itu buat integrate google search di aplikasi anda (biar keliatan keren bo!)

kalo mau belajar n-Tier web based, yang perlu disiapkan:
1. VFP (terutama XML)
2. Visual Studio > 6 (2000 / 2003 preferred, 2005 dibandung adanya versi DVD)
3. Windows XP Server 2003 (atau XP tapi install .Net Framework dulu, biar bisa jalan ASPX)
4. IIS 5 / 6
5. Kopi kalau anda suka kopi
6. rokok kalo anda merokok
7. pengetahuan tentang XML (kulit juga boleh)

trus kendala:
jarang shared hosting yang mau host VFP runtime kudu dedicated server
akhirnya harus... bikin DLLnya yang bisa JIT activation, ya... .NET itu

ntar kita liat aja...

[tbsqc01]

dear all...........sory berat mau numpang nimbrung nih.....maaf yah kalau pertanyaannya konyol pisan.......maklum belajar program baru beberapa hari.....maksudnya surogate primary key apaan yah...bedanya ama primary key di tabel apa ?   bikinnya gimana ?....maklum sampai hari ini saya masih taraf niru....baru beberapa yang bisa saya pahami dan jiwai..selebihnya masih blank....
saya jadi tertarik tapi ilmunya cetek pisan...he...he...he.... karena saya lagi bikin program buat kantor sendiri nih....dengan tujuan sekalian belajar ma mudahin gue kerja...so sambil nyelam minum air (moga2 kagak tenggelam) please mohon pencerahan....bisa dapet di mana nih tutorial lengkapnya....tks semua


ps :
.....gue inget omongan dosen senior gue......pertama kali masuk ke kelas dia ngomong gini....."MOHON BANTUANNYA KE SEMUANYA BAGAIMANA KAMI BISA MEMBANTU ANDA SEMUA"....it's nice world....

[taz]

menurut mas Taz lebih baik di-post kemana. Mudah-mudahan bisa beres dalam dua-tiga hari lagi.

di-post kemana saja, ntar tetep masuk ke tahap sruting hehehe. ntar saya yang alokasikan deh. ditunggu yah papa foxy yang baik hati wekekekeke
hem...n-Tier web based sangat mudah pake php. nggak perlu konfigurasi web server sesusah IIS (maklum....IIS hampir nggak pernah nyentuh, enakan apache, semua konfigurasi mode text  )
Sebenernya googlepun pake SOAP, nah keunggulan PHP itu kita nggak perlu ada deklarasi/setting/konfigurasi apapun di sisi server. dah include, tinggal kopi, paste, jalanin servicenya...wala! tapi, itu sih saya, bisanya PHP, nggak bisa ASP wekekeke....
kalo pake ISAPI vfp bisa juga kan kang fish? kaya foxite tuh, keren (karena kodingnya pasti bejibun) passingnya nggak perlu XML. susah handle XML (atau saya yang oon/nggak mau belajar parsing XML yah?!?) weks!
eniwei, seperti email kang fish yang lalu, piye progressnya? sampe mana? janjinya mo ada artikelnya loh wataaaaa!!!!

surogate primary key?
http://fox.wikis.com/wc.dll?Wiki~SurrogateKey~SoftwareEng
primary key?
http://fox.wikis.com/wc.dll?Wiki~PrimaryKey~SoftwareEng

http://fox.wikis.com -> gudangnya pengetahuan terori dan praktek VFP/FoxPro, seperti saya yang nggak pernah kena bangku sekolah IT, disitu gudangnya WIKI FoxPro

[fish]

sampe mana apanya?
yang parsing artikel? ngko entek bandwith-e lho hehehe...

kalo yang pake web, baru ditunda soalnya lagi buat webnya dulu
n lagi ada gawean suruh bikin class buat report listener + print preview yang bisa diinclude ke project / automation, dengan tambahan ++
jadi kebutuhan dompet didahulukan, gomen... hehehe...

ntar dikabarin kalo udah jadi