l i n u x - u s e r s - g r o u p - o f - d a v i s
L U G O D
 
Next Meeting:
July 21: Defensive computing: Information security for individuals
Next Installfest:
TBD
Latest News:
Jul. 4: July, August and September: Security, Photography and Programming for Kids
Page last updated:
2003 Apr 24 16:43

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] Unnecessary RDBMS features [was Need your help in recovering database.]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] Unnecessary RDBMS features [was Need your help in recovering database.]




"Micah J. Cowan" wrote:

> On Thu, Apr 24, 2003 at 08:28:48AM -0700, Tim Riley wrote:
> > Soumyadeep:
> >
> > I'm affraid the InnoDB addition to Mysql
> > is over my head. After viewing the InnoDB.com
> > site referenced below, it's clear that this addition
> > provides the commit/rollback transaction processing
> > features that I believe helps make Oracle bloated.
>
> Are you actually saying you believe commit/rollback is a *bad* thing?

Yea--it's not worth its weight.

>
> If so, you are definitely the first person I've ever heard say that...
>
> I'm not criticizing your opinion; I'm just trying to understand.

Commit/rollback requires that a copy be made of each datum involved
in an insert, update, or delete statement. This is very expensive. But
why make the copy? I know my insert, update, or delete is the correct
thing to do at the time. If I'm making a mistake to the database,
I'll fix it when I catch it.

This feature is really a pain with large load processes. Before I learned
how to place "commit" statements
every 100 or so rows, the CPU would dog  making all those copies,
and sometimes I would run out of rollback segment (the copy place) space.

I think the intention of the commit/rollback feature is to undo all the
changes if an insert depletes the last available disk space. This is a
thoughtful
idea; however, because a unique index insures table integrity, after
allocating more space, I can easily restart the load from the beginning
with confidence.

> I
> agree with you that feature creep causes major bloat, which in turn
> causes huge opportunities for bloat.

If you want to expand on this more, there are other areas of Oracle-like
DBMS features that cause unnecessary bloating and headaches.

> But when you have such an
> important feature for guaranteeing data reliability,

I'm curious to learn what you consider data reliability to be
and how commit/rollback guarantees it.

> I would
> definitely consider it worth the slight risk the added code
> introduces.
>
> One reason I avoided using mysql for so long was specifically because
> it lacked commit/rollback functionality.
>
> -Micah
> _______________________________________________
> vox-tech mailing list
> vox-tech@lists.lugod.org
> http://lists.lugod.org/mailman/listinfo/vox-tech

_______________________________________________
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech



LinkedIn
LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
facebook
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
Appahost Applications
For a significant contribution towards our projector, and a generous donation to allow us to continue meeting at the Davis Library.