Re: Xquery might have some things right

"Corey Brown" <corey_at_spectrumsoftware.net> wrote in message news:<V5m2c.66912$Tn.41083_at_bignews5.bellsouth.net>...
> Sorry, you're wrong again. I described a publish and subscribe mechanism
> that broadcasts information only to those clients that have "subscribed" to
> that particular publication. In your solution, every client interested in a particular
> piece of information would have to query the server, essentially at the same
> time, to retrieve it. Unless you can think of some way of throttling your clients,
> I don't see how your solution would ever scale.

You didn't prove that in my approach there is greater volume of information floating across network than in yours. How can you conclude that my solution won't scale, then?  

> Allowing clients to directly query the server via SQL makes your design
> too fragile for real world application. Server side schema or application
> changes will immediately break every client in your system. Your solution
> requires that clients have intimate knowledge of the servers table structures
> in order to properly formulate a "query" that would allow the client to pull
> the information that they're interested in.

No more than changing message format wil break everything in yours. Next, there is a concept of view. If you change your schema in incompatible way (note that it's not quite easy to do that; just adding the table column wont break anything) then you provide backward compatible views.  

> Interfaces between systems must form an abstraction layer between the
> server and the client in order to insulate one from the other and to allow
> for application flexibility.

Views and query language work perfectly as an interface layer. The abstraction layer of relational language (unlike many on this group I include SQL there) is much higher than any alternative that you have in mind.

> Not to mention, I don't know of too many application
> owners that are going to allow untrusted clients to have direct database access
> to their systems.
> Even if the access is in a read-only mode, there may be information
> stored on the server that is considered sensitive and cannot be shared with other systems.
> For instance let's say your bank account numbers or social security number was stored along
> with your stock information. Would you want external clients to be able to randomly
> query for such information?

Excuse me, but what about Database security? Unlike XML world database security matured for the period of what, 20 years already? If your DBA/Database designers aren't able to leverage database security mechanisms, maybe it's time to employ other ones? Received on Sat Mar 06 2004 - 21:02:15 CET