### 替代方案 可以使用多種不同的方式來定義自己的注解用于上述任務。例如，你可以使用一個單一的注解類 **@TableColumn**，它擁有一個 **enum** 元素，元素值定義了 **STRING**，**INTEGER**，**FLOAT** 等類型。這消除了每個 SQL 類型都需要定義一個 **@interface** 的負擔，不過也使得用額外信息修飾 SQL 類型變的不可能，這些額外的信息例如長度或精度等，都可能是非常有用的。 你也可以使用一個 **String** 類型的元素來描述實際的 SQL 類型，比如 “VARCHAR(30)” 或者 “INTEGER”。這使得你可以修飾 SQL 類型，但是這也將 Java 類型到 SQL 類型的映射綁在了一起，這不是一個好的設計。你并不想在數據庫更改之后重新編譯你的代碼；如果我們只需要告訴注解處理器，我們正在使用的是什么“口味（favor）”的 SQL，然后注解助力器來為我們處理 SQL 類型的細節，那將是一個優雅的設計。 第三種可行的方案是一起使用兩個注解，**@Constraints** 和相應的 SQL 類型（例如，**@SQLInteger**）去注解同一個字段。這可能會讓代碼有些混亂，但是編譯器允許你對同一個目標使用多個注解。在 Java 8，在使用多個注解的時候，你可以重復使用同一個注解。