Re: Simplified (a-la [G|N]DBM) DB access

On Apr 19, 2005, at 22:56, Dann Corbit wrote:

> Have you actually seen any problem in simple get/put/delete/update
> situations?

Not sure, that I understand your question.

> It's a shame when people spend a great deal of effort to invent a cure
> for a disease that does not exist.
>
> If you have problems with any of these things, there are usually good
> solutions.

Not always. Please, keep in mind, that not all problems need so
complicated querys.

> Using the copy API, you can insert like a raving madman. PostgreSQL
> has
> a prepared insert.

Yes, but it will be rest "prepared" till the end of the session.

> Safe, transacted inserts will be hard to do much
> faster than that.

INSERT is not the main problem, SELECT - is. Why I need complicated
SELECT * FROM words WHERE id = 21 to just make simple key/value search?

> You can also bracket bunches of operations in a
> single transaction if you like.
> In real life, how fast can you update records? If you have a titanic
> pile of users all trying to update, then the MVCC model is probably
> close to optimal anyway.

Again, INSERT and UPDATE is not a main problem.

> Do you have some measurement that shows PostgreSQL is not performing up
> to a real business case time requirement?

And again, business can be different.

> Sometimes, we can be guilty of 1980's batch oriented mind-set, if we
> have been doing data processing for a long time. The old paradigms no
> longer apply for the most part.
>
> Recommended reading:
> http://research.microsoft.com/research/pubs/view.aspx?msr_tr_id=MSR-
> TR-2
> 005-39

Thank you for the reading, but it is not the case for me.
First of all, I will repeat, in some situations, you need not so
complicated solution, and nothing comes for free. In some situation you
may need faster access with more complicated API, in some, of course,
SQL is more suitable.

As Tom said absolutely correct, in such situations Berkeley DB is
something that more suitable, but it will add another one database, so
ISAM-like (native, which does not translate it's calls to the SQL)
access to the PostgreSQL will be just fine.

Regards,
/Alexandre.