Cservenak Tamas - 2004-11-08

Logged In: YES
user_id=1154447

I think it is unnaplicable in Druid's case.

When you start a database design, you don't know what DB
will you use (or even if you know, Druid allows you in any
moment to change to another SQL script generator). And there
is no "primary" SQL export module, you can switch or
generate with any of them in any moment. So, which keyword
list to use? The merged keyword list of, for example mySQL
and Oracle?

The real check would be to generate SQL with "Rebuild in
JDBC db" so the given database engine reports you all the
things he dislikes.

Ok, at least Druid could warn you for some some subset (ANSI
SQL?) of keywords, but it is useless in my opinion, coz you
won't use ANSI keywords anyway unless you're lost with SQL.

As using doublequotes (where I know it is dangerous): within
Oracle is dangerous, coz then all your application (PL/SQL
packages) have to access it thru doublequoted name,
otherwise Oracle won't find the object. So, it introduces
another "weak point" in your App, and you have to worry
about addressing the given object. Anyway, using an object
(field, table) with name that is keyword in a given DB is
not recommended.

Isnt it easier to generate the database in a test schema and
correct the reported errors? Every table and field can have
names that *are* descriptive and does not clashes any
keyword of the host database.

This would be out of the spirit of the Druid. Druid is not
commited to any DB engine (it is not an Oracle Designer
neither FireBirdExpert and don't want to be), it is a
general tool addressing as much DB engines as much JDBC 2.0
compliant driver exists.

Cheers,
Tamas