Re: Xquery might have some things right

"Mikito Harakiri" <mikharakiri_nospaum_at_yahoo.com> wrote in message news:8a529bb.0403061202.eaf1bca_at_posting.google.com...
> "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?

    I don't have to prove that. I think it's fairly obvious. Discrete messages are     always going to be smaller than anything that you're proposing here. How     can you control what you clients will query? What if they issue a select *?

>
> > 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.

    Wrong again. That's the whole point of having an abstraction layer or a     facade, if you want to talk in terms of patterns. If there's an abstraction layer in     place, the receiving client never has to worry about what happens under the     covers. In your solution, the client still has to be intimately familiar with the     database layout or particular view that they need to query.

>
> > 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.

    Wrong again. Are you suggesting that the owners of the server should     cater to every client by providing some sort of backward compatibility view?     How many versions will they need to support?

>
> > 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?

    Ok, just for grins, why don't you call your bank and ask them if you can     use your personal computer to query their customer database directly. I'm sure     they'll be happy to have their database administrator work with you on a security     solution that will allow you to query just your personal information. Do you     see where I am going with this? Security should not implemented at the database     level. It is implemented at the application and network levels. I'm sure some     amount of security can be leveraged at the database level. But it will never     be enough to support a real-world interface specification.

    With a publish and subscribe implementation (regardless of whether it's XML or not)     My security concerns are far fewer than in your solution. All I need to know is that     a trusted client has subscribed for information that my server is publishing on one or     more topics. End of story. The client can be validated in any number of different     ways.

    So, to wrap things up once and for all, let me just ask you if you have ever implemented     your "you query my db and i'll query yours" solution in a real world application? My guess     is no, because if you had, all of the real issues that I have posted in these last few     messages would make sense to you.

    Cheers,
    --Corey Received on Sun Mar 07 2004 - 00:04:42 CET