Re: What so special about PostgreSQL and other RDBMS?

"Quirk" <quirk_at_syntac.net> wrote in message news:4e20d3f.0405250037.4d99dd34_at_posting.google.com...
> "Niall Litchfield" <niall.litchfield_at_dial.pipex.com> wrote in message
news:<40b25fc8$0$20518$cc9e4d1f_at_news-text.dial.pipex.com>...
>
> > "Quirk" <quirk_at_syntac.net> wrote in message
> > news:4e20d3f.0405220405.57e0a8bf_at_posting.google.com...
>
> > > Thanks Nick, your alternative propositions are much clearer than the
> > > FUD of the other posters. Although, your attitude seems no less
> > > belligerent, so my hopes for a fruitfull discusion are not high.
> >
> > Last time I looked my name was Niall,
>
> Sorry Niall.
>
> > I'm afraid you are probably correct about the liklihood of a fruitful
> > discussion since you seem to have managed to get heated with every
single
> > one of the posters that I am aware of who regularly post well thought
out
> > informative posts.
>
> I guess the new free software movement is such a big threat to the
> status quo that it makes them nervous and belligerent to even discuss
> it, like many protectionists, they are worried their island is about
> to be stormed by barbarians. Well, I guess they are right. The
> consumer, however, will benifit. And those amongst you with real
> skills will also get on just fine.
>
> > > I'm not saying that this is always the case, or is your case, but it
> > > is the real world you asked about, and that's it.
> >
> > If true, and there is some truth to this, I don't see what failing to
get
> > the legalities right has to do with having access to the source. This is
> > about license management and control of procurement.
>
> Because with closed source software, 'failng to get the legalities
> right' is a financial mater, in many cases companies *chose* not to
> get them right, they know perfectly well they are overdeployed.
> Sometimes the choice is made by the principals, sometimes the choice
> is made further downstream; in the IT department who can't be bothered
> going through the procurement cycle again and again and justifing
> needing any more licences to the bean counters. They simply install
> the software on an another server, or for another user. In larger
> organisations the company tends to drift into overdeployment, in
> smaller ones, overdeployment or outright piracy is frequently the
> starting point.
>
> Free software can not be overdeployed, which is one reason why linux
> and bsd boxes are popping up in datacentres around the world, they
> started with Webservers, LAN Servers and Firewalls (esp for NAT), then
> Mail, now the Database, later the Desktop.
>
> > > So, when the question of Free versus Propietary Databases is asked, I
> > > think it is important to help people understand the advantages of
> > > having source, or using free software, of avoiding dependencies, *as
> > > well* as comparing features.
> >
> > No software project, even if you have access to all the source is 'free'
of
> > dependencies,
>
> Sorry, I meant free of exclusive external dependencies: fixed
> dependencies on outside organisations, not just software dependencies.
>
> > > As I said in my article in the NonProfitTimes, wether or not a
> > > particular peice of free software is better that a particular peice of
> > > nonfree software, free is better than stolen.
> >
> > Ah a straw man argument. Seen them before.
>
> No, perhaps a nonsequetor, but not a straw man, a 'straw man'
> is refuting a weaker argument instead of the argument you have been
> given, the passage you quote is an extension of my own argument 'free
> is better than stolen', it is not a weakening of yours. You may
> consider my extenstion irrelevant (I do not) but it is not a straw
> man.
>
> > > Issolating your data access code does not mean you can not take
> > > advantage of the platform, it means that all your data access code is
> > > in one place, meaning that you can more easily change your
> > > application, for instance to migrate it, or for instance to *make
> > > better use of the platform you are running*
> >
> > It almost always does mean you can't take advantage of the platform.
> >
> > I have 2 databases, both run on clustered hardware, db 1 can resume a
select
> > statement that was issued on a failed node on a second node of the
cluster,
> > db 2 can't. How, precisely, do you 'abstract' this difference in
capability
> > whilst preserving the ability of db 1 to handle failed nodes more
gracefully
> > than db 2. How, precisely, do you abstract differences in datatype
between
> > two db platforms without performing excessive casting..
>
> The passage you quote talks about issolating your code to one place:
> abstracting access from your application, which is a good coding
> practice for reasons I explain, as quoted above, I am not recomending
> you try and abstract //the difference between two databases// just
> that you issolate the code: abstract the data access for the rest of
> your application.
>
> When and if you need to migrate your application to another DB,
> presumably you have chosen db 2 based on your requirements and have
> already decided on a solution to whatever problem you are facing,
> having your code issolated means fewer code changes. Again, this holds
> true for migration, it also holds true for simply making better use
> (i.e. new features) of the platform you are currently using.
>

Instead of abstracting there are much better ways. Abstrating somethings are good. Put the business rules and referential integrity in the DB not in some middle tier or front end. (even access the db via stored procs) Then you can swap out the front end , middle tiers much easier and be assured that you do not have to rewrite and validate the business rules all over again. (not tied to one technology). It is much more likely you are going to swap out some middle tier or front end or have multiple programs accessing the db. If you give access to the db only through stored procs and put the business logic close to the database (in it) then it is just an API for storing, retrieving your data. It is a way to encapsulate that functionality. If you write a C++ or Java or other OOPL functionality the concept (among others) is to encapsulate the functionality in that class. The class does all the checking and data validation etc. Think of the db in the same way with respect to data and its relationship to itself. (RI, business rules) You can still have edit checks in a GUI, but the ultimate RI and business rules should reside in the database. But if one is only a programmer this is a difficult concept to agree with and understand.

> > Not at all. You claimed that if I have access to the source, as I do
with
> > Linux 1.5, then I can always find a way forward without external
> > dependencies.
>
> With out _exclusive_ dependencies on third parties, sorry for the
> confusion: without paying for a new licence.
>
> > The only route to what you claim as an advantage would seem to
> > be rewriting the code in-house, or being dependent on external agencies
with
> > whom I don't have a legal relationship (you don't seem to like legal
> > relationships much).
>
> You see, *this* is an example of a straw man argument: that I don't
> like legal relationships, what I don't like is _bad_ legal
> relationships that lock me and my application in to a sole source
> situation and other specific restrictions, like limiting the
> deployment of my own application to the licenced limits of the
> dependency. I have no problem with good legal relationships, like
> support contracts, employment contracts, service contracts. All yummy,
> with a decent termination clause of course, and my perpetual right to
> the source when possible.
>
> > Oh and by the way I am perfectly free under my licence to install new
> > versions of the Oracle software for no change in cost and with the same
> > support.
>
> As long as you agree to pay whatever Oracle charges for support, a
> price fixed not by competition, as it would be if you had source and
> could contract who ever you liked, but by David Ricardo's concept of
> Economic Rent, meaning that in the long run the price will rise to
> what it would cost you to migrate away from Oracle. Interestingly, in
> this way users of closed source software do marginaly benefit from
> free software, since it lowers this theoretical rent. However, it is
> clear that Oracle can benefit from ignorance of free options for quite
> a while yet.
>

BS. If you are so niave to believe that Oracle doesn't think it has competition they you are from another galaxy. I assure you that they know there are other companies out there and they price accordingly. This includes support. I've been at many companies where there was competition between Oracle and others and they were fully aware and concerned that they would get the business. They priced accordingly. Jim

> Also, your licence likely limits the number of users and severs you
> are allowed to deploy, so therefor Oracle's licence has a cost push
> effect on your own application as well, potentially killing your own
> competitiveness, or forcing you into overdeployment.
>
> Regards,
> Dmytri.
Received on Tue May 25 2004 - 07:18:46 CDT