"Darren New" <dne### [at] sanrrcom> wrote in message
news:4766e906@news.povray.org...
> Gail Shaw wrote:
> > In theory, you want to prevent any form of data anomaly from multiple
> > accesses.
>
> Or, in my examples, you only have one writer, and that writer is doing
> atomic writes, and no reader looks at multiple records in one
> transaction. So what's there to transactionify?

Similar to what I have. My main system, most of the data changes are done
during the overnight processes. Hence, doing most of the reads uncommited is
safe. I don't need to go for read committed. I certainly don't need
serialisable.

Post a reply to this message

Darren New wrote:

> Or, in my examples, you only have one writer

I missed the part that there was exactly 1 writer. I thought you were 
just saying that you only ever write to one end of the table. [This 
condition alone obviously doesn't preclude Bad Things.]

> A bit kludgey, I'll admit, but better than holding a transactional lock 
> on the table for 30 seconds at a time.

Which is why I prefer Oracle's lock-free approach. But let's not start a 
flamewar about that too...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Gail Shaw wrote:

> Yup. You know the theory.

Well, and the practice of backing up and restoring a production 
database. But really, that's not especially hard if everything has been 
configured right... [You just need to DAMN WELL make sure you can do it 
in your sleep though.]

> In practice however things are sometimes done
> differently. Not because theory is wrong, but because sometimes shortcuts
> are necessary.

This part I understand.

> In theory, you want to prevent any form of data anomaly from multiple
> accesses. In reality, that often reduces concurrency to unacceptable levels,
> so some possible anomolies are accepted to get higher throughput.

Hence the various transaction isolation levels we spent so much time 
numbing our brains with, I take it...

Never came across anybody arguing that we should go for the very lowest 
option though. (Usually more like "the top option is best, but the one 
just below it is very much faster with only a couple of drawbacks"...)

> In theory, all tables should be at least 3rd normal form of Boyce-Codd
> normal form. In reality, you will get tables that are intentionally in 1st
> or 2nd normal form.

"Flexing the model?"

As in, use the theory, work out the theoretically ideal configuration, 
and then denormalise from there, making a note of what extra hoops you 
have to jump through with each denormalisation step and making sure the 
payoff is worth it. Is the way they taught us anyway... we never 
actually got as far as doing that in practice.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v7 wrote:
> I missed the part that there was exactly 1 writer.

Well, depends on the table. There's a few that get real-time data feeds 
from exactly one supplier. There are others that everyone writes to, but 
each writer has its own keyspace (such as the table that stores all the 
debugging output, keyed by host name, PID, and timestamp).

> I thought you were 
> just saying that you only ever write to one end of the table. [This 
> condition alone obviously doesn't preclude Bad Things.]

If nobody overwrites anything, then yes, everyone is by definition 
writing to the "end" of the table. (Appending to the table, that is.)

>> A bit kludgey, I'll admit, but better than holding a transactional 
>> lock on the table for 30 seconds at a time.
> 
> Which is why I prefer Oracle's lock-free approach. But let's not start a 
> flamewar about that too...

Well, this is optimistic locking, performed manually. :-)

-- 
   Darren New / San Diego, CA, USA (PST)
     It's not feature creep if you put it
     at the end and adjust the release date.

Post a reply to this message

Orchid XP v7 nous apporta ses lumieres en ce 2007/12/17 11:27:
> Tom Galvin wrote:
> 
>> Why reinvent the wheel?
> 
> I was hoping that if I make it simple enough, it will be impossible to 
> misconfigure it. ;-)
> 
The simplest programm that can have any configuration *CAN* be misconfigured! No 
mather what trap you implement, what failsafe you place, what sanity check you 
build, there is some genial idiot that will find a way to screw things...

-- 
Alain
-------------------------------------------------
You know you've been raytracing too long when you have ever "Hand-Coded" a 
bezier patch.
Stephan Ahonen

Post a reply to this message

Orchid XP v7 wrote:
> Gilles Tran wrote:
>> How difficult it is to actually listen to what professionals like 
>> Darren and Tom and Gail are telling you?
> 
> When somebody says "oh yeah, transactions aren't really all that 
> important" when I spent 4 months learning about how important 
> transactions are, I have to think "hmm, who is right here?"
> 


I am.


It's a helpdesk.  It's not for 10,000 employees at Microsoft, GM, NASA, 
or for members of Parliament.  It will not hold company financial 
information, or vital medical records during an epidemic, or operations 
at a nuclear power plant.  KISS, and don't reinvent the wheel.

Post a reply to this message

Orchid XP v7 wrote:
> Tom Galvin wrote:
> 
>> Why reinvent the wheel?
> 
> I was hoping that if I make it simple enough, it will be impossible to 
> misconfigure it. ;-)
> 

Why do you lie right to my face.  You know that's not possible.  You 
want to play.  Admit it.

Post a reply to this message

Alain <ele### [at] netscapenet> wrote:
....
> The simplest programm that can have any configuration *CAN* be misconfigured! No
> mather what trap you implement, what failsafe you place, what sanity check you
> build, there is some genial idiot that will find a way to screw things...

The most valuable programming course I have ever taken was taught by one Dr.
Breckenridge, who was justifiably notorious for the difficulty of his exams.
He did, however, give us one small break. A full five percentage points was
added to the score of any test paper with the following written verbatim at the
top:

"The statement: 'No one could possibly be that stupid,' is universally false."

Best Regards,
Mike C.

Post a reply to this message

On Mon, 17 Dec 2007 13:19:51 -0800, Darren New wrote:

> Jim Henderson wrote:
>> My point here is that he's actually stood up and said "now wait just a
>> damned minute" - something that he has needed to do for a while.
> 
> Does that make him a triffid? ;-)

LOL!  Is he planted?

Jim

Post a reply to this message

Mike the Elder nous apporta ses lumieres en ce 2007/12/18 09:08:
> Alain <ele### [at] netscapenet> wrote:
> ....
>> The simplest programm that can have any configuration *CAN* be misconfigured! No
>> mather what trap you implement, what failsafe you place, what sanity check you
>> build, there is some genial idiot that will find a way to screw things...
> 
> The most valuable programming course I have ever taken was taught by one Dr.
> Breckenridge, who was justifiably notorious for the difficulty of his exams.
> He did, however, give us one small break. A full five percentage points was
> added to the score of any test paper with the following written verbatim at the
> top:
> 
> "The statement: 'No one could possibly be that stupid,' is universally false."
> 
> Best Regards,
> Mike C.
> 
> 
In a programing course, the teacher asked for a program where all input was 
filtered to reject invalid entry. One student came up with his solution saying 
that his filtering was foolproof. The teacher, without ever looking, slamed his 
fingers across the keyboard and hit the return key. Instant crash! The program 
was expecting a numerical value faling within a given range. It filtered a 
numerical entry against that range. It was unable to cope with alphanumeric entry.

-- 
Alain
-------------------------------------------------
   A hooker once told me she had a headache.
   	Rodney Dangerfield

Post a reply to this message