Mailing List Archive

New database scheme
Since Lee added a namespace field, I think now is the time to
brainstorm and see if any other changes to the database scheme are
needed or desirable.

First, I think the cur_namespace should be indexed, since we are using
it for finding articles. Should old also get a an old_namespace, or do
you intend to store the namespace as part of the title? Also, I was
wondering about the cur_title/cur_ind_title situation. Would it be
possible to declare cur_title not as binary and combine the two?
Should we store the passwords in user in encrypted form? (Right now,
any sysop with mysql access can read all passwords.) Maybe we
should store the user_rights as a bitstring?

The tables linked, unlinked and ipblocks should have PACK_KEYS=1
(makes reads faster and updates slower). Any other possible fields for
site_stats? Maybe a date field?

Axel
Re: New database scheme [ In reply to ]
On mar, 2002-05-21 at 23:19, Axel Boldt wrote:
> Since Lee added a namespace field, I think now is the time to
> brainstorm and see if any other changes to the database scheme are
> needed or desirable.
>
> First, I think the cur_namespace should be indexed, since we are using
> it for finding articles. Should old also get a an old_namespace, or do
> you intend to store the namespace as part of the title?

I don't think we need a separate namespace field in old.

> Also, I was
> wondering about the cur_title/cur_ind_title situation. Would it be
> possible to declare cur_title not as binary and combine the two?

IIRC cur_ind_title contains spaces where cur_title contains underscores,
so that words in the title are treated as separate words for searching.

They could potentially be merged by taking the underscores out of
cur_title and doing s/_/ / magic instead of s/ /_/... but that leaves
the question of getting around limitations in MySQL's search indexing.
I'll have to grab version 4 and see what can be done as far as case
folding, accent matching etc; otherwise we may still end up wanting
separate real-content and search-index fields both for titles and
article text.

> Should we store the passwords in user in encrypted form? (Right now,
> any sysop with mysql access can read all passwords.)

Yes, that's been discussed and I think we agreed to do it, it just
hasn't gotten done yet. Since this would require an update script to be
run to make it work, we may as well stick it in with whatever other
database changes we may be making...

> Maybe we should store the user_rights as a bitstring?
>
> The tables linked, unlinked and ipblocks should have PACK_KEYS=1
> (makes reads faster and updates slower). Any other possible fields for
> site_stats? Maybe a date field?

I assume the point of the site_stats table is so that writing updates to
the page view figures etc can't block access to the cur table?

-- brion vibber (brion @ pobox.com)