Re: What so special about PostgreSQL and other RDBMS?

"Quirk" <[e-mail]> schrieb im Newsbeitrag news:[e-mail]...
> "Volker Hetzer" <[e-mail]> wrote in message news:<c7t3p2$b15$[e-mail]>...
>
> > > What cold comfort that is. I would prefer the right to make my
> > > aplication work without their good graces.
> > >
> > > Before you consider suing them I suggest you reiview your contact with
> > > an actual lawyer. So you can understand exactly how painted into a
> > > corner you really are.
>
> > Look, we've got about 50 people here dealing with
> > exactly those questions, telling us what contracts to enter and what not.
> > When we buy support, we *know* what we are in for and when and
> > what to sue them for and how to deal with them before we sue them.
>
> Your argument, as usual, is that I should just believe you, not
> because you have explained yourself, but just because you *know*.
Wrong. My argument is that I've taken your "suggestion" long ago.

> My orignal comments still hold true, the right to sue is cold comfort,
> the right to pick up your pieces and try somewhere else, keeping your
> application in tact as much as possible, is better.
It simply doesn't work. Try it sometime.

>
> > > > at least, the right to cancel the
> > > > contract which hurts them way more
> > >
> > > How can you cancel the contract when your entire application is
> > > dependanton there product? Can you afford to throw away your
> > > application too?
>
> > See my other posting. Compared to changing the application (replacing
> > it with another), changing the underlying database is easy.
>
> Even easier if you have abstracted your data access with a simple
> function, and then used that function throught your application. I
> have no idea why you find this so hard to believe.
As I said before, "a simple function" doesn't do it because
there are lots of other things specific to a database so that
the porting to another database won't be significantly eased.
And, I'm trying to convey this too, there's no need to ease it
much more because it's not much trouble anyway.

>
> And for what purposes are you bringing up changing the application?
> How is this comparison relevent? I am trying to explain how to protect
> your investment in your application; to change it as little as
> possible.
I'm trying to tell you that whatever API I'm using, the application
is protected enough against any change.

>
> You make so little sence I wonder what is motivating you to carry on.
Whatever.

>
> Abstraction of your database access is a good idea. Why are you so
> hell bent to dispute this.
It depends on how much performance it costs.


> They [support contracts] make even more sence if you are not locked in to a single source.
>
> > I was talking about the case where I go to the developer and ask him
> > to do something for free.
>
> Why would anybody do work fo you for free? Are you a charity of some
> sort?
You started out by saying that maintenance contracts are evil things
devised by the big companies to suck their customers dry. Now suddenly
it's obvious that I pay for changes/fixes and that this is a cost factor when
deciding about an investment.

> > > > See my other postings and the reply about division of labour. You might
> > > > also read up on Maos Great Leap Forward and north coreas policy of doing
> > > > everything themselves.
> > >
> > > You're not seriously trying to draw me into to a discusion on
> > > communist history are you? If so, please go ahead, it may be
> > > intersting. I've been reading the Fabian writing of George Bernard
> > > Shaw recently myself.
>
> > Right. Mao wanted every village to be self-reliant and do everything on
> > their own. I think the best published example was that more or less
> > every village had its own steel factory, resulting in a very low efficiency
> > and crap steel. If you read about north corea you will sooner or later
> > stumble on something similar, called "Juche". A fierce desire to be
> > independent, an inability to recognize you can't be a specialist of
> > everything and, consequently, a desaster.
>
> And the relevance of this is....?
That it doesn't make sense to turn me or our company into database specialists.
That therefore access to the source code doesn't make sense to us.
Even if we hired some other company, the only thing we need is having *them*
accessing the source code. If you've done any work under NDA's you'll know
what a difference this is.

> > > > > I'm not sure what this example is supposed to illustrate. The vendor
> > > > > failed to fix the bug originaly and ony did so under dures,
> >
> > > > The point was that contracts work.
> > >
> > > It was quite a poorly demonstrated point, as they nearly did and could
> > > well have lost their own customer under the arrangement.
>
> > Not "nearly", the legal opinion was correct and therefore the only ones
> > to worry were the sued ones.
>
> If it did come to a dispute, they could not have supported there own
> application, they where exclusively dependendant on an outside firm.
You are talking ifs here. The contract was as it was and they were right.

>
> > > > > which only
> > > > > shows how vulnerable you where to begin with,
>
> > > > Why was he vulnerable if he had a contract that required the vendor to > > > > work?
>
> Because he had no right to go elsewhere if the vendor failed to
> deliver.
And in what way is that different if mysql AB goes bust and fails to deliver?

