Subject | Re: [Firebird-Architect] Re: Standard Conformance |
---|---|
Author | Jim Starkey |
Post date | 2003-06-19T11:39:17Z |
peter_jacobi.rm wrote:
cares to work on it is another matter all together.
One of the many reasons I hate the database market is that prospects tend
to get hung up on standard compliant even when compliance doesn't bring
interoperability. I've always thought that functionality, performance, and
stability were better reasons to pick one database from among a set of
mutually incompatible, non-interoperable systems, particulary since, in the
end, they'll probably pick the one with the biggest ad budget.
When designing a database, as I mention, I consider standard compliance
as good practice, but not all that important. No arbitrary differences, of
course, but if there are important semantic reasons, to hell with the
standard.
A couple cases in point. The SQL security model stinks. Always has.
Interbase
implemented named security classes backed by access control lists. Vastly
more powerful and easy to administrate, and could encompass all of SQL
semantics. Borland dumbed down the model to SQL semantics. I wouldn't
have done that. In Netfrastructure I use a flexible role model, where an
account has a set roles, some active and some latent, under control of the
application. Again, incompatible with the standard, but very powerful and
appropriate, even necessary, for the target domain. Another example is
triggers. Interbase had the first commercial implementation of triggers way
back in 1985. We did them right (well, almost. V2 has multiple triggers
per table). The SQL standard triggers are idiotic and next to useless.
Why would somebody want to through out a perfectly useful major
feature in favor of a brain-dead system that offer no possible
interoperability?
So ask away, but unless you willing to do it yourself, don't expect much
response.
>Very reasonable. But If I ask for feature that enable me toYou can ask for anything you wish with any motive. Whether or not anyone
>use standard DDL with Firebird (e.g. nameable constraints
>for domains), would this be considered a valid motive?
>
>
cares to work on it is another matter all together.
One of the many reasons I hate the database market is that prospects tend
to get hung up on standard compliant even when compliance doesn't bring
interoperability. I've always thought that functionality, performance, and
stability were better reasons to pick one database from among a set of
mutually incompatible, non-interoperable systems, particulary since, in the
end, they'll probably pick the one with the biggest ad budget.
When designing a database, as I mention, I consider standard compliance
as good practice, but not all that important. No arbitrary differences, of
course, but if there are important semantic reasons, to hell with the
standard.
A couple cases in point. The SQL security model stinks. Always has.
Interbase
implemented named security classes backed by access control lists. Vastly
more powerful and easy to administrate, and could encompass all of SQL
semantics. Borland dumbed down the model to SQL semantics. I wouldn't
have done that. In Netfrastructure I use a flexible role model, where an
account has a set roles, some active and some latent, under control of the
application. Again, incompatible with the standard, but very powerful and
appropriate, even necessary, for the target domain. Another example is
triggers. Interbase had the first commercial implementation of triggers way
back in 1985. We did them right (well, almost. V2 has multiple triggers
per table). The SQL standard triggers are idiotic and next to useless.
Why would somebody want to through out a perfectly useful major
feature in favor of a brain-dead system that offer no possible
interoperability?
So ask away, but unless you willing to do it yourself, don't expect much
response.