What so special about PostgreSQL and other RDBMS?

[Joel Garry]

Why postgresSQL?? Why don't u say that all RDBMS except Oracle is
highly overrated. This way u don't have to fear about ur job for any
foreseeable future.

Your attitude reminds me of the attitude Americans had towards outsourcing
some 4/5 yrs ago. At that time all they could do is to arrogantly dismiss
outsourcing as unsustainable model. We all know what happened to them today.

I see lot of similarity between movement towards outsourcing few yrs
ago and now movement towards open source database. US companies, after
achieving cost savings thru outsourcing will next turn their attention
to money guzzling enterprise software like RDBMS. How long do you think
it will take them to realize that most of them don't deserve the price
tag they pay.

See ya after 3 yrs in Bangalore

There is a backlash against outsourcing now. Some parts are
sustainable and some are not. Anyone can do bad java code. For
administrative purposes, the database (well, not really, it's the
managers) requires someone local. And the definition of
administration is broadening.

I had come to this conclusion myself, then saw a talk on
administration futures by Guy Harrison where he said it, then a
solicited commercial email from Mike Ault where he said it, too.

Deserving has nothing to do with it. It's the useful application that
gets the money.

And the drudge development that can be outsourced? Bangalore is
losing it to China and Eastern Europe.

jg

 

[Quirk]

Is PostgreSQL reliable enough to be used for high-end commercial
application? Thanks

Some rules of thumb, A guide to the perplexed:

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

- Ideally, your Application's data access will be built around a data
abstraction layer that can use alternative database backends, i.e.
PEAR:B.

- If your data is really important to you, you will use network, not
application or database level security to protect access to it.

- If your data is really important to you, you will only keep a
secondary copy of it in *ANY* SQL server for indexing and querying
purposes, not as the primary datastore.

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

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

I'm also in Berlin BTW I hope you had a fun May 1st.

Cheers.

 

[Volker Hetzer]

Some rules of thumb, A guide to the perplexed:

- 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. The main problem is not the right to the source code
but the right to get maintenance.
An example: How many corporations had UTF8 built into oracle before
the UTF8 enabled distribution came out?
Who implemented ANSI PL/SQL for mysql before the mysql developers did?
The right to modify is a red herring. If I'm prepared to spend man-years on having
a developer work itself into postgresql or mysql (plus set up all the QA stuff)
I can also ask any other db company for the price of a feature. Or, in case
of old versions, buy vintage support.

- Ideally, your Application's data access will be built around a data
abstraction layer that can use alternative database backends, i.e.
PEAR:B.

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.

- If your data is really important to you, you will use network, not
application or database level security to protect access to it.

Wrong. If it's important it must not matter whether one tries to
access the data from a local or remote machine. A defense in depth
will always include a securely configured database.

- If your data is really important to you, you will only keep a
secondary copy of it in *ANY* SQL server for indexing and querying
purposes, not as the primary datastore.

The primary store is the safe with the tapes of last night. So what?

- 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).
In any case, permanency across more than two major database or other
software releases is difficult, regardless of the format.

- 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. They get nothing, so they are not
required to do anything.
So, I'd only trust mysql if I could do a contract detailing response times,
recovery services, a patch process and all that. Since I then have to
pay anyway, I might as well go for the company that's best at it. Oracle
has a reputation for that and after 5 service requests I've never been
disappointed yet. No idea how IBM or M$Soft do in the service area.

Lots of Greetings!
Volker

 

[Quirk]

- If you don't have the source code for a product, and the right to

That's not true.

Yes it is.

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.

The right to modify is a red herring.

