Re: Xquery might have some things right

"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. Received on Sun Mar 07 2004 - 09:42:05 CET