I know it has been a while since this was brought up, but I have
thought about it a lot since then, and I had one more question about
this:
My wiki uses pagelists extensively--in fact every page has a
complicated pagelist as a "group footer" that lists related pages and
generates maps. Since I always have the pages searched by group, it
seems like in this case it might still make sense to create separate
tables for each group because for every direct page request, every
page in the database will be read. With separate tables for different
groups you would only have to pull up the tables in the groups you are
searching in.
This seemed to make sense to me, and I just wanted to have someone who
knows databases and/or the sqlite recipe confirm or refute my
hypothesis.
Thanks,
Alex
On Aug 6, 2012, at 11:17 PM, Petko Yotov wrote:
Alex Eftimiades writes:
I just got the sqlite recipe working with all the pages switched
over to the database, and after looking at the database structure,
I thought it was odd that it did not use separate tables for
different groups. I would think this would cut down on the time it
takes to access pages, but I could be wrong.
Yes, having all pages in a single table cuts down the time it takes
to access a table and a page in the table.
I do not know very much about databases in general.
Generally (and in this case too) when records (here: wikipages) have
the same structure, they are better to be in the same table, not in
different tables.
I was just wondering whether this was worth working on.
Probably not, if you want to optimize the recipe.
Probably yes, if you want to learn about managing SQLite databases
with PHP.
Petko
_______________________________________________
pmwiki-users mailing list
[email protected]
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
_______________________________________________
pmwiki-users mailing list
[email protected]
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