>
> > > As the old joke goes: "if this fire alarm fails, and your house burns
> > > down, we will refund the entire purchase price (not including the
> > > battaries)."
>
> > OTOH, "if you install this fire alarm, you will pay less insurance on
> > the house".
>
> Relevence? What insurance is provided in the case here?
> Fire insurance you can buy, I have never heard of application
> obsoletion insurance.
Maintenance is insurance to the database vendor. For a fixed price (or whatever)
the vendor agrees to do maitenance work. The database vendor obviously
balances maintenance costs and development costs, trying to minimize both.

>
> The original point being, you can not recoup your own investment, just
> the purchace price.
Yes. The same is with open source software. At least if you place a reasonable
limit on the costs to maintain the open source software yourself. (Reasonable
meaning it should cost less than a migration to another supported product.)

>
> > > > > if you had the right to
> > > > > say 'OK, were going to fire you and give someone else the contract'
> > > > > they would have fixed your bug pronto with no back talk.
>
> > No, they wouldn't, because first they would have to understand the code.
>
> If they where a credible provider of support and development for this
> particular product, they would certainly understand the code.
Well, looks like the only credible supporter of mysql is mysql ab.

>
> > > > Maybe, but in case of open source software they'd say 'Good luck
> > > > working into our source code, see you in two years'.
> > >
> > > Were do you get this idea? You can contract many companies, large and
> > > small, to support your open source product, the difference being that
> > > you can hire another when when they fail, because you have a right to
> > > the source code, where as you have no recource when the provider has
> > > all the rights.
>
> > Like, suse and redhat, each doing their own distributions?
>
> Huh? No, like a competent development comany providing devlopment
> services, exactly like Oracle does, but without trapping you into a
> sole source situation.
And right now it works because they all more or less follow redhat.
Nevertheless, each commercial software gets certified for single platforms,
therefore you are still tied to a single distribution, or the supported
subset.

>
> > Could you provide a link where IBM actually provides support
> > for mysql? The only thing I have found is them bragging that  MySQL AB
> > (fully) supports the AIX port, not that IBM supports MySQL.
>
> Your question is yet another fallacy, since you are responding to a
> general statement,
So, who is the competitor for mysql ab?

> IBM Application development and systems integration
> http://www-1.ibm.com/services/us/index.wss/it/bcs/a1000402
Yes. Doesn't mention support or databases anywhere.
I had a look at the arcadia case:
"Key Components
Software IBM LotusDomino(tm)
IBM Lotus Notesョ
IBM DB2ョ Universal Database(tm) for iSeries(tm)
IBM Net.Dataョ
Servers IBM iSeries
Services IBM Global Services"

>
> > > Yes, developing applications costs money, it is this investment I am
> > > advising people to protect by not getting locked into third party
> > > dependencies.
>
> > I do get locked into a third party dependency, even if I can change
> > the third party.
>
> If you can change it, you are not 'locked in.'
So, if I can change the db from oracle to db2 I'm not locked in either.

>
> > I agree, on the plus side, I can change support without
> > changing code, so who actually owns the code and merges the
> > fixes from the other guy, provided they don't want to keep them themselves
> > because they want to keep the customers?
>
> All these question depend on the case, and have nothing to do with the
> topic, if you have a right to the source you are safer that if you do
> not, if you have abstracted your access you are safer still. What is
> it you can not understand?
That I am supposed to be safer with a bunch of code that, in the case
I need it, is obsolete or takes time and expertise to get into.

>
> This conversation is becoming surreal.
>
> > > > > or negotiate access to source for the vendors
> > > > > product, the only difference being that you then have leverage.
> >
> > > > The access to the source means nothing, see above.
> > >
> > > It means everthing.
>
> > Why? I can't change it.
>
> You have the *right* to use it and have it changed for ever and ever,
> not only by the permission of some outside company.
So what? The right to use it doesn't make me a programmer for that particular
database. It doesn't make anyone else (short of the original maintainers)
a programmer for that particular database on short notice. It doesn't make
the maintenance cheaper than the migration to a still supported database.
And it definitely doesn't make my boss keep a bunch of abandoned code
that we are the sole users of.

>
> > > It means the difference being being the master of
> > > your applications and contracts or being a slave to a third party
> > > vendor.
>
> > He's my slave because I pay him.
>
> No, he can simply ignore you if he decides the relationship is no
> longer profitable for him. You can do nothing.
I can stop paying maintenance and go somewhere else.

