|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v7 wrote:
> Well, last I checked, MySQL is a "toy database" on a par with Access.
As I said, your info is out of date. You're about four major releases
behind. Now they have distributed clusters and everything. Kind of
"start simple and work up to something worth using."
It still has annoying features, but "toy" it isn't.
--
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 wrote:
> once, you need transactions or you'll end up with a data integrity
> nightmare.
>
> (In this instance, it also needs to be possible to back up the database
> without shuting it down. And to recover if there's a crash. And all
> those other kinds of things.)
Damn you're dense. :-) Really. MySql does all that sort of stuff.
Indeed, I have a process that monitors the hot spare every 30 seconds
and tells me if it gets more than 60 seconds behind the live master. My
read-only heavy queries run against the hot spare instead of the live
read/write database. I'm doing financial transactions that need to audit.
Really. Your information is at least 5 years out of date. You're
complaining that you just wish Windows supported true multitasking.
--
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 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
|
|
| |
| |
|
|
|
|
| |