On 07/06/07, Jonathan Robie <[EMAIL PROTECTED]> wrote:
If what I want is database functionality, and I want to be able to access the database from multiple platforms, I can't use just JDBC, I also need something that is not dependent on the Java language or the Java platform, so I wind up using both JDBC and ODBC, and very likely ADO.Net.
Yes, JDBC is obviously Java-specific.
Of course, not all databases support all of these interfaces, and not all of these interfaces are available on all platforms, and these three APIs are gratuitously different in things that could easily have been done the same way.
My point is that in the Java market every database that I know of supports JDBC. And vendors such as Sybase provide vendor-specific functionality that is not at the SQL layer via extensions to JDBC. I don't see the different APIs for database access as a problem particularly. Yes it might be nice if they were closer but for various reasons they are not. I do think that any vendor in the database space that tried to go against ADO.NET on the .NET platform or JDBC for Java would be extremely foolish.
Of course, in the database world, SQL implementations also differ markedly, but suppose SQL worked the same way across databases and we were designing an API to access relational databases across platforms and languages. Would we want to use one model for everything but Java, then use JDBC for Java? I think it would make much more sense to provide one consistent API across languages, and provide an alternative Java API, which would use the same code base as the native Java API.
If we were setting out with the goal of designing an API to work across languages for accessing relational databases are you not stating that we are designing something to replace JDBC? I don't understand that point in that case. RG
