Re: sparse components

On 1 June 2010 17:19, Mat Noguchi <[email protected]> wrote:

>  I think that was my quote! (:
>
>
>
> Anyways, one reason why you’re probably finding inspiration in older tech
> (SQL) is that back then the SQL optimizations were quite hardcore, dealing
> with insanely slow external storage and limited memory. (Just like slow main
> memory and limited caches.)
>
Oh, yes, so very yes. This is something I only noticed after I'd been
hacking at data oriented development for a while, and it gave me hope that I
was on the right track with what I was realising. I've still got a general
problem with appreciating joins on tables. I haven't been able to look at
them without getting scared of the N*M problem, but think that most of the
joins I would have done in the past on database queries are now sequences of
selections with decision tables built from previous selections. At least
that way I get to sleep at night ;)

I'm wondering if the old convoluted queries we had to do for uni' were a
result of business logic, and need to test our skills. I'm hoping that I'll
find out one way or the other when I get around to the more complex
combinations of data (I'm guess that will be when I get to the monster AI in
the roguelike).

Other potentially hazardous queries, such as selecting ranges of values,
struck me as quite hard to make fast. That was until I had a brain bulb go
off. I've now come to the conclusion that they are eminently simple to
optimise with techniques varying on a case by case basis but usually being
some combination of indexing and cached sets. I've got a whole section of my
work devoted just to optimisations on selecting values from tables.

-- 
fabs();
Just because the world is full of people that think just like you, doesn't
mean the other ones can't be right.

_______________________________________________
Sweng-Gamedev mailing list
[email protected]
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com