Až Vám zčerná obrazovka, přejděte na Linux!

Proč používat Linux

středa 9. dubna 2008

Hibernate a tabulky bez primárních klíčů

Jsou lidi, kteří tvrdí, že mít tabulku bez primárního klíče je nesmysl. A proto se bez něj Hibernate neumí pohnout. Já s nimi nesouhlasím.
Mějmež jednoduchý příklad: chceme uložit přichodivší fakturu do databáze. Faktura obsahuje hlavičku (kdo, kdy,...) a několik položek. Každá položka faktury má pevně danou strukturu. Z hlediska databázisty jednoduchý případ jak facka. Jedna tabulka pro fakturu (ID faktury, hlavička a stav), druhá pro položky (id faktury jako cizí klíč a atributy položky (cena, množství,...).
No jo, ale zkuste toto udělat v Hibernate! Jediná cesta, kterou jsem vygoogloval, je vytvořit fake_id pro každou položku každé faktury! FUJ! řeknou kování DBáci. A já s nimi.
Možná, že znáte jinou cestu. Rád se ji dozvím.

3 komentáře:

Ales řekl(a)...

Tohle jsem nejak nepochopil.
V Hibernate mam prece moznost pouzivat slozene primarni klice. Napr:
class Uzivatel {
@Id
private String idCislo;
}

@Embeddable
class NavstevnostPK {
private String idCislo;
private Date cas;
}

class Navstevnost {
@EmbeddedId
private NavstevnostPK pk;
@JoinColumn(insertable = false, updatable = false)
private Uzivatel uzivatel;
}

Co se tyce vazby OneToMany, mam moznost za prve urcit insertable a updatable a za druhe mam moznost urcit, jestli Fetch bude EAGER ci LAZY.
Osobne nevidim problem v mapovani z DB do ORM jako je Hibernate.
Nekde jsem cetl, ze i slozene primarni klice jsou mor, ale osobne je vyzuvam a to dost hojne, bez jakehokoli problemu.
Podle me, primarni klic by MEL byt v kazde tabulce, kterou vytvorim. Jak budu napr. unifikovat zaznam v tabulce, kde bych chtel nad takovymi zaznamy delat CRUD?

Oto 'tapik' Buchta řekl(a)...

Mám bohužel tabulku, kde složeným primárním klíčem by byl celý řádek, což se mi dost příčí. Navíc je možné, i když hodně hypoteticky a to pouze v případě, že je na subsystémech rozsynchronizován čas a k identické události by došlo "ve stejný" okamžik, ale pominout to nelze, že by se jeden řádek mohl vyskytnout vícekrát. Proto musím zavádět fejky. Potíž je v tom, že stačí Create a Select, update nepotřebuju vůbec a Delete pouze hromadně. Hibernate jsem chtěl použít čistě pro urychlení vývoje, výsledek pojedu stejně přímo nad JDBC, takže mi zavedení fejku zas tak nevadí.

Oto 'tapik' Buchta řekl(a)...

Navíc k mému příkladu - co když opravdu na faktuře je jedna položka dvakrát? Příklad - v sámošce pokladní místo zadání 2xčárový kód(jogurtXY) přejede dvakrát čtečku a na účtence se objeví čárový kód(jogurtXY), čárový kód(jogurtXY). Rozlišit tyto dvě položky nepůjde jinak než fejkovým ID položky, které je v databázi naprosto k ničemu.