personal opinion:

baiknya memang mulai dari hibernate table, lalu forward engineer, kecuali
kalau terpaksa (seperti adelwin) jadi harus reverse engineer dari database
ke object model - karena table di bank biasanya udah ada, kita cuma perlu
nambahin dikit2.

tujuan dari object/relational mapping kan menjembatani database yang
relational dan object, yg di-traverse dengan menggunakan object methods.
kalau data model kita definisikan dari awal (aplikasi kita sendiri yang
desain), biarkan hibernate yang menggenerate table. karena kita memanipulasi
dengan object oriented language, kita perlu membuat sebisa mungkin object
oriented friendly.


On 11 February 2010 14:03, Adelwin, Adelwin <adelwin.adel...@sc.com> wrote:

>
>
>  Maaf…
>
> Salah pencet…
>
> Lanjutin lagi yah
>
>
>
> Tapi sebenernya pengalaman gue sih table journal biasa nya kagak gituh
> bentuk nya sih :D
>
> transaction_id,
>
> credit_amount,
>
> debit_amount,
>
> transaction_code (apakah ini transaction biasa ato reversal),
>
> ada reference…
>
> ada date
>
>
>
> biasa nya Cuma gituh… yah ada beberapa field yang sesuai keperluan bisnis
> sih…
>
> kayak user_id, siapa yang bikin transaction…
>
> approval date juga contoh nya…
>
> reference ituh ntar FK ke something else…
>
> kalo gak salah namanya chart of account yah?CMIIW…
>
> ini semacam transaction type master gituh…
>
> dari siapa… ke siapa… category… gituh2…
>
>
>
>
>
>
>
> *Adelwin Handoyo  |  Senior Consultant - Wholesale Bank*
> *Standard Chartered Bank*
> Plaza By The Park #06-00, 51 Bras Basah Road. Singapore (189554)
> *T* : (65) 655 72441  |* **E* adelwin.adel...@sc.com
>
>
>
>
>   ------------------------------
>
> *From:* Adelwin, Adelwin
> *Sent:* Thursday, February 11, 2010 1:59 PM
> *To:* 'jug-indonesia@yahoogroups.com'
> *Subject:* RE: [JUG-Indonesia] Desain tabel journal
>
>
>
> Kenapa kok sekarang trend nya tuh justru orang design domain class dan
> tables sesuai apa mau nya hibernate yah?
>
> Apa ini kagak kebalik yah?
>
> Justru nya harus nya khan kita bikin code hibernate yang bisa cocokin apa
> mau kita dan keadaan database…
>
> Emang sih katanya kalo pake hibernate ituh design nya harus top-down…
>
> Tapi menurut gue sih kalo sampe harus bener2 di balik design hibernate
> domain dulu baru create table yang enak… wah… agak gimanaaa gt …
>
>
>
> Untuk menjawab pertanyaan…
>
> Iyah… bener begitu data model nya…
>
> Tapi agak nya kurang cascade nya…
>
> Asal udah di annotate cascade type nya… hibernate bisa cascade otomatis…
> baik select, update ato insert…
>
>
>
> Gue belom sempet bongkar code2 nya hibernate sampe dalem…
>
> Tapi ada beberapa tebakan neh…
>
> Di property DateC sebenernya gak perlu di annotate Temporal juga bisa jalan
> dengan baik…
>
> Dugaan gue Temporal inih untuk kalo property type nya bukan Date
>
>
>
> Kalo table name nya akan sama seperti class name, sebenernya gak perlu di
> annotate Table lagi…
>
> Bisa di baca di readme nya kok gimana hibernate akan guess table name
> berdasarkan non-qualified class name
>
>
>
> Tapi sebenernya pengalaman gue sih table journal biasa nya kagak gituh
> bentuk nya sih :D
>
> transaction_id,
>
> credit_amount,
>
> debit_amount, transaction_code (apakah ini transaction biasa ato reversal),
> ada reference
>
>
>
> *Adelwin Handoyo  |  Senior Consultant - Wholesale Bank*
> *Standard Chartered Bank*
> Plaza By The Park #06-00, 51 Bras Basah Road. Singapore (189554)
> *T* : (65) 655 72441  |* **E* adelwin.adel...@sc.com
>
>
>
>
>   ------------------------------
>
> *From:* jug-indonesia@yahoogroups.com [mailto:
> jug-indone...@yahoogroups.com] *On Behalf Of *onsir salman
> *Sent:* Thursday, February 11, 2010 1:12 PM
> *To:* jug-indonesia
> *Subject:* [JUG-Indonesia] Desain tabel journal
>
>
>
>
>
> Bagaimana cara desain tabel journal sperti ini klw pake hibernate
>
> Misal tabel journal
> Date -->tanggal transaksi
> kode -->kode; kode transaksi dari barang masuk atau keluar
> Credit -->nilai
> Debit -->nilai
> kodeSC -->berisi kode suplier atau customer
>
> tabel BrgMasukHD
> Date
> Kode
> Kode_SUP
>
> tabel BrgKeluarHD
> Date
> kode
> Kode_CUS
>
> tabel supplier
> kode
> Nama
>
>
> tabel customer
> kode
> nama
>
>
> isi tabel supplier
> kode Nama
> S01 Suplier1
> S03 suplier3
>
>
> isi tabel customer
> kode nama
> c01 customer1
> co2 cuatomer2
>
>
> isi tabel BrgMasukHD
> Date        kode    kode_sup
> 1-1-2010  M0001  S01
> 2-1-2010  M0002  S03
>
>
> isi tabel BrgKeluarHD
> Date         Kode   kode_cus
> 6-1-2010   K0001 C01
> 7-1-2010   K0002 C02
>
>
> isi tabel journl
> Date       Kode     Credit Debit KodeSC
> 1-1-2010 M0001    1000 0        S01
> 2-1-2010 M0002    2000 0        S03
> 6-1-2010 K0001    0      200     C01
> 7-1-2010 K0002    0      300     C02
>
>
> apakah spt ini, desain tabelnya
>
> @Entity
> @Table(name = "journal")
> public class Journal implements java.io.Serializable {
>
> @Id
> @GeneratedValue(generator = "system-uuid")
> @GenericGenerator(name = "system-uuid", strategy = "uuid")
> @Column(name = "ID_JOURNAL")
> private String idJournal;
>
> @Column(name = "DATEC")
> @Temporal(javax.persistence.TemporalType.DATE)
> private Date datec;
>
> @Column(name = "KODE", nullable = false, unique = false, length = 40)
> private String kode;
>
> @Column(name = "KODE_SC", nullable = false, unique = false, length = 20)
> private String kodeSc;
>
>
> @ManyToOne
> @JoinColumn(name = "ID_MASUK")
> private BrgMasukHd brgMasukHd;
>
> @ManyToOne
> @JoinColumn(name = "ID_KELUAR")
> private BrgKeluarHd brgKeluarHd;
>
> @ManyToOne
> @JoinColumn(name = "ID_SUP")
> private Supplier supplier;
>
> @ManyToOne
> @JoinColumn(name = "ID_CUS")
> private Customer customer;
>
> apakah utk isi datanya spti
>
> utk transaksi barang masuk
> kode akan berisi kode barang masuk, Date berisi tgl barang masuk, kode_sc
> akan berisi kode supplier, id_sup berisi idSupplier, id_cus null, id_masuk
> berisi id barang masuk, id_keluar null
>
> utk transaki barang keluar
> kode akan berisi kode barang keluar, Date berisi barang keluar, kode_sc
> akan berisi kode customer, id_sup null , id_cus berisi id customer
> id_masuk null, id_keluar  berisi id barang keluar
>
>
>
> terima kasih
>
>
>
>
>
>   This email and any attachments are confidential and may also be privileged. 
>  If you are not the addressee, do not disclose, copy, circulate or in any 
> other way use or rely on the information contained in this email or any 
> attachments.  If received in error, notify the sender immediately and delete 
> this email and any attachments from your system.  Emails cannot be guaranteed 
> to be secure or error free as the message and any attachments could be 
> intercepted, corrupted, lost, delayed, incomplete or amended.  Standard 
> Chartered PLC and its subsidiaries do not accept liability for damage caused 
> by this email or any attachments and may monitor email traffic.
>
>
>
> Standard Chartered PLC is incorporated in England with limited liability 
> under company number 966425 and has its registered office at 1 Aldermanbury 
> Square, London, EC2V 7SB.
>
>
>
> Standard Chartered Bank ("SCB") is incorporated in England with limited 
> liability by Royal Charter 1853, under reference ZC18.  The Principal Office 
> of SCB is situated in England at 1 Aldermanbury Square, London EC2V 7SB. In 
> the United Kingdom, SCB is authorised and regulated by the Financial Services 
> Authority under FSA register number 114276.
>
>
>
> If you are receiving this email from SCB outside the UK, please click 
> http://www.standardchartered.com/global/email_disclaimer.html to refer to the 
> information on other jurisdictions.
>
>
>  
>



-- 
-o--o---( ^  ^ )---o--o-
Speed Optimization: Seek and ye shall find!
In case it isn't in the cache yet, too bad, you've to wait 40x longer.
Daniel Baktiar (http://dbaktiar.wordpress.com)

Kirim email ke