Re: Oracle is a bigger version of MS Access?

I am certain you miss the point. The only way to get to the data that is in an RDBMS is to use the RDBMS to get/set the data. You can use a variety of languages and techniques to access the data that reside in the RDBMS but the language that is outside the database is not the access point. You can attempt to control that access point by saying "To access the data in the X database you should go through this API I have written." But in a company of any reasonable size (eg over 10 developers or people who have customers that want to access data) that quickly falls down. (been there done that as Noons pointed out) And the vi argument is specis; you really aren't going to get the information that way, and are surely going to shoot yourself in the head. Since there is one way to get the data (and a variety of languages and programs) to access the data it makes sense to put the rules at the point of access.

Gosh, if one does something in Java they usually create some sort of manager or access program to make it easier to control that resource. (or class if you will) Then if they need to change the implementation they can do so without rewriting other classes. (most of the time) So putting an extra layer on top of the database to "handle data integrity rules" meets my sarcastic reply of "Yes, any programming problem can be solved by adding another layer of indirection."

Yes, one can set up all sorts of artificial arguments, but they just don't hold water. Maybe I'm a genius, but learning a new language just isn't a big deal. I've been at this for a couple of decades and learned probably +50 languages/macro/scripting in the interim. (to varying degrees of competency; APL can be pretty slick, but it can also be rather difficult to remember what the heck you did the next day if you didn't document the heck out of it.) Writing lots of code in a particular language quickly does take practice, but it isn't hard. Not only that but by putting the business / data integrity rules in the back end you actually make it easier to demarcate the tasks. The GUI folk can concentrate on that end of things and not have to be experts in backend stuff. (They usually don't want to anyway, so make them happy and let them screw around with the UI.)

While I prefer Oracle my arguments are not db specific. I've seen too many people, especially just out of school, cling to a language as if it were a hammer and everything was a nail.
Jim

<ctcgag_at_hotmail.com> wrote in message
news:20031004160839.098$5C_at_newsreader.com...
> "Jim Kennedy" <kennedy-downwithspammersfamily_at_attbi.net> wrote:
>
> > I think you miss the point.
>
> Perhaps.
>
> > The database is the point at which one or
> > more outside things get data from and send data to. Thus while it is
> > possible that someone can (and it does happen) implement data integrity
> > rules incorrectly in the database, (because they misunderstood the
> > requirements) at least the rules will be applied uniformly. If you try
> > to put them in every program that accesses the database (instead of in
> > the database) then you immediately increase the potential that the rules
> > will be misinterpreted.
>
> And if you compare pristine apples to rotten oranges, the oranges don't
> look too good. Whether the procedures are in one place or many, and which
> language the procedures are written in, are two different issues. I don't
> see that it is the case that if they are in Java, they will be in many
> places, and if they are in Oracle, they will only be in one place.
>
> > Also you are creating MORE work for yourself.
>
> That depends on what language you already know. Learning new
> languages is not easy.
>
> > You are coding those rules in all those different applications that may
> > not be written in the same language and certainly not by the same
person.
>
> Clearly if you code the rules in a language, you would have to route your
> other languages through that one to use the rules. This seems to be no
> different than saying that, if you use Oracle, you can't just open the
> datafiles with vi and muck around with them. Of course you shouldn't do
> that.
>
> > Anytime you increase the complexity beyond what gets the job done you
> > increase the probability of doing it wrong, increase the maint. cost,
> > etc.
>
> That's an argument keeping the data access code in one place, but not
> really for which place that should be. I prefer that that place be the
> database, not Java. But I see that as more of a preference than a holy
> war.
>
> Xho
>
> --
> -------------------- http://NewsReader.Com/ --------------------
> Usenet Newsgroup Service New Rate! $9.95/Month 50GB
Received on Sat Oct 04 2003 - 15:39:23 CDT