我认为我对UDT和JDBC的了解已经很全面了，直到SO上的某个人向我指出了java.sql.SQLInput和java.sql.SQLData JavaDoc的一些细节。那个提示的本质是（来自SQLInput）：
一个输入流，其中包含表示SQL结构类型或SQL不同类型实例的值流。此接口仅用于自定义映射，由驱动程序在后台使用，并且程序员从不直接调用SQLInput方法。
这与我所习惯的相反（当与Oracle JDBC驱动程序一起使用时，也是稳定的生产系统中使用的）：实现
JDBC驱动程序将使用回调方式调用我的自定义类型，使用以下方法：
我使用了一种方法，并从
对我来说，这似乎是实现此自定义映射的完美方法。采用此方式的好处包括：
一个输入流，其中包含表示SQL结构类型或SQL不同类型实例的值流。此接口仅用于自定义映射，由驱动程序在后台使用，并且程序员从不直接调用SQLInput方法。
这与我所习惯的相反（当与Oracle JDBC驱动程序一起使用时，也是稳定的生产系统中使用的）：实现
SQLData并在自定义映射中提供此实现。ResultSet.getObject(int index, Map mapping)
JDBC驱动程序将使用回调方式调用我的自定义类型，使用以下方法：
SQLData.readSQL(SQLInput stream, String typeName)
我使用了一种方法，并从
SQLInput流中读取每个字段。最后，getObject()将返回一个正确初始化的实现SQLData的实例，该实例保存来自UDT的所有数据。对我来说，这似乎是实现此自定义映射的完美方法。采用此方式的好处包括：
- 我可以使用标准API，而不是使用供应商特定的类，如
oracle.sql.STRUCT等。 - 我可以生成源代码来自我的 UDT，包括适当的 getters/setters 和其他属性。
- 您认为我采用实现
SQLData的方法可行吗？即使Javadoc声明不同？ - 你知道哪些其他读取Java中UDT的方法？例如Spring做什么？Hibernate做什么？JPA做什么？你自己又做了什么？
UDT支持和与存储过程的集成是jOOQ的主要特点之一。jOOQ旨在隐藏客户端代码中更复杂的“JDBC事实”，而不隐藏底层数据库架构。如果您有类似上述的问题，jOOQ可能会为您提供答案。
getObject(...)调用上提供还是在连接全局提供都是细节问题。两种方法都有优缺点。在我的情况下，我无法控制连接，因为我正在使用jOOQ库（http://jooq.sourceforge.net）。另一方面，我将ResultSet的具体调用从库的客户端代码中隐藏...（示例在http://tinyurl.com/3aaxdoj中） - Lukas Eder