> ...  Others have
> suggested the existance of faster ways of generating primary keys (do
> you really need them here?) which solves your performance problem for
> this hypothetical situation.

I do need to generate these primary keys (e.g. assign a customer number 
or an invoice number, etc). Any reference to such suggestions to more 
efficiently generate primary keys would be greatly appreciated.

> Keep in mind the impact of the profile above on your application.
> Basically Squeak has to wait for the DB.  That means that each
> individual user will see a certain "responosiveness" to your 
> application
> which might be slightly degraded due to this wait.  That responsiveness
> is /not/ likely to degrade further due to GOODS as the number of users
> increases (although it certainly will degrade due to Seaside/Kom) since
> more users simply means more GOODS transactions waiting on sockets to
> complete.  The actual performance of this application is not likely to
> be severely impacted by GOODS unless you need to support large
> transaction rates for a single individual.

Imagine something like entering a new order. User will need to "find" 
the customer in the database, searching by phone number, name, address, 
zip code, previous order number, or a combination of these. If customer 
is found, then start entering order details and the order line items. 
At the end, post the order. If the customer was not found, then before 
entering the order details, the user will need to create the new 
customer. At any rate, I would imagine a few back and forths. First, 
the searching of the customer. I think in this regards, GOODS can be 
pretty good. I bulk loaded 25,000 customer records into a sample GOODS 
database and the search performance was very good (even though it took 
several hours for the bulk load process). However, when "committing" 
the transaction, the application logic would need to be something like: 
get the next customer number, assign it to the new customer, post the 
new customer, then get the next order number, assign it to the order, 
and finally post the order. Again, this is a hypothetical situation. A 
real life app would be more complex than this. I don't know how GOODS 
will perform in this situation, specially when you are talking about 
hundreds of thousands or over a million customers in a database (I have 
such a need).

> ... Due to the current
> GOODS client performance, this tends to come up more often than I'd 
> like
> but I'd prefer spending time on this than dealing with SQL (or
> frameworks like GLORP).

I'm trying to stay away from SQL and GLORP as well.

Thanks,
Daniel