Not if your application and the permenancy of your data is important.

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, or use a
class such as PEAR:B (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.

Wrong.

Famous last word(s).

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.

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!

The primary store is the safe with the tapes of last night. So what?

Not only last night, but also perhaps thirty years later, or maybe a
hundred in the case of public data, which is why some incomprehensible
filesystem blob, accessible only through a deamon for which you do not
even have the source code will not do, rather as I say, self
contained, self describing, human readable files. The filesystem blob
is designed for optimized access not perpetual storage.

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?

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

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

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

Cheers.

 

[Volker Hetzer]

Yes it is.

What was the value of this reply?

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.

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!

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:B (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.

Famous last word(s).

[empty reply]

Interesting that you believe that this can not be accomblished with
network security.

Yes. Now you figure out why.

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.

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.

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.

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

 

[Rove Monteux]

Because saying so wouldn't be true. There are documented security and
recovery practices for all of the commercial RDBMS products. There are
books, case studies, and years of experience from industry professionals
supporting the fact that while they may be different ... they all work.
The same can not be said for PostgreSQL. MySQL, in this regard, has a
far better record.

Care to disagree? Fine. Provide the names of 5 major commercial
installations of PostgreSQL.

I'll do it for the Oracle side.
1. Amazon.com
2. Mastercard
3. Visa
4. Federal Bureau of Investigation
5. Boeing Commercial Airplane Group
6. Bank of America
7. Washington Mutual Bank
8. American Express
9. Starbucks
10. Oracle Corporation

1. BASF
2. Vanten Inc.
3. Shannon Medical Center
4. Mohawk Software
5. Dravis Group

I myself have implemented solutions based on PostgreSQL in clients such
as Baltimore.

MySQL has a better record because theres people being paid for doing it.
For documenting, for making propaganda, etc. MySQL isnt really 'Open
Source' or 'Freeware' as you *have* to buy a license if you happen to be
using MySQL for a commercial solution.

In that sense PostgreSQL hasnt all the 'commercial' propaganda behind
it. PostgreSQL IS freeware AND opensource. Isnt GNU either, so gets no
GNU (eg. Linux community) support.

Not that any of that affects in its functionality at all, its a great
product, but people like yourself tied to all the commercial and
burocratic work tend to ignore.

Bit like Ruby. Pretty sure people that develop and use PostgreSQL would
bother with it at all.

But now saying that ' they all work. The same can not be said for
PostgreSQL. MySQL, in this regard, has a far better record.'.

Give me a break.

If commercial value and propaganda were signal of quality, Windows would
be the better OS in the world by far. OpenBSD/FreeBSD would be muck. And
anything not used by Warner, or Amazon.com, and less than $2000 in a tag
price would be muck as well.

Give me a break.


Cheers


Rove

 

[Howard J. Rogers]

Volker Hetzer wrote:

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!

Precisely. There's nothing wrong with contracts, or a willingness to pay
for a willingness to support. This is where open source can indeed
become the socialist flim-flam that Microsoft spoke about (though in the
wrong context, and drawing the wrong conclusions). Good software
requires a bit more than warm hugs and cuddles. It requires a contract.

And I heartily concur with your point about not wanting to create your
own development team. Was 200 years of division-of-labour theory in
vain? I think not. I'd quite happily pay for a competent team to do my
development for me, if that happens to free me up to do the stuff *I*
happen to be modestly competent at.

Why such trade-offs should be considered the spawn of Beelzebub, I have
no idea.

Regards
HJR

 

[Dave]

Care to disagree? Fine. Provide the names of 5 major commercial
installations of PostgreSQL.

Here's a newsflash for alot of DBA's. Most applications _do not_
need a database as powerfull as Oracle. Like it or not I would bet a
few apps could get by with flat files. (I'm half joking...)

I've been a DBA for about 8 years and its rare for a company to use
the advanced features of Oracle. Advanced Queueing, Replication (in
all its forms), RAC, flashback query, VPD, etc. etc. In all honesty
how often are these features used? I worked in a dev. shop once
where they were prepared to spend 6 months developing a feature that
could easily be handled by Oracle. Their reasoning was that they
didn't want to get tied into a particular database.

Now, i'm not a big fan of mysql... The gotchas link someone else
posted in this thread says it all but I think postgresql is a good for
small-mid sized apps. It has alot of features that mysql is missing.
Now, would I use it for my production financials system? Ummm no, but
I would use it for the corporate employee timesheet system. For
critical applications I wouldn't hesitate to recommend Oracle, in some
cases maybe even SQLServer but there is room for opensource databases.

 

[Quirk]

What was the value of this reply?

What was the value of yours? Or this latest one?

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

Yes, you have the right to be overcharged for work that may or may not
not suit your needs by only _one_ vendor, and no right to go elsewhere
when they fail, ignore you outright, stop supporting your application
or vanish from the face of the earth. Have you actually read your
contract or software licence? It only protects the vendor, not you.

You didn't read my posting, right?

You are one funny guy. Really. I'll bet you're the first guy in usenet
to ever ask this question rhetoricly.

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!

You are dependent on their licence because you built your own
application on top of a platform for which you have no source code,
and no right to modify, you then also have no leverage with the vendor
of the orginal software.

You have no rights at all, wether or not you are willing to pay.

Elegant coding... The holy grail of software engineering. Why am I
spontaneusly reminded of http://www.dilbert.com/comics/dilbert/archive/
dilbert-20040417.html ?

I dunno, because you're culturaly issolated and have a poor
imagination?

For db computing, reducing server load is the important thing.

No, it is not, in most cases CPU is not the most limited resource.

Interoperability
typically means primitive, network/db intensive sql.

No, interoperability means abilty to integrate applications in a
heterogeneus environment. It means standards and flexibilty.

Yes. Now you figure out why.

Because you don't know what you are doing maybe? Oh wait, you don't
need to, after all, you have decided to pay a vendor to know for you,
I remember now.

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.

If your network has holes, then your database is insecure, because I
can get right at the filesystem blobs, the reverse however is not
true.

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

What is it about "Self Contained, Self Describing, Human Readable"
that you do not understand?

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.

What does this have to do with "Self Contained, Self Describing, Human
Readable" files that can be read on any system past or present?

Get some real world experience.

Wow. Not only a comedian, but also a master logician.
What a compelling argument, tell me, how much do you know about my
experience, and why do you feel that talking about _me_ is a response
to my argument?

Wrong. I am the user, t.

Oh, well then I guess we have nothing further to discuss, my comments
here where meant for actual developers.

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.

 
You have no such right, ever, the only right you _can_ have is the
right to modify it yourself or contract someone to do it. Please read
your licence.

Cheers.

 

[Buck Nuggets]

... 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, or use a
class such as PEAR:B (for PHP), depending on what your application
requirs.

Son, it sounds like you're the victim of some simplistic advise from
database 101 book:
1. database portability is not (typically) as important as
application portability - since applications come & go far faster than
databases change, and some databases support multiple application
technologies (java + .net, php + python, etc).
2. abstraction layers can often cause more complexity than they
solve, unless the project is fairly sizable
3. the most powerful SQL capabilities are seldom supported in
abstraction layers - living without OLAP capabilities, for example,
means that you're limiting the usability & functionality of the
application.
4. having said all that - yeah, go with portable sql as much as you
can, and only deviate if there's a value in doing so. But don't work
yourself up into a religious hysteria about it.


Don't be a fool, implement security measures on each level.


That's a damn funny idea - now exactly how do you plan to keep the
6000 tables from a SAP financial database for a fortune 100 updating a
hierarchy of XML tables? You realize that the database is never
static, that performance & quality are already tough challenges
(without non-acid writes to XML files). And you must also realize
that nobody will care about that detail of that data in 30 years,
right? Oh yeah, and if you *really* want to archive it you'll keep it
on non-acid paper instead of in an electronic archive. Now - getting
transactions to span a print-device - that would make for an
interesting little undergraduate project.

Here's the thing - you've got yourself a nice objective there, and I
encourage you to pursue it. Just keep in mind that complex XML isn't
"human readable", that it doesn't contain sufficient business rules
and integrity constraints to be fully "self describing" either. So,
ten years from now if you really wanted to read that data (and most
often you won't) you really won't have a clue what it means - due to
the massive loss of context. Sure, you'll be better off than if you
had a file format you couldn't read at all - with XML you'll probably
be able to find a way of structuring the data (got help you if you
can't). But you will still have spent a lot of time & money on a
solution that'll fail you in the end.

So, you've got yourself a fine start on database technology. Now, go
get yourself a job, keep these objectives in mind, and in a few years
discover the wisdom in what Yogi had to say:
"In theory there is no difference between theory and practice. In
practice there is."


Buck

 

[Matt O'Toole]

Daniel Morgan wrote:

... otherwise stop promoting freeware

as though it was worth more than its price.

Your true colors are showing, especially when I see all the newsgroups this is
crossposted to. Shill be gone!

Matt O.

 

[Erland Sommarskog]

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, or use a
class such as PEAR:B (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.

This may sound good in theory. Real life is different.

One should keep in mind that few tools are so extremely powerful to make
things go really slow as database engines.

There are of course applications where portability is a requirement. I
once had contact with a small company who authored a system for producing
financial reports for big corporations. Their philosophy was that they
could not mandate which engine to use, so they aimed at portability. I
guess that was a fairly small system.

The system that I work with now runs only on RBDMS: MS SQL Server. This is
a business-critical system for our customers, and if I had support multiple
platforms, I would not be able to give our customers acceptable performance,
nor acceptable functionality. At least not to acceptable prices.

A competitor of ours were working on a replacement for their current
system - which dates from the end of the 1980s - and they worked just
along the line they suggested. Their owners poured in around 250
million SEK into that work, and the system is far from completed. That
competitor recently fired about 80% of their staff, and that new
system will never be completed.

 

[Quirk]

(e-mail address removed) (Quirk) wrote in message news:<[email protected]>...

Son, it sounds like you're the victim of some simplistic advise from
database 101 book:

Ok Dad, it sounds like you're the victim of the patronizing ass school
of discourse. My condolences to your coleagues.

1. database portability is not (typically) as important as
application portability - since applications come & go far faster than
databases change, and some databases support multiple application
technologies (java + .net, php + python, etc).

Both are important, which is more important depends on the data and
the application, in both cases my advice to either rely on open
standrads or abastract access when possible holds true.

2. abstraction layers can often cause more complexity than they
solve, unless the project is fairly sizable

I agree, when you have the perpetual right to the database and It's
source code, but if you are using a proprierty database then not using
an abstaction layer is folly, unless the project is so small that the
code is disposable.

Abstracting your data access can be as simple as writing a function to
use as a wrapper OR as complex as a full blown data access object,
depending on the application.

3. the most powerful SQL capabilities are seldom supported in
abstraction layers - living without OLAP capabilities, for example,
means that you're limiting the usability & functionality of the
application.

I have no argument here, as so far this is true, but experience
prompts me to bring up two points: First is how often are 'powerful
SQL capabilitites' used to compensate for poor database design?
Second, how certain are you that Proprietary databases (in fact than
YOUR particular one) always have more features than Open Source (or
Competetive Alternatives) ones to justify engineering your application
so that you are dependant on it forever?

I know, the answer is 'depends', but I hope you see what I'm getting
at.

4. having said all that - yeah, go with portable sql as much as you
can, and only deviate if there's a value in doing so. But don't work
yourself up into a religious hysteria about it.

I agree, I never said anything different, the only time you *must*
abstract your data access is when your application and/or it's data
has a long expected life time and depends on a prorietary Database.

Don't be a fool, implement security measures on each level.

OK Mr. T. I agree. What I was really argueing against where those
(like Volker) who think that Database security is a replacement for
network security, I'm trying to make it clear that network security is
more important, since databasy securite depends on it, although, yes
both are important.

That's a damn funny idea

I'm a funy guy, always good for a laugh or two.

- now exactly how do you plan to keep the
6000 tables from a SAP financial database for a fortune 100 updating a
hierarchy of XML tables?

It was only an example, one that for some applications makes sense,
you can always randomly chose an example wher it does not make sence
but this, my silly friend, is what is know as a straw man.

I guess this would be a good time to mention that SAP has been working
closely with MySQL these days.

You realize that the database is never
static, that performance & quality are already tough challenges
(without non-acid writes to XML files).

Yes I do realize this, but don't let my understanding discourage you
from further random blather if it makes you feel smart.

And you must also realize
that nobody will care about that detail of that data in 30 years,
right?

To bad you didn't realize that I never suggested otherwise.

Oh yeah, and if you *really* want to archive it you'll keep it
on non-acid paper instead of in an electronic archive.

Perhaps, but paper is not always superior to some sort of WORM
storage, provided you use an intellegent storage format, my main point
is that an imcomprehensible file system blob, readable only by a
deamon for wich you have no source code, is not such a format.

Now - getting
transactions to span a print-device - that would make for an
interesting little undergraduate project.

I would consider redundant WORM devices instead.

Here's the thing - you've got yourself a nice objective there, and I
encourage you to pursue it. Just keep in mind that complex XML isn't
"human readable", that it doesn't contain sufficient business rules
and integrity constraints to be fully "self describing" either.

Thanks for the XML tips.

Sheesh. Where were you when I was writing my Pull DOM to DOM parcer?

So,
ten years from now if you really wanted to read that data (and most
often you won't) you really won't have a clue what it means - due to
the massive loss of context. Sure, you'll be better off than if you
had a file format you couldn't read at all - with XML you'll probably
be able to find a way of structuring the data (got help you if you
can't). But you will still have spent a lot of time & money on a
solution that'll fail you in the end.

Ok so your argument amounts to that since any approach *MIGHT* fail, I
should recomend the aproach that *WILL* fail?

What the hell are you trying to say?

So, you've got yourself a fine start on database technology. Now, go
get yourself a job, keep these objectives in mind, and in a few years
discover the wisdom in what Yogi had to say:
"In theory there is no difference between theory and practice. In
practice there is."

 
If I happen to meet the unemployed, inexperience person you imagine
you are talking to, I'll tell him that the ignorant pompous ass says
hello.

Cheers.

 

[Quirk]

Got a news flash for ya...

Oh boy, it's Seseme Street News, OK Kermit, keep talking.

If you have a maintenance contract with a vendor and something of
theirs' is broken, they must fix it if you need it.

Perhaps, but when the product in question is proprietary you have no
recourse when they fail, because no one else has any right to modify
the source code.

When you have a right to the source code you can sign such a contarct
with any firm you like, and fire their ass and hire another when they
fail.

I know this
because it happend to us recently at work. We found something broken
it a version of a prticular commercial RDBMS that had been fixed in a
later release, but due to customer requirements we cannot yet upgrade
to that version (i.e., the customer is unwilling to pay for it at this
time). The vendor didn't want to fix it but because the customer is
paying them beaucoup bucks for a maintance contract we demanded that
they do so. They did and supplied us with the necessary patch.

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, which only
shows how vulnerable you where to begin with, 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. In anycase,
you were lucky the vendor did decide to support you, other folks in
the same situatuion have not been so lucky.

The only way you can get that kind of support is with a maintance
contract. With Open Source we'd have had to spend many extra
man-hours trying to find where the problem was and how to fix it
without breaking anything else.

Why? You could have the exact same contarct with a vendor supporting
an open source product, or negotiate access to source for the vendors
product, the only difference being that you then have leverage. Or
failing that, your application could have been designed to to give you
alternatives,

You programmed yourself into a corner, and are now trying to use your
folly, which nearly cost you a customer, as a positive example.
Interesting.

It is people like you that warm the hearts of confidence men
everywhere.

And we didn't hace the time to fool
with such nonsense as this occurred in a production application that
had to be up 24x7x365.

But you put yourself in a position were you may have been unable you
support your own customer _AT_ALL_ except for the good graces of your
vendor. I pitty your customers if they really do expect to get
24x7x365 under such an arrangement.

Cheers.

 

[Quirk]

Quirk ([email protected]) writes:

The system that I work with now runs only on RBDMS: MS SQL Server.

Well, I hope that the other readers of the thread now know enough to
never hire a company as stupid as yours.

I hope you one day learn how to write real software before your
unskilled labour is no longer needed in the industry.

Cheers.

 

[Volker Hetzer]

Oh boy, it's Seseme Street News, OK Kermit, keep talking.


Perhaps, but when the product in question is proprietary you have no
recourse when they fail, because no one else has any right to modify
the source code.

I have, at most, the right to sue them, at least, the right to cancel the
contract which hurts them way more than if I go to a postgres developer
and tell him I'm not interested any more. So, unlike open source developers,
they actually have an interest in doing something.

When you have a right to the source code you can sign such a contarct
with any firm you like, and fire their ass and hire another when they
fail.

But it doesn't make sense to use any other firm than the guys who wrote it.
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.

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.

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?

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.

Maybe, but in case of open source software they'd say 'Good luck
working into our source code, see you in two years'.

Why? You could have the exact same contarct with a vendor supporting
an open source product,

Yes, but then it would cost like any other product, right?

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.

Or
failing that, your application could have been designed to to give you
alternatives,

Right. And the customer throws away years of experience with one db system
and pulls a finished, reliable and maintainable alternative installation out of the hat.
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?

You programmed yourself into a corner, and are now trying to use your
folly, which nearly cost you a customer, as a positive example.
Interesting.

It is people like you that warm the hearts of confidence men
everywhere.


But you put yourself in a position were you may have been unable you
support your own customer _AT_ALL_ except for the good graces of your
vendor.

Why? He doesn't support the db. The db vendor does that. All he has to do is to
show that it's othe db's fault, at which point his customer's maintenance
contract with the db vendor kicks in. Normal business practice.

I pitty your customers if they really do expect to get
24x7x365 under such an arrangement.

Oh, they do get it. Because it's in the contract, you know?

Greetings!
Volker

 

[Volker Hetzer]

What was the value of yours? Or this latest one?

A question is not an answer.

Yes, you have the right to be overcharged for work that may or may not
not suit your needs by only _one_ vendor, and no right to go elsewhere
when they fail, ignore you outright, stop supporting your application
or vanish from the face of the earth. Have you actually read your
contract or software licence?

Of course. See the end of this posting.

It only protects the vendor, not you.

I've read the licence and done even more: I've used the software and tested the contract.

You are one funny guy. Really. I'll bet you're the first guy in usenet
to ever ask this question rhetoricly.

Nice way of avoiding an answer.

You are dependent on their licence

I'm dependent on the author's licence regardless of which database I use.
It's just that some licences give me the illusion of being able to do something
while mainly giving me in reality the ability to shoot myself in the foot or paying
someone else to shoot me in the foot.

because you built your own
application on top of a platform for which you have no source code,

Same question: Did you read what I wrote?
I don't care about the source code, I care about product and support
quality. And, since I am not the developer of the software, nor is anyone else,
apart from *the* developers, anyone else is going to make a worse job than
them. So, I get the best support when I'm paying them and no one else.

and no right to modify, you then also have no leverage with the vendor
of the orginal software.

You have no rights at all, wether or not you are willing to pay.

Read oracles licence some time. There it says very clearly what
you get if you enter a support agreement.

I dunno, because you're culturaly issolated and have a poor
imagination?

No, it's because the phrase "elegant coding" is just as empty.
Or as the phrase "the one true god" uttered by people of
different religions.

No, it is not, in most cases CPU is not the most limited resource.

Yup. Which, in a well configured db is CPU load because
caching, indexing and db specific sql takes care of the i/o load.
Nevertheless, I concede, it *is* possible to have such a
horribly configured system that i/o load becomes an issue. It's also
possible to have a database that permits so few actions
that the dba can't do anything about a badly written app.
fortunately, oracle is different.

No, interoperability means abilty to integrate applications in a
heterogeneus environment. It means standards and flexibilty.

So? What's more "standardised" about mysql's socket interface than
about oracles OCI or ESQL?

Because you don't know what you are doing maybe?

Wrong. Try again.

Oh wait, you don't
need to, after all, you have decided to pay a vendor to know for you,
I remember now.

Right. The alternative is not paying anyone and trying to figuring out the
source code on my own, right? Or paying someone else who starts
from scratch too?

If your network has holes, then your database is insecure, because I
can get right at the filesystem blobs, the reverse however is not
true.

Care to elaborate? An insecure network does not mean that someone can
log on to the database server from anywhere but the console screwed onto
it. And securing the listener (in case of oracle) is part of the database
configuration.

What is it about "Self Contained, Self Describing, Human Readable"
that you do not understand?

See above.

What does this have to do with "Self Contained, Self Describing, Human
Readable" files that can be read on any system past or present?

It has to do with permanency. Try to read what you quote.

Wow. Not only a comedian, but also a master logician.
What a compelling argument, Thanks.

tell me, how much do you know about my
experience,

What your arguments tell me.

and why do you feel that talking about _me_ is a response
to my argument?

Because your argument isn't backed by anything. Give me some
substance and we can talk about it. All I've hear so far is the
usual open source rethoric about me or someone else being able
to magically support a product in a few days or weeks after the
original developers have abandoned it, or me.

Oh, well then I guess we have nothing further to discuss, my comments
here where meant for actual developers.

So, oracle people should further develop oracle and mysql people
mysql. Did I get this right?

You have no such right, ever, the only right you _can_ have is the
right to modify it yourself or contract someone to do it. Please read
your licence.

"Assistance with my SRs 24 hours per day, 7days a week". Practically I usually
get two or three guys working on a typical SR of mine, depending on how
log it takes. Without a contract I'd get a 'buzz off, I'm doing my exams this month'.

Volker

 

[Erland Sommarskog]

Erland Sommarskog <[email protected]> wrote in message


Well, I hope that the other readers of the thread now know enough to
never hire a company as stupid as yours.

I hope you one day learn how to write real software before your
unskilled labour is no longer needed in the industry.

Well, I have the guts to sign my articles with my real name. You haven't.
So you don't really have to consider whether what you say affects your
possibilities on the market.

The product that my company manufactures is for a narrow segment on the
market: stock brokers and other actors on the financial markets, so most
readers would not have reason to contact us anyway.

Anyway, I only offered testimony from real life. As I said, a compeitor
of ours tried precisely what you teach. And that company never managed
to complete their system.

 

[Quirk]

A question is not an answer.

And what was your reply?

Of course. See the end of this posting.
I've read the licence and done even more: I've used the software and tested the contract.

Realy, care to quote the part of the Contract that Gaurantees you any
rights?

Instead, what you will find is that the contracts insists that the
Software is not gauranteed to be usefull for any particilar purpose,
and that they deny all responsibilitty for it to the extent possible
by law.

By "tested the contarct" what you mean is you agreed to pay them
completely on their terms and where satisified with the results they
chose to give you.

Have you tested alternatives?

Nice way of avoiding an answer.

Are so so stupid that you actually expect a serious answer that was
obviously a
hostile attempt to insult by way of a rhetorical question?

I'm dependent on the author's licence regardless of which database I use.

Yes, which is why you should choose one that give you a perpetual
right to the source code, otherwise you are locked into a dependancy
that may prove fatal to your application.

It's just that some licences give me the illusion of being able to do
something while mainly giving me in reality the ability to shoot myself in
the foot or paying someone else to shoot me in the foot.

Unsubstantiated bunk, if you have the source code, it is not magic to
fix it, or extend it, just normal progamming. Simple calling something
an illusion does not explain why you condsider it impossible to
actually change a program. Perhaps you should consider a different
line of work.

Same question: Did you read what I wrote?

A better question: What kind of an idiot are you that, in the face of
good sense, the best you can do is attemp insulting, evasive
rehetoric?

I don't care about the source code, I care about product and support
quality. And, since I am not the developer of the software, nor is anyone else,
apart from *the* developers,

As I said, my comments where ment *FOR DEVELOPERS* that is those who
are developing *NEW* appliciations, and my advice is simple enough,
despite your contortions: If your application is important to you, do
not engineer a dependency on code you do not have access to.

anyone else is going to make a worse job than
them. So, I get the best support when I'm paying them and no one else.

More unsubstantiated bunk, first of all, in many cases you can hire
the original developers, regardless of your right to the source code,
secondly, by hiring the "Copyright Holders" you *ARE NOT NECESSARLIY
HIRING THE DEVELEORS*, who may not even be with the company anymore,
in fact you are often hiring some peon who they scooped of the
consulting market 5 minutes before sending him to your office as an
certified solutions prodiver or whatever idiotic buzzword whey have
for their unskilled labour.

And finaly, it is a falalcy to say that someone will do a worse job
simply because they are not the original developer.

Read oracles licence some time. There it says very clearly what
you get if you enter a support agreement.

But it stops short of guaranting that your apllication will actualy
work, or that your existing version of the software will be supported.

In anycase, I am not arguing agianst using Oracle, as I said, if
Oracle suits your needs and you think it's worth the money, use it,
however, my advice is that if you do develop an application, write
your code in such a way that you do not depend on Oracle, but can
easily switch it over the the greatest extent possible.

I have no idea why you are insisting on jumping up and down like this
is crazy talk, the only plausible theory is that you get some kind of
thrill out of embarassing yourself.

No, it's because the phrase "elegant coding" is just as empty.
Or as the phrase "the one true god" uttered by people of
different religions.

This is just stupid, elegnt coding is hardly as unatainable an ideal
as you seem to be conviced, in fact in this specific case it's a
simply matter of using a standard wrapper function throughtout your
aplication to access your data rather than using proprietary bindings
throughout your application, if your application is sufficently
complicated, perhaps a data abstaction object might be usefull for
this function, perhaps not, if you use any non standard features of
your database server, then write some additional functions as wrappers
for these. It is anything but rocket science.

Yup. Which, in a well configured db is CPU load because
caching, indexing and db specific sql takes care of the i/o load.

What about the human and financial load? As in the load on the DBA,
inhouse developers, consulting budgets and application support staff?

Nevertheless, I concede, it *is* possible to have such a
horribly configured system that i/o load becomes an issue. It's also
possible to have a database that permits so few actions
that the dba can't do anything about a badly written app.
fortunately, oracle is different.
So? What's more "standardised" about mysql's socket interface than
about oracles OCI or ESQL?

Are you having a nightmare in which we are dicussing the various
merits of MySQL versus Oracle? Please follow your own advice and read
this thread again so that you might figure out what is it we are
actually taking about.

Wrong. Try again.

The more you talk, the clearer it is how right I was.

Right. The alternative is not paying anyone and trying to figuring out the
source code on my own, right? Or paying someone else who starts
from scratch too?

More straw men and red herrings. If you are a Developer, which is who
my comments are addressed to, it is your responsiblilty to your users
and clients to know how your application works and to be able to
support it without allowing some third party to hold them hostage.

Care to elaborate? An insecure network does not mean that someone can
log on to the database server from anywhere but the console screwed onto
it. And securing the listener (in case of oracle) is part of the database
configuration.

If the above is true, that someone can only access any of the devices
on your Database server via the local console, then your network *IS*
secure (perhaps too secure, but that's beside the point), However, if
your network is not secure, then that is not true, and your Database
security is a dangerous false sence of security.

This is what I'm trying to say, that network security comes first,
because Database security can only depend on it, not being able to
actualy protect devices, which is the burden on the OS and networking
environment.

Once again, It must be assumed that your consternations to contend
this point are some weird form of self-flagilation.

It has to do with permanency. Try to read what you quote.

What does reading text files have to do with Chip design? I can read
text files I created on my Apple ][, and no, I do not have the orginal
hardware (well maybe my mom does somewhere in her basement).

Try to avoid making an ass of yourself with further pretentions.

What your arguments tell me.

Which ones? That abstracting access to suspect dependencies is a good
idea? That database security is secondary to network security? That
one should keep archives in a format that is likely to be readable
forever?

All these things come from experience, your attempt to question my
experience, only show that you are unable to formalute an actual
argument, so you try and discredit the arguer instead of the argument.

Because your argument isn't backed by anything. Give me some
substance and we can talk about it.

Oh please, my argument has been presented well enough, attacking me
just shows you can not defend your own, that is if you actually had
one.

If my argument was not backed up by anything it would easy enough to
refute it without attempting to insult me, you started with the
insulting precicely because you could not defeat my arguments.

But please, don't take this as discourgement from continuing to try
your silly insults, I don't mind being given the oportunity to
embarrass you personaly as well as refute your arguments, but it is
hard for me to understand why would chose to subject yourself to such,
as one would think it would more pleasent for you to simple lose a
respectfull debate, rather than lose a debate and a battle of wit at
the same time.

All I've hear so far is the
usual open source rethoric about me or someone else being able
to magically support a product in a few days or weeks after the
original developers have abandoned it, or me.

These must be voices in your head that you are hearing. Since my
argument have been quite clear and even sumerized several times.

Your arguments amount to the metaphysical belief that only the
copyright holders of your favourite proporiety software know how to
program, that the very concept of good programming is an illussion,
and therfore the only way forward is to make yourself both tehnicaly
and legaly dependent on them as much as possible.

So, oracle people should further develop oracle and mysql people
mysql. Did I get this right?

No, that's not right, that's not even wrong.

(with applogies to Wolfgang Pauli)

Application developers should avoid locking themselves in to external
dependencies, either by not using products to which they have no right
to the source code, or abstracting access when they do use such
products. Simple.

And having right to the source code does not mean that the program is
'open source,' as you can purchace such a right for propretary code,
as is common for libraries.

Of course, when the program _is_ open source, you are guaranteed that
right.

"Assistance with my SRs 24 hours per day, 7days a week". Practically I
usually get two or three guys working on a typical SR of mine, depending on
how log it takes. Without a contract I'd get a 'buzz off, I'm doing my exams > this month'.

"Assitance" only means that they will provide someone whose time they
can bill you for, not that anything will be accomplished. And you
discredit yourself by attemping the fallacy that the only way to have
access to an applications source code is to hire some one who is doing
exams. Many large companies, and profesional develpoers provide source
licences and/or support open source products, including the largest
computer company in the world, IBM.

Cheers.

 

[Quirk]

I have, at most, the right to sue them,

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.

Good luck in your legal adventures. I prefer to solve my problems by
programming. (my users and clients seem to prefer this too)

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?

than if I go to a postgres developer
and tell him I'm not interested any more. So, unlike open source developers,
they actually have an interest in doing something.

What on earth are you trying to say here? Why is a postgresql
developer any more or less interested in your contarct than one who
pedals proprietary software?

But it doesn't make sense to use any other firm than the guys who wrote it.

Why? What magic powers are possesed by the firm that holds the
copyright? Expcet the power to prevent anyone else from touching or
looking at their code?

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.

By the way, I am _not_ arguing that one must do everything
themeselves, only that one should not get locked into being dependant
on a single provide.

As I'v said, I'm baffled that this is so controversial that you all
expect me to defend my good name merely for saying it.

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.

Why was he vulnerable if he had a contract that required the vendor to work?

Because there is no such requirement, you can not really force an
unwilling vendor to do work that do not want to do. If you think you
can, you are delusional. If you have enought legal might, you may be
able to get a refund, usualy limited to the whatever you originaly
paid, not compensating you for you own ivestment.

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

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.

Yes, but then it would cost like any other product, right?

Yes, developing applications costs money, it is this investment I am
advising people to protect by not getting locked into third party
dependencies.

The access to the source means nothing, see above.

It means everthing. It means the difference being being the master of
your applications and contracts or being a slave to a third party
vendor.

Right. And the customer throws away years of experience with one db system
and pulls a finished, reliable and maintainable alternative installation out
of the hat.

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.

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

Why? He doesn't support the db. The db vendor does that. All he has to do is > to show that it's othe db's fault, at which point his customer's maintenance
contract with the db vendor kicks in. Normal business practice.

Yes, passing the buck is unfortunalty the normal business practice,
however good firms neither do it or put up with 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.

BTW, this latest response is much better in tone than your last one, I
hope this is a trend.

Cheers.