Orchid XP v7 wrote:
> I was expecting great things. Maybe too great. What I actually found is 
> that by default "commit" and "rollback" are no-op, and transaction 
> handling is an "optional feature" that you have to explicitly enable.

Honestly, of the 30 or so tables currently in my application, there's 
about 5 that need transactional consistency. I don't need it in the 
debugging logs. I don't need it in the (equivalent of) web access logs. 
I don't need it in the tables that's collecting the real-time feeds off 
the various partners, nor off the custom hardware. Those are all 
append-only (for the most part) tables.

But where I need it, I turn it on, and take the penalty of speed over 
correctness.  Enforcing transactions is high overhead if you don't need 
it. If all your table write-accesses are to a single row, why would you 
want to lock things?

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

Darren New wrote:

> Honestly, of the 30 or so tables currently in my application, there's 
> about 5 that need transactional consistency.

Well, my application will probably only be about 5 tables, and it's 
simple enough that speed is unlikely to be a problem. So why make things 
more difficult than necessary?

> But where I need it, I turn it on, and take the penalty of speed over 
> correctness.  Enforcing transactions is high overhead if you don't need 
> it. If all your table write-accesses are to a single row, why would you 
> want to lock things?

Why do you need to lock things to enforce transactional integrity? 
Locking is only one (suboptimal) way to solve the problem.

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

Post a reply to this message

Orchid XP v7 wrote:
> Well, my application will probably only be about 5 tables, and it's 
> simple enough that speed is unlikely to be a problem. So why make things 
> more difficult than necessary?

Then use the innodb table type, and be happy.

> Why do you need to lock things to enforce transactional integrity? 
> Locking is only one (suboptimal) way to solve the problem.

The RDBMS locks things to enforce transactional integrity. I don't do it 
explicitly. I merely start a transaction, and the appropriate rows get 
locked.

Whatever you do to enforce transactional integrity? It takes resources.

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

Darren New wrote:
> Orchid XP v7 wrote:
>> Well, my application will probably only be about 5 tables, and it's 
>> simple enough that speed is unlikely to be a problem. So why make 
>> things more difficult than necessary?
> 
> Then use the innodb table type, and be happy.

It just worries me that the designers of this system fundamentally think 
that transaction integrity is so unimportant that it's not even the 
default, that's all.

>> Why do you need to lock things to enforce transactional integrity? 
>> Locking is only one (suboptimal) way to solve the problem.
> 
> The RDBMS locks things to enforce transactional integrity. I don't do it 
> explicitly. I merely start a transaction, and the appropriate rows get 
> locked.

That's only one way of implementing transactional integrity. (And, IMO, 
not a very good way.)

> Whatever you do to enforce transactional integrity? It takes resources.

Now that at least is a valid statement.

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

Post a reply to this message

47642e2a$1@news.povray.org...
> It just worries me that the designers of this system fundamentally think 
> that transaction integrity is so unimportant that it's not even the 
> default, that's all.

It's not the default because it's not needed in many database applications. 
Frankly, it looks like you just discovered the word "database" yesterday, 
fell in love with a couple of buzzwords even though you still have strictly 
no idea about what a database it and how it works (this thread started about 
*** CSV files *** being used for testing your database). Sorry mate, but you 
can't spout utter nonsense about MySQL and Access being "toys" and be taken 
seriously after that. Get some experience first.

G.

Post a reply to this message

Orchid XP v7 wrote:
> Gail Shaw wrote:
> 
>> Tell, me. Did you do any research on mySQL before making these claims?
> 
> I heard that MySQL is this cool free database that's taking over the 
> world. The KNOPPIX CDs contain it, so I thought I'd sit down and have a 
> play.
> 
> I was expecting great things. Maybe too great. What I actually found is 
> that by default "commit" and "rollback" are no-op, and transaction 
> handling is an "optional feature" that you have to explicitly enable.
> 
> I decided that any database that considers something so fundamentally 
> important to be "optional" is obviously not a very serious effort. Then 
> I looked at the release notes and it says "yay! we now support unions", 
> and I'm like "my God - you're kidding, right?"
> 
> At that point, I lost interest.
> 
There is a difference between stating that a program can not do 
something and asking the p.o-t for their opinion and experience. In 
practice the result here is the same, mainly because there are a lot of 
friendly people here that have com to know you over the years. IRL your 
mileage may vary. One of the main differences IRL is that the former 
tends shuts down all communication, while the latter invites the other 
to participate in an exchange of ideas.

Post a reply to this message

Darren New wrote:
> 
> Damn you're dense. :-) 
> 

He does program in Haskell.

Post a reply to this message

Gilles Tran wrote:

> Frankly, it looks like you just discovered the word "database" yesterday, 
> fell in love with a couple of buzzwords even though you still have strictly 
> no idea about what a database it and how it works (this thread started about 
> *** CSV files *** being used for testing your database). 
> 
> 

You forgot reinventing the wheel.

He's writing a helpdesk!  That's IT 101.


If it's for fun, that's one thing.  If it's to meet a business need, 
then put in one that has been tested, debugged and gained a little 
maturity.  Your users will thank you, and the person who takes the job 
after you will be deligheted not to inherit a undocumented 
haskell/oracle monster.

Post a reply to this message

Orchid XP v7 wrote:
> Tom Galvin wrote:
> 
>>> I'm going to build [yet another] helpdesk application.
>>>
>>
>> Then mysql is more than adequate to the task.
> 
> I disagree.

Hmmm who should I listen to? Gail the professional DBA, who is flown all 
over the world for database technology conferences, with many years of 
experience, or Andrew?  Sorry mate.



> 
> I'll take a look. It's probably too complicated though. 
> 

Glad you are so openminded.

Here's another one that runs on Active Server Pages with an MS Access 
Database or MS SQL backend.

http://www.liberum.org/

It's been running at major companies for years with great reliability 
and users love it.  Some people even modified it to use mysql.

Post a reply to this message

Orchid XP v7 wrote:
> It just worries me that the designers of this system fundamentally think 
> that transaction integrity is so unimportant that it's not even the 
> default, that's all.

Know something? The default is also to commit after every statement on 
most DBs too. So? :-)

Yes, MySql *started out* tremendously simplified. But it's like you're 
complaining about how DOS looses disk clusters if you don't close the 
file properly, while evaluating XP.

> That's only one way of implementing transactional integrity. (And, IMO, 
> not a very good way.)

Actually, I think there are a number of ways to do it, depending on the 
table. You can even use explicit locks to enforce at least the I of ACID 
on the non-transactional tables.

>> Whatever you do to enforce transactional integrity? It takes resources.
> Now that at least is a valid statement.

Yah. In my experience, it's about a 5:1 ratio. When I realized that, I 
changed most of my tables to non-transactional. There's nothing I'm 
running on the tables that isn't idempotent.

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