Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: What so special about PostgreSQL and other RDBMS?

Re: What so special about PostgreSQL and other RDBMS?

From: Volker Hetzer <volker.hetzer_at_ieee.org>
Date: Fri, 7 May 2004 11:35:24 +0200
Message-ID: <c7fl8s$bjo$1@nntp.fujitsu-siemens.com>

"Quirk" <quirk_at_syntac.net> schrieb im Newsbeitrag news:4e20d3f.0405070046.50c2d5dd_at_posting.google.com...
> > > - If you don't have the source code for a product, and the right to
> > > modify and redistribute it in perpetuity, nothing you develop on top
> > > of it can be relied upon, so therefore the open source applications,
> > > or applications for wich you've been granted such rights via an
> > > non-expiring licence, are much *MORE* suitable for high-end commercial
> > > applications, since you are not locked into any external dependencies.
>
> > That's not true.
>
> Yes it is.

What was the value of this reply?

>
> > The main problem is not the right to the source code
> > but the right to get maintenance.
>
> With out the right to modify the source code you can have no "right to
> maintenenence" as all rights are held by one vendor, exactly the sort
> of dependency I recomond avoiding.

I do have the right to maintenance, because that's in the contract. Very simple.

>
> > The right to modify is a red herring.
>
> Not if your application and the permenancy of your data is important.
You didn't read my posting, right? I don't *want* to create my own development team competing with the original one. I don't want to merge my change back into their code with every new release! I don't want to develop code and then have them decide whether they condescend to incorporate it or not! I want the authors of the software to do the coding based on what I'm willing to pay for!

>
> > > - Ideally, your Application's data access will be built around a data
> > > abstraction layer that can use alternative database backends, i.e.
> > > PEAR::DB.
>
> > Which either gives me the freedom to write nonportable code
> > ("create bitmap index", "where A(+)=B") or loses efficiency
> > on all but the dumbest platform.
>
> You can always write bad code, my point being that if you are using a
> commcial SQL server, such as Oracle, you should abstract your data
> access so that you can use something else instead down the road, you
> can do this with your own wrappers through elegent coding,
Elegant coding... The holy grail of software engineering. Why am I spontaneusly reminded of http://www.dilbert.com/comics/dilbert/archive/dilbert-20040417.html ?

> or use a
> class such as PEAR::DB (for PHP), depending on what your application
> requirs. Efficiency is very relative, eficiency of what? Code
> Executution? Application Extension? Interoperability? Tip: The first
> is not always the most important.

For db computing, reducing server load is the important thing. Interoperability typically means primitive, network/db intensive sql.

>
> > > - If your data is really important to you, you will use network, not
> > > application or database level security to protect access to it.
>
> > Wrong.
>
> Famous last word(s).

[empty reply]

>
> > If it's important it must not matter whether one tries to
> > access the data from a local or remote machine.
>
> Interesting that you believe that this can not be accomblished with
> network security.

Yes. Now you figure out why.

>
> > A defense in depth
> > will always include a securely configured database.
>
> Yes, a securely configured database, protected by a secure network,
> the later being far more important!

A network will alway have holes, simply because legitimate users have to get through and legitimacy can change while they are in. Therefore you protect the data where they are. In the db.

> > > - Your primary datastore should be self contained, self describing and
> > > human readable, something like a heirarchy of XML files. This is the
> > > best way to ensure the perminancy and portabilty of your important
> > > data.
>
> > Until the next version can't read the old format (or DTD in the XML case).
>
> What is it about "Self Contained, Self Describing, Human Readable"
> that you do not understand?

The fact that you believe such a thing exists. Unless you mean a printout of the database contents.

>
> > In any case, permanency across more than two major database or other
> > software releases is difficult, regardless of the format.
>
> For unskilled labour, yes.

Right. You show me how do convert VENUS chip designs into Synopsys without going into a museom for the original hardware and getting all the versions in between.

> That is why vendor educated developers who
> can not see passed their favourite commercial product should not be
> asked for advice on this subject.

Get some real world experience.

>
> > > - Anyone who calls Free Software 'Freeware', implies that believing in
> > > it is a 'religion' or thinks that it is low quality as a rule should
> > > be considered unskilled labour, not a source of real advice.
>
> > It's not "low quality" as a rule, at least not as long as one reduces product
> > quality to code quality. The problem is that as soon as the developers feel
> > they are fed up with the product or get a real job they dump the code
> > on you and leave you alone with it.
>
> If you have the source code, you are the developer,
Wrong. I am the user, regardless of whether the vendor wants me to do his development work or not.

> if you contract an
> outside developer or licence an existing product, fine, as long as you
> have perpetual access to the source code and the *right* to modify it,
> or contract someone else to. If you do not, than you can not gaurantee
> the permenance of your application.

When will you get it, I don't *need* the right to modify it as long as I have the right to have it modified by the guys who wrote it in the first plac and are competent at it.

Greetings!
Volker Received on Fri May 07 2004 - 04:35:24 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US