>
> > > Maybe not 'out of the hat' but with less expense and retraining that
> > > having to reprogram the entire application which was programmed with
> > > proprietary bindings everwhere instead of properly abstracted code.
>
> > Abstraction can make the job easier, you are right here, but then
> > changing a database is not that hard too, as long as both are relational
> > ones.
>
> That's all I'm saying, Abstraction is a good idea. I was giving some
> simple, good advice. What are you saying?
That "elegance" is more than "abstraction" and means different things
to different people. And abstraction doesn't always make sense either
because from a technical point of view one decides for a specific
product because of the specific properties of the product. If you
abstract away from them you won't need it either.

>
> > > > Including people who have been trained on it.
> > > > In what way is a change from oracle to db2 easier than a change from
> > > > postgresql to mysql?
> > >
> > > Well, for one, you would never have to change away from the open
> > > source products because of a dispute with the developer.
>
> > Yes, I would. Because I'm not going to maintain my own database
> > distribution.
>
> Nobody asked you to.
But you always tell me how good it's supposed to be. Well, it is not.

> You have the right to use the product and never
> talk to the developer if you like. You don't need to change it to
> enjoy the rights
> that source code gives, that is the right to use the
> product for ever, and even have it changed *if you need to*
Oh, I've got the right to use oracle forever too. It's only what I
want updates that I have to talk to them.

>
> My advice is to abstract when you have no source code, and perhaps
> even then, I have repeated this many times and am not sure what you
> are even disputing.
Your advice. Abstraction means you won't need/use a distinguishing feature.
This might cost you performance, it costs money to implement, if only that
feature makes your app possible you simply can't abstract from it and if the
interface is standardized anyways you don't need to bother either.
Therefore abstraction is to be decided on a case-to-case base just like
any other thing.

>
> > > But in
> > > anycase, my argument is not, and never was, oracle and db2 versus
> > > postgresql or mysql. But rather for abstraction when you do not have
> > > source code, or sometimes then too.
>
> > If I have abstraction it's even less necessary to mess around with
> > the db because it's easier to change the db.
>
> Yes, that's why I am *recomending* abstraction. Are you just typing
> compulsively at this point?
No, I'm showing you the contradiction of your arguments.
If it's easy to change, the case for code rights disappears. Which way do
you want it?

>
> > > I certainly would
> > > not expect my clients or users to be satisfied when I told them, I'm
> > > sorry the application I provided for you doesn't work, but you will
> > > have to discuss this with Larry Ellison. Nor would I be satisfied
> > > giving such an excuse.
>
> > It's different for databases.
> > A) the customer quite often already has a database and expertise
> >      maintaining it. He has an interest not to have another.
>
> Abstaction means your application can run for different clients with
> different databases then. double plus good.
But, and that's the point here, if every vendor provided its own patched
mysql database the customer would be even more pissed off.
Believe me, it's easier to say "we require oracle" that "we require you
to run my oen hacked version of MyFavouriteOpenSourceDatabase.
Are you trying to change thread from opensource to abstraction?

>
> However if your application is tied to one database, then the very
> client you are describing is the very client that you will not get if
> they use a different database from yours.
We do have such an app here. The result is that it doesn't run well
on *any* database.

>
> > B) the customer may  trust Larry ellison, or IBM more than me.
>
> But if they only sent there money to Lary because they purchaced your,
> unabstracted application, they would be pissed off when it did not
> work, and you blamed it on Larry.
Ah, but I only blame it on larry if it's larrys fault.

>
> > C) the customer may want a database that can do more than I could
> >      implement or maintain, like incremental backups, logical/physical
> >     standby databases or security.
>
> Exactly, so how are you going to accomplish this with your
> unabstracted application? Do you even remember what side of this
> debate you are on?
I use a database that can do that and tell them to get the discount
version if they don't need it. How do you going to accomplish
that with an open source app where you are the only surviving
supporter? Just to get back to the open source topic here.

>
> > Another case where it's different would, for instance be the OS.
> > How much linux maintenance do you think you can provide,
> > compared to redhat or suse? Is this really your corebusiness
> > or area of expertise?
>
> Why do I have to?
Why would you have to provide support for a database then?
Remember you disputed that it's a good idea to let larry provide
the oracle support.

> Since I can hire one of a million support providers
> for any OS,
> however for OSes without source, they can't do much when
> the problem is with the OS itself. Same with the database.
So, how many have you under contract and how do your customers
react to the news that they have to run your own linux distribution?


>
> Again, my argument summerized for the millionth time: If you have no
> source Abstract access for sure, and it's also a good idea to abstract
> access even if you do. I'm baffled how you've turned this into such a
> long conversation.
In case you've already forgotten, the topic was open source, not abstraction.
In your case abstraction wouldn't have made sense because you won't ever
need to change the database because you'd just carry on supporting it or
buy the best (probably original) developers and go on, right?
But the abstraction thingie was a nice diversion.

Greetings!
Volker