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.
Příspěvky
Dagblog přesunut na vlastní doménu
před 8 lety
3 komentáře:
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?
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í.
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.
Okomentovat