On Sat, Nov 16, 2002 at 01:28:31AM -0800, Brion Vibber wrote:
5) Why is a
broken link table necessary? Couldn't it be sufficient to
do a query to find out which links are broken? Or is this another "we
have no subqueries" issue?
I believe the primary use of the brokenlinks table is for generating the
'most wanted' list.
All articles have ID numbers; that's cur_id in the cur table. bl_from
and l_to reference cur_id numbers. Articles that don't exist don't have
cur_id numbers of course, so cannot be referenced by id, but only by
title.
What if there were no "broken links", only articles that had no text?
ie, the text field would be NULL? And we could do with a single "links"
table by collapsing article and image links together. And one could
find the "dangling links" simply by searching for those articles with
the text property set to NULL. The following query would do the trick:
SELECT * from cur where cur_text = NULL;
The current solution is more or less like that for the
articles tables.
There's 'image' ~= 'cur' and 'oldimage' ~= 'old'.
Uploading a file with
the same name as an existing one is considered creating a new revision
of the same file; the old one is pushed back into the old list, and the
new one put in the current place.
Hm. Maybe images could be collapsed into the "cur" table too.
The primary use of the links table is to generate the
'Whatlinkshere'
listing. No subqueries, and we need the titles to list the links, not
the id numbers.
I think we could reduce to the following tables:
current_articles, previous_articles, deleted_articles, links
We just add a "type" field to the articles tables to indicate "wiki
text" or "image"; this gives us flexibility to support other types of
object too.
Stores ~1000 randomly selected page names. When someone
clicks 'Random
page', one of those is selected rather than one of the whole bunch;
every once in a while the list is regenerated. Allegedly this improves
performance.
That makes sense, and it very well may improve performance.
18) What is
ss_row_id and ss_good_articles? How does this table work?
Does it contain stats for each article? Shouldn't that go in the table
that already contains the info for an article? That would lessen the
number of SQL updates, collapsing two UPDATE statements into one.
This contains a single row for the whole database. The good articles
count is generated by faulty math anyway, though.
What is a "good article"? What uses that table? What would happen if
it went away?
No. user_rights is a comma-separated list of
priveledges. Currently the
only ones defined are 'sysop' and 'developer', so possible values are:
'' (normal users)
'sysop' ("sysops" or "administrators")
'sysop,developer' ("developers")
Ah. Oddly enough, I would recommend splitting that out into two tables,
each containing just user ids; one called "developers", and the other
"sysops".
The newpassword feature sounds nifty. I like it.
Jonathan
--
Geek House Productions, Ltd.
Providing Unix & Internet Contracting and Consulting,
QA Testing, Technical Documentation, Systems Design & Implementation,
General Programming, E-commerce, Web & Mail Services since 1998
Phone: 604-435-1205
Email: djw(a)reactor-core.org
Webpage:
http://reactor-core.org
Address: 2459 E 41st Ave, Vancouver, BC V5R2W2