h a l f b a k e r y
I heartily endorse this product and/or service.
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
or get an account
The major database servers all listen on different ports:
MySQL on 3306, Oracle on 1521, PostgreSQL on 5432, SQL
Server on 1433, DB2 7.x on 50000, DB2 8.x on 60000, etc.
Proposed is a database daemon that listens on all of these
ports, emulating whatever features are available to allow
in client driver selection. Some features are not 1:1,
such as separating users from databases in Oracle or creating
materialized views in MySQL, but for schemas and
applications written to be portable, I don't see how
implementing only the ODBC-compatible features would be
||So like ODBC/JDBC, only server-side? I've come across
hosts who's only job it was to act as a single
"datamart" for single-stop-shop retrieval by downstream
systems that kind of did something like this - but the
way it did it was to act as a multi-driver repository
that used Oracle JDBC to connect to oracle, and MySQL
JDBC to connect to MySQL etc and then exposed the
results via its own proprietary XDBC drivers/API.
||"So like ODBC/JDBC, only server-side?"
||So, given that the client is required to use only "standard" syntax (presumably already supported by the underlying DBMS), does this proposed daemon do anything apart from juggle ports? Not that it has to, necessarily - I'm just checking in case I've missed something.
||This seems like a solution looking for a problem. Why
would you ever need to do this?
||A better way of doing things is to simply abstract away
the database interface entirely. I've built a few apps
with Ruby on Rails using SQLite, MySQL, and
PostgreSQL, and I've had to change exactly zero lines
of application code to switch between them. You just
pick your database type in the config file, and it all
||I'm with [ytk] on that one.