Re: Database development
Zlatko Duric wrote:
But there is some information about all those objects I'd like to
store in a single table or maybe two of them, that'd be super-fast to
reach, without having to look for all those
parent/children/node/parameters/other links ...
Lew wrote:
Zlatko Duric wrote:
Well, I don't mean to change the model.
I want to keep and use all this stuff that's already in there.
But there are few things I think can benefit from an approach like this:
- reports
there are a few "reports" being produced from the system. For some
10000 objects, there are 200k mysql queries - I am not much into big
systems (yet) but this seems waaaaaaaaaaay too much to me. If I had the
data from this in an additional table (I know this means duplicating
some data), I could filter out what I need in one single query.
You can do that with views or join queries without duplicating the data.
- lists
when accessing the data, users only fetch a certain small amount of
objects - 15, 20, maybe 100 at a time. So to avoid most of the node
links and stuff, I could get a quick filter of the data needed, without
having to join this and that.
What do you mean by "most of the node links and stuff"?
Duplicated data will require more accesses, code complication and risk than
"to join this and that".
Now, I know there are some disadvantages too, like having to worry
whether I update the object and the table at the same time or so.
I also have to make sure that all the data is in sync, since it's now
duplicated. But I still can't resist wondering if this would be a good
option.
No.
Luckily I still have a couple of months work already planned, so I get
to think about it :P
Time isn't necessary, correct thinking is.
--
Lew