Ann wrote:

>>Granted - but I'd need to hear from somebody with a real application
>>that could be improved by quotas.

David Johnson wrote:

>>

> In a typical (for me) system: You have about 150 developers writing
> code to interface with legacy back-end systems.

From context, I gather that your developers are working on the
production databases. Is that true?

> You need sub-second
> responsiveness for 8,000 users whose work lives rotate around system
> capabilities, plus automated processes tracking some 50,000 pieces of
> equipment and a similar number of current business transactions in real
> time in a multi-terabyte database.
>
> Weekly spike loading is roughly 2.8 million transactions per hour.
> Yearly spike is almost double that. System responsiveness during
> spikes is not permitted to degrade noticeably, because it translates
> directly to noticeable numbers of dollars per minute in lost
> business.

In short, a major and mission critical application, and if the
assumption is correct, one that mixes real-time processing and
software development. Exciting.

>
> It is much better to have the query break in development than to hang
> the users up for a minute in production. A "hard" break must be fixed
> in development (the governor killed it, it's too long, figure out what's
> wrong and make it work) - a long running query can be ignored and cause
> delays in transacting business.

Perhaps I'm being obtuse, but I don't see exactly where quotas would
help. The ability for a developer to kill a query - absolutely, but
what quota would you choose to limit?

Regards,


Ann