Re: What so special about PostgreSQL and other RDBMS?

"Quirk" <quirk_at_syntac.net> schrieb im Newsbeitrag news:4e20d3f.0405190205.416ed0ce_at_posting.google.com...
> [comp.databases.ms-sqlserver removed]
>
> Wow, five days later Volker is still scratching his head about this, I
> though this thread was dead long ago.

I've got some long test runs with not much to do in between, that's why I spend a bit of time here.

>
> > > 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.
>
> Huh? If you have taken my suggestion, then why did respond to my
> suggestions?

You implied that I didn't run the contract by our law department.

> Did you imagine, that although I was not responding to
> you, somehow It was you I was talking about? As usual, you make no
> sence.

You did talk to me. Read up your article 4e20d3f.0405110143.3fba4756_at_posting.google.com.

>
> > > 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.
>
> 'Simply doesn't work' -- an unsubstantantiated out of hand dismissal,
> which is, as anybody with clue knows, a fallacy.
Substantiation: When cygnus supported gcc, who else did?

>
> 'Try it sometime' -- Another attempt to portray yourself as having
> greater experience, another fallacy.

So, what's your experience?

>
> Well, what more can we expect from Volker, the human fallacy?
:-)

> The specific proprietary bindings can be wrapped in a simple function.
> Additional functions can be used to issolate proprietry features.
So, how do I isolate functional or bitmap indexes? How do I isolate the queuing mechanisms of oracle?

> > > 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.
>
> The question was: Why are you bringing up changing the application as
> if it was an argument _against_ my suggestions, since my suggestions
> help protect your applications. Please try to follow.
"> > See my other posting. Compared to changing the application (replacing" "> > it with another), changing the underlying database is easy." If you are that forgetful maybe you shouldn't cut out that much.

> > It depends on how much performance it costs.
>
> Funny, that's what I said.

Where?

> > > 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.
>
> No, closed source licence agreements are so devised.
If I buy oracle (or purify) or whatever, I buy a fixed price for the product *once* and the maintenance annually. There is no sucking dry part.

> Maintenence contracts are perfectly fine.
Ok.

>
> > Now suddenly
> > it's obvious that I pay for changes/fixes and that this is a cost factor when
> > deciding about an investment.
>
> You pay for labour, yes, why would this not be obvious?
I'm trying to make it obvious to you that I can pay for the labour perfectly fine without having the right to the source code. It's what those perfectly fine maintenance contracts are for.

>
> > That it doesn't make sense to turn me or our company into database
> > specialists.
>
> I don't know what makes sence for your company, but it should be
> obvious to you that my advice is not directed at your company
> specificaly, and also, my advice is not to become database
> specialists, but rather to not make your own application, especially
> if it is a 'high end commercial application' as described in the post
> I was responding to, exclusively dependend on a third party.
Ok, somehow you seem to think 4 (ok, at most 5) weeks migration effort is an exclusive dependency justifying staying away from db2 or oracle. I guess that depends on the apps you are developing.

>
> > That therefore access to the source code doesn't make sense to us.
>
> Access to the source code gives you the freedom to swith 'database
> specialists' even if you never touch the code yourself.
See above.

>
> It also means you never have to stop using the product simply because
> the vendor wants to sell you a new one if the product continues to
> meet your needs, since with source, you can recompile for for a new
> cpu, a new os, or when new security updates are available for the
> libraries it depends on.

And where are the security updates for the obsolete database? Where are the customers that want to buy a piece of legacy code?

>
> With source, you have the assurance that the product is yours for
> keeps, just like your own code, without source, you have no such
> assurance.

See above.

> > > 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?
>
> You still have the source code.

Yes, I can print it out and kill some trees with it. Somehow you still think I will become a database developer or can convince my boss to pay for the support of an obsolete application.

>
> > > 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.
>
> Yet the vendor gaurantees nothing.

He guarantees to put labour to my service requests. Btw, what does mysql guarantee if you take out a service contract with them?

>
> > The database vendor obviously
> > balances maintenance costs and development costs, trying to minimize both.
>
> The vendor only tries to maximize profits.
Yes, and where is the contradiction?

