Re: Major features for 9.1
От | Jeff Davis |
---|---|
Тема | Re: Major features for 9.1 |
Дата | |
Msg-id | 1302029774.438.31.camel@jdavis-ux.asterdata.local обсуждение исходный текст |
Ответ на | Re: Major features for 9.1 ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>) |
Ответы |
Re: Major features for 9.1
|
Список | pgsql-advocacy |
On Mon, 2011-04-04 at 16:56 -0500, Kevin Grittner wrote: > SSI allows you to enforce arbitrarily complex user-defined business > rules within the database without blocking, by automatically > detecting live race conditions in your SQL transactions at runtime. > It protects you by safely rolling some of them back (which can be > retried safely). "SSI allows you to enforce arbitrarily complex user-defined business rules within the database without blocking..." If I heard that statement and nothing else, and then encountered a problem where SSI was a good solution, I'm not sure I'd make the connection. It sounds a little vague (most people think SQL already magically does that), and "complex" is probably a bad word to use (people often read "complex" as "doesn't apply to me"). Sometimes I try to reverse the order and see if it sounds a little better. Maybe something like: "SSI automatically detects any race conditions among concurrent transactions, and safely rolls some transactions back. That means you can enforce arbitrary business rules and mix transactions safely without blocking; and simply retry any failed transactions." Still a little long, but I like the order a little more. At least for me, "automatically detects race conditions" seems to have the most punch, so it makes sense to put it first. Ordinarily it's good to put a business need first, so I see why you wrote it that way originally. But in this case, I think that "safety" and "error detection" can be seen as the business needs; because most people probably think they are enforcing their business rules already. If they happen to be doing so safely already, then perhaps you can drill down into the penalties they are paying in performance (due to blocking) and/or development time (because getting it right is not easy). Just my thoughts. It depends on the audience, of course. Regards, Jeff Davis
В списке pgsql-advocacy по дате отправления: