我發現了一個不同的解決方案,沒有浪費像生成一個類每個KEY
一樣多的內存。我生成單個類,大致看起來像這樣:
public class References {
// First, initialise all unique keys
public static final UniqueKey<TAuthorRecord> SysPk_14655 =
createUniqueKey(TAuthor.T_AUTHOR, TAuthor.ID);
// Then initialise all foreign keys
public static final Reference<TBookRecord, TAuthorRecord> SysFk_14666 =
createReference(SysPk_14655, TBook.T_BOOK, TBook.AUTHOR_ID);
public static final Reference<TBookRecord, TAuthorRecord> SysFk_14667 =
createReference(SysPk_14655, TBook.T_BOOK, TBook.CO_AUTHOR_ID);
// Factory method for unique keys
protected static <R extends Record> UniqueKey<R>
createUniqueKey(Table<R> table, TableField<R, ?>... fields) {
// Factory method for foreign keys referencing unique keys
protected static <R extends Record, U extends Record> Reference<R, U>
createReference(UniqueKey<U> key, Table<R> table, TableField<R, ?>... fields) {
}
從所生成的表格類的實際表然後可以參考和使用上述密鑰。我按照BobG的建議查看了JPA註釋。但我沒有發現他們非常有用的描述:
- 多場鍵(
@IdClass
需要一個類型作爲參數,我想避免這種類型)
- 多字段引用(怎麼辦呢?)
- 從一個表到另一個表使用不同的鍵的多個引用
- 唯一鍵與主鍵共享許多屬性。
的一些評論中提到我爲什麼要建立這樣一個發電機,因爲有很多既定的框架。我正在爲http://www.jooq.org做這個。我覺得jOOQ正在填補今天數據庫抽象可能性的空白。
聽起來像是在燙髮空間填滿時獲取OutOfMemoryErrors的祕訣。 – duffymo 2011-05-02 18:26:59
謝謝duffymo。這就是我問的原因。我很好奇具體的數字,雖然 – 2011-05-02 18:27:54
沒有,因爲我不知道你產生什麼。我很好奇 - 當你有很多持久化解決方案(直接JDBC,Hibernate,iBatis,TopLink,JPA等)時,爲什麼你認爲這是必要的?你買的這些解決方案不是什麼? – duffymo 2011-05-02 18:30:45