>
> > > 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.)
>
> You do not need to, just like if you design a curcuit with a
> proprietary conector or a standard one, the former is expensive and
> only comes from one comany, the later is cheap and comes from many.
> Unless you really need the former, you would always chose the later.
> In neither case are you required to manufacture connectors.
Just checking... All the databases we are talking support sql, or at least a reasonable subset of it right? So, by using sql I'm only tying those parts to the particular db that are special and which I use, right? So, the only "own investment" is tied to those features because I need them, right?
This might sound unusual for you, but if you use a great library, and suddenly it has a bug and there's no maintenance, the app is bust. Now, what are the cases here:
- I'm poor. So, neither could I pay for the fix, nor for the company. My   product depends on someone richer to pick up the pieces. (the code   or the rights to the code)
- I'm rich. So, either could I agree to pay more maintenance and keep   the vendor alive, or pay a few percent less (by cutting out the management   level of the vendor) and hire the developers to go on. - I'm a programming genius. then why did I use a library in the first case?

> > Well, looks like the only credible supporter of mysql is mysql ab.
>
> There are as many as the market will bear, since there is no
> artificial thing, like closed source, keeping competition away.
Closed source is nothing artificial either, it's the only way to go before you have payed the original developers.

> Since the Market is growing rather fast, and big names like SAP are
> promoting it, I see no reason to worry about a lack of support for
> MySQL.

If I were using SAP and not worried about recovery beyond restoring last night's backup I'd be using SAP/MySQL too, if I could send my MySQL bug requests to SAP.

>
> > > > > 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.
>
> What? Who follows Red Hat?

The Linux distributors. As an example of a big open source project. And that postgres windows company does the same, right (following the main postgres company)?

Btw, spelled out: I *CAN'T* hire "many companies, large and small" to support my open source product. For most, none exist, for some, one exists, tying me down, for very few, some companies support ports, some simply cash in.

Also, I've had my share of support by small companies. They have no way to make all customers pay a flatrate, they *always* bill by the hours, and they don't support new platforms if they differ from the current Dell pc because that's all they can afford. No, thanks, I'll stay with the biggies, and right now the only open source biggie is RedHat for the OS and no one for databases. However, if SAP buys MySQL AB that would make mySQL a real contender in the database business.

> What does this have to do with companies
> providing development services? What are you blathering about?
The connection is that somehow the development has to be coordinated because otherwise you won't have one project anymore but a bunch of quickly diverging incompatible branches. So, there are de facto owners. For Linux most commercial software vendors make sure that their stuff works with redhat and the other distributors scramble to make their distributions as compatible as possible. Of course, each adds some bells and whistles, like a nice config tool or checks whether all the packages work, but that's more or less it.

>
> > Nevertheless, each commercial software gets certified for single platforms,
> > therefore you are still tied to a single distribution, or the supported
> > subset.
>
> Different products have different cross platform stragies, the good
> ones try and support the widest number of platforms, almost all
> serious database software supports Linux now, including Oracle and
> Sybase. But in anycase, I have no idea how this relates to anything we
> are actualy discussing. Must be something funny in the drinking water
> in your parts.

We are discussing vendor dependencies. And if you buy a commercial linux product it typically says something like "RedHat Linux 7.2, 7.3, 8.0, Enterprise AS 2.1, 3.0", not "guaranteed to run on any kernel you manage to drag from the internet and compile on the PDA of your choice".

>
> > > > 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?
>
> Anyone who wants to be, as many as the market will bear, each
> competeting for customers and compentent labour with each other to the
> benifit of the consumer, simple economics.
In other words, no one.

>
> Oracle has you trapped because no one else can compete with them,
> since their source is closed. BUT EVEN STILL, I am not recomending you
> never use Oracle, I am only recomending that abstraction is a good
> idea, particularliy when you do not have source.
>
> > > 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.
>
> As I said, your question was a fallacy, since it was in responce to
> the statement that many companies, including IBM, support open source
> products, the statement did not say that IBM, specificaly, supports
> MySQL, specificaly.

What open source projects does IBM support, i.e. offer maintenance for?

Btw, many companies support closed source products too, typically their own. Some offer more, they are called consultants. So what? If I go out now into your nice shining world, what do I see? - Mysql: Mysql AB, with SAP sponsoring development. - Postgres: one sham, one windows only supporter and the owner So, regardles of what you wish for, If I depend on an open source database for its features or whatever I'm still tied to one supporter.

> Yet, if you wanted to, you could hire IBM to
> support your MySQL implementation, if you had enough money, they would
> be happy to take it.

If I had that kind of money I could have them implement my feature in DB2 too, right?

