Re: Xquery might have some things right

"Mikito Harakiri" <mikharakiri_nospaum_at_yahoo.com> wrote in message news:8a529bb.0403070042.27b2c73c_at_posting.google.com...
> "Corey Brown" <corey_at_spectrumsoftware.net> wrote in message news:<uMs2c.32148$rB4.8981_at_bignews6.bellsouth.net>...
> > "Mikito Harakiri" <mikharakiri_nospaum_at_yahoo.com> wrote in message news:8a529bb.0403061202.eaf1bca_at_posting.google.com...
> > > 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 *?
>
> FYI "select *" is full projection. If you are afraid of full
> selection, that is not the most resource intensive query, either.
> Hint: joins.
>
> Now, there is a way to limit resource usage in DBMS per each session.
> You can specify that a particular session can't exceed some amount of
> CPU resources, or logical reads. Irresponsible client will simply be
> kicked off the system.
>
> > >
> > > > 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.
>
> No, proceduaral/XML inteface layer is not higher abstraction than
> relational one.
>
> > >
> > > > 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?
>
> No more or less version # than in your approach.
>
> > > > 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.
>
> That sounds so familiar: you scared of direct database acceess to the
> system, and for some reason feel secure when you have goofy
> application "abstraction" layers on top of DBMS?
>
> > > > 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.
>
> That entirely depend what role I approach them. As a private person,
> no. However, if I'm an application developer willing to work with the
> services that bank provides I'll tell them straight away: "Please give
> me direct database connecton; don't give me your s**tty RPC/CORBA/SOAP
> services".
>
> > 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.
>
> Once again, application, let alone network, is low abstraction level.
>
> > 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.
>
> Right, you want to reinvent security on application level.
>
> > 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.
>
> You have to define "trusted client". This is by no means less work
> than with database security.
>
> > 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.
>
> I've seen enough s**ty integration solutions -- AQ, MQ,
> publish-subscribe, hub and spoke, etc. They all barelly work. After
> several months of piling procedural abstractions layers upon each
> other consultants are happy when they are able to send pathetic 3
> fields of customer info from one system to another. Among neumerous
> bugs plaguing their 'solution" nobody really have the time to verify
> transactional integrity and other subtle details. So, please don't
> tell me that you have real word experience, and, therefore, know
> better.

    OK, I won't.

    Good luck with your solution. (you'll need it!)     --Corey Received on Sun Mar 07 2004 - 14:31:10 CET