[Leaplist] coding - rdbms, revisions, and fks

[Kevin Korb]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I mostly agree with you.  However, there are times when the efficiency
improvement is not worth the effort.  This is the standard cost vs rewards
analysis.

If you can design efficiently (and securely) from the ground up then
wonderful.  If you find a way to make something more efficient after the
fact that might simply not be worth the time it takes to do the work.
When things grow and the balance shifts that can easily change.

My favorite example (which unfortunately most people haven't experienced)
is Gentoo's portage system.  It is all written in python and it uses
sqlite as a caching system to accelerate processing the dependency data
stored in the (currently 26289) ebuild files.  Over the years many people
have suggested rewriting the python code in C or [insert compiled language
here] to make the portage system faster.  Of course going from python to C
would make portage faster but since portage is simply an organized system
for running configure and make with scripted options there really isn't
much point.  Even if an ebuild could be sped up from 5 seconds to .5
seconds that just doesn't matter since the ebuild launches a make which
takes 30 minutes.  It certainly isn't worth rewriting the entire system.
Of course some day things may change to the point that running several
hundred gcc compiles is faster than running a python script.  If that ever
happens then there will be real benefit in rewriting portage.

On Fri, 4 Dec 2009 21:04:58 -0500
Phil Barnett <philb at philb.us> wrote:
> On Fri, Dec 4, 2009 at 1:52 AM, John Simpson <jms1 at jms1.net> wrote:
> 
> > On 2009-12-03, at 2241, Phil Barnett wrote:
> > >
> > > You can certainly do this, but it's wasteful.
> > >
> > > All you really need in the history is:
> > >
> > > 1. Original records that generated the mailing that don't change. If
> > > you need to edit them, save a new different copy with a new
> > > differnent id.
> > Link
> > > the two records together so you know they are cousins.
> > >
> > > 2. History tables with dates and pointers to the original records.
> > >
> > > This consumes less space.
> > >
> > > Duplicating data that is already in the system is wasteful if you can
> > refer
> > > to an original copy of it.
> >
> >
> > one, disk space is cheap these days.
> >
> 
> Bah, Bad thinking. This is where things go wrong all the time where I
> work. Wasting 40% space is obviously no big deal on a 200M table. Then
> you get into a place like Disney and you wasted 40% of 1T. And then you
> have to rethink and redesign something that could easily have been right
> from the beginning.
> 
> Bad thinking. Efficiency doesn't come from throwing more hardware at a
> problem, efficiency comes from the mind.
> 
> 
> >
> > in the code which actually does a mailing... i'm sure your existing
> > SELECT query to get the address data for doing a mailing is complex
> > enough as it is, so here's a way which is easier to implement and will
> > probably run faster than trying to force the SQL server to only return
> > those records which have the highest rev for that aid value...
> >
> > Yeah, like marking the old records inactive when they get cloned
> > forward.
> 


- -- 
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~
	Kevin Korb			Phone:    (407) 252-6853
	Systems Administrator		Internet:
	FutureQuest, Inc.		Kevin at FutureQuest.net  (work)
	Orlando, Florida		kmk at sanitarium.net (personal)
	Web page:			http://www.sanitarium.net/
	PGP public key available on web site.
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAksZw0cACgkQVKC1jlbQAQe5bgCgvVSwnqIiEjV06mR4Ls1RxBee
ml8AoNHfhT4AnDOy0IZMqSwApKCKGCEl
=lmQC
-----END PGP SIGNATURE-----

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.