> They do not promote themselves as such, and would
> frankly be surprised to get such a contract, knowing that there are
> cheaper alternatives and that MySQL users are not currently the
> typical IBM consulting clients, however, with SAP behind MySQL AB,
> this could soon change.

At which point, your support requests still land at the same company regardless of whether the bug form has mysql or sap on it.

> > > 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.
>
> If the code is a working part of your application, it is not obsolete,
> however a closed source vendor can obsolete it
So can an open source vendor. Remember, I'm not beating up a dead horse.

> on purpose to force you
> to buy a new licence.

He can't. The only thing he can do is stop bothering about my bug requests (mysql ab can do that too) and tell the world that this product is obsolete (mysql ab can do that too).

> And you need no expertise in it, since if your
> product is popular, like say MySQL, the marker will attract lots of
> competition for your business.

What marker? And my product isn't mysql it uses it. (or, oracle, in that case)

>
> > > 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.
> If it's a working part of a production system, you do not need to be,
See above, that paragraph about me being either rich and poor and how the right to the source code is irrelevant.

>
> > It doesn't make anyone else (short of the original maintainers)
> > a programmer for that particular database on short notice.
>
> If it is a viable market, there will be programmers for it.
If it's a viable marked the original support wouldn't have gone bust.

> > It doesn't make
> > the maintenance cheaper than the migration to a still supported database.
>
> It may make migration uneccessary by allowing new entreprenuers to
> support it.

Oh yes! And this doesn't work at all with closed source, see informix.

> Competition among them will even make maintenance cheaper,

> and, of course abstraction makes migration, when neccessary, also
> cheaper.

And the product more expensive and slow in the first place.

>
> All this in perfect line with my adivice,
I really love the way you congratulate yourself more and more often.

> as stated in my original
> posting, and as still unrefuted in anyway by you copious blather.
Oh, I did refute it, you just ignored it. And asked me to help you forget by quoting shorter, right?

>
> > And it definitely doesn't make my boss keep a bunch of abandoned code
> > that we are the sole users of.
>
> First, if the system is widely used the code would not be abandoned,
Ditto for a commercial product.

> second, a closed source product is not less likely to be abandoned
> that an open source one,

It is. Because someone invested real money in it.

> third if it is abandoned then you are in
> better shape if you do have the code.

Sigh... We've been through this. In what way am I in better shape then? It doesn't make sense to wait for your mysterious entrepeneurs (who, in any case could also bid for the property of the bust company) and then we can reduce the problem to how do I as the sole left paying guy get some support from someone other than the original supporter. Which gives me the possibilities outlined above in the rich/poor stuff.

>
> > > > 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.
>
> You must also stop using the software then, and bear the costs related
> to that.

Ditto for open source. Remember, I leave when my bugs won't get fixed, regardless of open/closed source.

> I never said anything *always* makes sence, all projects have their
> own requirements, I have only given some general advice, good advice.
You should become a consultant.

>
> > > > 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.
>
> No, I tell you that source gives you freedom to chose, but sadely,
To choose what exactly? Any supporter out of one?

>
> > > 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.
>
> First of all, you do not have any such right,
I do. Witness all the 8.* and 7.* installations still around. Desupported ages ago.

> secondly, without
> source, how you will compile it for your new CPU, or new OS, or to
> link a security-updated library?

Even with the source, if I were to compile mysql to, let's pick a platform at random, my new cellphone, I'd have to do a bit more than ./configure&&make install, right? In fact, I'd have to go though all the code, look for any system calls, get to know my target system and how the system calls differ subtly, and still I'd have a much lesser chance of making it work than if the original maintainers did it.

> > Therefore abstraction is to be decided on a case-to-case base just like
> > any other thing.
>
> Funny, that's exactly what I said, many times in this thread.
Where? (I mean, before I pushed your nose in it?)

> > > 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.
>
> No, all your showing is your inability to follow a simple arguments.
>
> > If it's easy to change, the case for code rights disappears. Which way do
> > you want it?
>
> The 'case for code rights' does not disapear,
So, what are code rights good for if not for not having to change the database?

> but by abstarction,
> becomes less important, since abstarction is another layer of
> protection.

So my code gets clumsy and slow for no reason at all.

> This has been clear from my very first post in this
> thread.

To anyone else apart from you too?

