Re: What so special about PostgreSQL and other RDBMS?

[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.

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

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

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

Well, what more can we expect from Volker, the human fallacy?

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

The specific proprietary bindings can be wrapped in a simple function. Additional functions can be used to issolate proprietry features.

> And, I'm trying to convey this too, there's no need to ease it
> much more because it's not much trouble anyway.

Thanks for all your effort Volker, but I will continue putting any proprietary bindings my own functions, and use those functions through out my application, rather than have proprietary binding through out my application, and I will continue to recomend that others do the same, you do whatever you want though.

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

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

> Whatever.

I see. So so simple having nothing better to do? This will be my last response in this thread then. At least outside the PHP newsgroups.

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

Funny, that's what I said. Usualy however, performance concerns are not terribly significant and the abstraction can be kept very light weight.

> > 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. Maintenence contracts are perfectly fine.

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

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

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

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.

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.

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

Yet my advice is for the future, not the past, I see the example given as cautionary tale because of the 'ifs'.

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

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

> The database vendor obviously
> balances maintenance costs and development costs, trying to minimize both.

The vendor only tries to maximize profits.

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

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

There are as many as the market will bear, since there is no artificial thing, like closed source, keeping competition away.

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.

> > > > 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? What does this have to do with companies providing development services? What are you blathering about?

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

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

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

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

That's right, you are only 'locked in' if you can not change.

> > 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 on purpose to force you to buy a new licence. 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.

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

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

> 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. Competition among them will even make maintenance cheaper, and, of course abstraction makes migration, when neccessary, also cheaper.

All this in perfect line with my adivice, as stated in my original posting, and as still unrefuted in anyway by you copious blather.

> 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, second, a closed source product is not less likely to be abandoned that an open source one, third if it is abandoned then you are in better shape if you do have the code.

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

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

I have not attempted to define elegence for different people, only given specific examples.

> And abstraction doesn't always make sense either

I never said anything *always* makes sence, all projects have their own requirements, I have only given some general advice, good advice.

> > > 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, you have trouble understanding simple things. It's probably quite a good idea for you to pay Oracle to think for you, in your case, I withdraw my advice, however it still holds true for others, mor compitent profesionals

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

Oh never mind, just call Oracle support, you are obviously unskilled labour.

Good luck to you.

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

If you do not need to use it, yes, if you do, then //issolate its use// in your code with a wrapper function.

> 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. Yet abstarction is good advice, which is, as I've also said many times, all I have offered.

> > 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, but by abstarction, becomes less important, since abstarction is another layer of protection. This has been clear from my very first post in this thread. Keeping your archices in self-contained, self-describing, human-readable format was my third recomendation. If you have all three, you are in the best shape if your application and/or data has a long life span.

> > > 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. The customer prerers abstacation when it means that they can use there own database, 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.

> Believe me, it's easier to say "we require oracle" that "we require you
> to run my oen hacked version of MyFavouriteOpenSourceDatabase.

Depends on the costumer and wether or not they want to bear of adding Oracle to their environement.

> Are you trying to change thread from opensource to abstraction?

I am not trying to change 'the thread' -- I posted my recomendations, which included abstractions, you are responding to them, therefore in the discusion between you and I, it is my suggestions that are the topic and my only intrest is in defending them, I have no other reason to discuss anything with you.

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

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

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

I don't plan on being 'the only surviving supporter', yet another of your fallacies, as the producs that I use are popular and their popularity is growing, I also abstract my database access, so that if this changes, I can change with the dominant trends.

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

> > > 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. For the millionth time, please try to follow.

> > 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? I do not need to run my own linux distribution. You are a nutcase.

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

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

> But the abstraction thingie was a nice diversion.

Yeah, a 'diversion' I cleverly included in my very first post in this thread.

What kind of idiot are you? Received on Wed May 19 2004 - 05:05:56 CDT