Re: [GENERAL] Re: Is PostgreSQL ready for mission critical applications?

1999-11-24 Thread Bruce Momjian

  would you like it to work? What parts are too complicated? If they only
  *appear* to be so, then this is a documentation deficiency, otherwise we'd
  need to think about it.
 I think the concept of user friendly design is universal.  There should be
 one button in the middle of the screen you push and everything is done for
 you :)  (refer to technical support if you need to know more :)

I refer to this as "helmet-ware".  The software reads your mind, figures
out what you want it to do, and does it.

-- 
  Bruce Momjian|  http://www.op.net/~candle
  [EMAIL PROTECTED]|  (610) 853-3000
  +  If your life is a hard drive, |  830 Blythe Avenue
  +  Christ can be your backup.|  Drexel Hill, Pennsylvania 19026





Re: [GENERAL] Re: Is PostgreSQL ready for mission critical applications?

1999-11-24 Thread Lincoln Yeoh

At 11:48 AM 24-11-1999 -0500, Bruce Momjian wrote:
  would you like it to work? What parts are too complicated? If they only
  *appear* to be so, then this is a documentation deficiency, otherwise
we'd
  need to think about it.
 I think the concept of user friendly design is universal.  There should be
 one button in the middle of the screen you push and everything is done for
 you :)  (refer to technical support if you need to know more :)

I refer to this as "helmet-ware".  The software reads your mind, figures
out what you want it to do, and does it.

And halfway you change your mind :).

So it's still not fool proof. 

You need futureware. It'll predict what is really wanted and do that
instead ;). In fact it doesn't need MVCC and stuff like that, since it
knows what's going to happen. It'll have an Advanced Multi Universe
Concurrency Control.

Seriously tho. For things to be useful, there will always be a need for
humans to make decisions. 

For databases and much software a single "Install Yes/No" is not
satisfactory in sufficient cases to require additional decisions to be made
during installation.

The challenge is to organise the decisions/choices in as optimal a way as
possible. For example: The useful and popular choices are more
accessible/apparent, and the less popular ones don't clutter the others. At
the same time, making them obvious and understandable. 

Not easy. Easy to go wrong. If you put only one button, sometimes the
actual choice will be "Remove crappy software? (Yes/No)".

Hey, how about putting this option: "Global Thermonuclear War? (Yes/No)".
Of course that is only if Pg compiled with humour.h included.

Cheerio,

Link.






Re: [GENERAL] Re: Is PostgreSQL ready for mission critical applications?

1999-11-22 Thread Thomas Good

On Mon, 22 Nov 1999, Stephen Birch wrote:

 I have been surprised by the response to this question.  I was hoping that the
 responses would be more consistent, after all when software is unreliable it
 is generally known by all users.

Steve -  I tried to post an answer earlier (and it was verbose as is my
tendency!) but apparently it bounced.  I will cc the list, you and
scrappy on this note.

I converted my shop from FoxPro and PROGRESS (on UnixWare) to Postgres on
Linux/BSD this past year.  12 years worth of data.  My users are clinical
staff *not* computer ppl (in fact they are computer-phobic) and have made
myriad mistakes in entering and retrieving data via network and dialup
connections.  Our electricians have swapped feeder cables while my boxes
were online - ouch.  And I have made dubious errors in programming as I
learned perl, CGI and DBI.  But throughout it all, PG has suffered all of
our blunders and our predilection for the text data type.

Social Workers love to talk, even in their clinical progress notes.
But PG rolls with the punches and everyday I find new reasons to love this
database.  Performance is good (better on UnixWare and BSD than Linux)
and I am really happy that the Pg SQL is less idiosyncratic than Oracle.

Perl has become a 4GL of sorts for me (replacing PROGRESS) and my  140
character apps are now being ported to CGI for a netscape interface.
They work well...

I can't say enuf about how much I like postgres and - how much my users
like it.  They suffered with PROGRESS (slow) and FoxPro (corruption).
I run Oracle on Linux and have tried Sybase and Informix too.  I'll stick
with Postgres.  MySQL and mSQL are too much like flat file db's (concurrency 
control matters here) for me to even consider using them (I did try mSQL 
and didn't much care for it...)

I use Pg ver 6.3.2 which is *rock* solid altho I'm told 6.5.x is faster.
I may upgrade at some point but I feel very comfortable with 6.3.2 as I
know it runs a wide array of mission critical apps with good speed and
and good reliability.  The tech support from the likes of Vadim and
Bruce (and volunteers like Herouth M and Brett) is also something I've
gotten used to...I often waffle between which unix I like best but I
know which database I prefer.

Cheers,
Tom

--- North Richmond Community Mental Health Center ---

Thomas Good   MIS Coordinator
Vital Signs:  tomg@ { admin | q8 } .nrnet.org
  Phone: 718-354-5528  
  Fax:   718-354-5056  
  
/* Member: Computer Professionals For Social Responsibility */ 







Re: [GENERAL] Re: Is PostgreSQL ready for mission critical applications?

1999-11-22 Thread The Hermit Hacker

On Mon, 22 Nov 1999, K.Tao wrote:

 Well I do apologize as all my experiences are in the use of pre 6.5
 versions...I assume there have no longer been any reports of databases
 having to be rebuilt or restored from tape from the way you are talking ;)
 
 Although I still feel that the level of expertise for an admin on a
 Unix platform running PostgreSQL is much higher than lets say Oracle
 on NT.  One example is if you cancel out of a admin process like
 vacuum while in pgsql. U have to have enough exp to know what files to
 go and delete to be able to get pgsql back up and running.

Actually, I believe the pg_vlock file is planned for removal in v7.0 ...
just checked the current source tree, and this hasn't happened yet, but
there was talk on -hackers about removing it since MVCC invalidates the
requirement of locking all tables in a database while doing the vacuum...

Marc G. Fournier   ICQ#7615664   IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: [EMAIL PROTECTED]   secondary: scrappy@{freebsd|postgresql}.org