> Keeping your archices in self-contained, self-describing,
> human-readable format was my third recomendation.
Oh yes, we've been through that too. Send me an email once you've done this so I can redirect our ISO9000 auditors to your webpage.

> > > > 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.
>
> No one is recomending this, that is only your own red herring.
You are recommending this. Or, rather it follows from your recommendation. An open source db stops getting maintained and every appvendor start to do his own maintenance, resulting in a bunch of uncoordinated fixes. And this is so, because the business case for a coordinated patch and release management has disappeared.

> The
> customer prerers abstacation when it means that they can use there own
> database,

The customer prefers to use his own database. How the vendor deals with it is not his problem. *Our* problem right now *is* such an abstracted product, which doesn't run properly on oracle because those guys never tested it with an UTF8 database, much less ISO dates. From hindsight we'd even accepted sqlserver if they had done it properly. As for other abstractions, we've seen plenty of products available for several platforms and the first question is "what is your main development platform?" and that's typically what we'll use too because we are really sick of Mainwin, mks toolkits where every path has a different \ or / convention or Java apps which need three tries each time I try to start them. (Before you ask: that's abstracting from the OS, ok?)

> if they only use the database for your application, then
> they see the database as a part of your application, and only want it
> to work.

Yes. Then *you* will optimize your costs, looking for a partner who can support your database. At which point we are at the maintenance question. Again.

> > Are you trying to change thread from opensource to abstraction?
>
> I am not trying to change 'the thread' -- I posted my recomendations,
See the subject line.

> > > 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.
>
> As I said, there are bad applications, both abstracted and
> unabstracted ones, your argument, is, as usual, a fallacy.
In what way?

>
> > > > 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.
>
> And, if your forced your customer into Larry's arms, they will blame
> you, not Larry.

Yes, and if oracle isn't willing to fix it I can give oracle a lot more trouble than mysql because their contracts are more expensive.

>
> > > > 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?

You should have read the next paragraph before responding.

>
> > 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.
>
> I don't plan on being 'the only surviving supporter', yet another of
So, what was this "right to the source code" stuff about?

> your fallacies, as the producs that I use are popular and their
> popularity is growing,

And that somwhow doesn't work for commercial databases, right?

> I also abstract my database access, so that if
> this changes, I can change with the dominant trends.
And somehow this relates to open source.

>
> (I wonder if you even know what a fallacy is, you use so so many of
> them)

Whatever your secret work experience may be your public english experience isn't good enough to teach me that language.

>
> > > > 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?
>
> I support my application and all the dependencies that I have forced
> on the client by way of it. If my application fails because of a
> dependency I have chosen for it, the customer will blame me.

>
> > Remember you disputed that it's a good idea to let larry provide
> > the oracle support.
>
> Remember, it was limited to the situatuion where the customers only
> dealt with Larry because of me.

Actually no. The point B was (and it's still in here for you to read) that the customer trusts Larry more than me. But you are right if we open a case D), "I force my customers into oracle because I get a percentage or something", my customers would be right to complain.

> For the millionth time, please try to
> follow.

Cut out this stuff. It makes you sound ridiculous.

>
> > > 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?
>
> What on earth are you talking about?

About how you solve that problem for your customers.

> I do not need to run my own linux
> distribution. You are a nutcase.

Then you depend on some linux vendor.
For you, simplified: You are deperately seeking a case where open source beats closed source. If you can take someone elses distribution you are dependent on him and need your customer to run that distribution. (Correct me if all your programs consist of perl scripts and don't load any shared libraries.) If no one else exists (any more) do your own support, directly or by hiring others, yet still you need the customers run your OS.

>
> > > 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.
>
> I made a series of suggestions, including open source and abstraction,
> you responded to my suggestions, therefore the topic is my suggestions
> and your objections to them.

Abstraction is irrelevant to open source because the big thing is the right to the source code, correct? And due to the small migration work while moving from one sql database to another it's irrelevant to closed source too. It's impossible if you depend on special features of your database. In that case your customer knows it and is with you.

> > 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?
>
> Well, you might have trouble understanding it, but I think I've made
> it clear that both source and abstraction have their benefits.
See above.

>
> > But the abstraction thingie was a nice diversion.
>
> Yeah, a 'diversion' I cleverly included in my very first post in this
> thread.

What's the difference? You didn't start the thread.

> What kind of idiot are you?

How old are you? Received on Fri May 21 2004 - 14:11:52 CDT