POV-Ray : Newsgroups : povray.off-topic : ODBC Server Time
11 Oct 2024 21:18:52 EDT (-0400)
  ODBC (Message 81 to 90 of 98)  
<<< Previous 10 Messages Goto Latest 10 Messages Next 8 Messages >>>
From: Gail Shaw
Subject: Re: ODBC
Date: 17 Dec 2007 15:34:37
Message: <4766dd5d@news.povray.org>
"Orchid XP v7" <voi### [at] devnull> wrote in message
news:4766a681$1@news.povray.org...
> Gilles Tran wrote:

> > and keep having these
> > far-out opinions about things you are visibly ignorant about?
>
> I see. So thinking that transactions matter is "far-out" and "visibly
> ingorant"?

No, but saying that transactions are essential and anything that doesn't
implement them is a toy, on the other hand....


Post a reply to this message

From: Gail Shaw
Subject: Re: ODBC
Date: 17 Dec 2007 15:41:49
Message: <4766df0d@news.povray.org>
"Orchid XP v7" <voi### [at] devnull> wrote in message
news:4766a4d1$1@news.povray.org...
> Gail Shaw wrote:
>
> > University != experience.
>
> True. But my point is that I'm not entirely clueless about what
> databases are and how they work. I actually know stuff about this stuff.
>

Yup. You know the theory. In practice however things are sometimes done
differently. Not because theory is wrong, but because sometimes shortcuts
are necessary.

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 (probably
50% of the select statements done in my largest system use the read
uncommitted isolation level)

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.


Post a reply to this message

From: Gail Shaw
Subject: Re: ODBC
Date: 17 Dec 2007 15:44:25
Message: <4766dfa9@news.povray.org>
"Orchid XP v7" <voi### [at] devnull> wrote in message
news:4766a720@news.povray.org...

> Personally I prefer Oracle's lockless multiversion system - although
> obviously that has its own set of drawbacks.

oh, btw, Oracle also uses locks.
http://download.oracle.com/docs/cd/B28359_01/server.111/b28318/consist.htm#i
5704


Post a reply to this message

From: Darren New
Subject: Re: ODBC
Date: 17 Dec 2007 16:19:02
Message: <4766e7c6@news.povray.org>
Orchid XP v7 wrote:
> I just object to being told I know nothing about databases when actually 
> I do. I don't claim to be a world-renound expert, but I do know 
> *something*.

Nobody is claiming you know nothing. We're just claiming that you're 
making incorrect claims about database systems that are easily checked, 
and then basing vehement opinions on said incorrect information.

-- 
   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

From: Darren New
Subject: Re: ODBC
Date: 17 Dec 2007 16:19:51
Message: <4766e7f7@news.povray.org>
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? ;-)

> So I still say "well done!"

True. :-)

-- 
   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

From: Darren New
Subject: Re: ODBC
Date: 17 Dec 2007 16:24:22
Message: <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?

I have another table, where I have multiple processes going thru it, 
doing what it says to do, each step taking maybe 10-30 seconds. Rather 
than using a transactional table, I do things like
SELECT * from to_do where state = 3 limit 10
then for each of those rows, I do
UPDATE to_do SET state=4 WHERE id=$id AND state = 3
then I check if the num_rows_affected > 0, and if so, I know I'm the one 
that changed that row.  Just as an example. If the rows affected was 
zero, someone else changed that specific ID.

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

-- 
   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

From: Darren New
Subject: Re: ODBC
Date: 17 Dec 2007 16:26:19
Message: <4766e97b$1@news.povray.org>
Orchid XP v7 wrote:
> I see. So thinking that transactions matter is "far-out" and "visibly 
> ingorant"?

No. Insisting that MySql is a toy that doesn't have them, even after 
being told your information is long out of date, is "visibly ignorant".  :-)

> Um... I did? [At least, I read the MySQL manual, and spent some time 
> using it.]

And you missed the part about multiple users and the "Begin transaction" 
statement?

> When somebody says "oh yeah, transactions aren't really all that 
> important" 

We said "they're not always important", not that they're not really 
important.

-- 
   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

From: Darren New
Subject: Re: ODBC
Date: 17 Dec 2007 16:27:25
Message: <4766e9bd$1@news.povray.org>
Orchid XP v7 wrote:
> Personally I prefer Oracle's lockless multiversion system - although 
> obviously that has its own set of drawbacks.

There's also optimistic locking. I think MySql implements a number of 
these techniques, depending on what you ask for. There are anumber of 
levels of isolation in standard sql, which mysql implement.

-- 
   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

From: Gail Shaw
Subject: Re: ODBC
Date: 17 Dec 2007 16:33:31
Message: <4766eb2b@news.povray.org>
"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

From: Orchid XP v7
Subject: Re: ODBC
Date: 17 Dec 2007 16:56:08
Message: <4766f078$1@news.povray.org>
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

<<< Previous 10 Messages Goto Latest 10 Messages Next 8 Messages >>>

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.