Jonathan Van Matre on 19 Feb 2002 14:36:31 -0000 |
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
RE: spoon-discuss: So, what should I be doing? |
While we're on the subject of improvements, I'm curious about how you've structured the database. Being a DBA by day, I might be able to offer some suggestions in that area, both to improve performance, and possibly add a handy way to enable the intra-page links. Can you dump CREATE TABLE scripts for the tables and send them my way? If you're really feeling the Copious Free Time, a TOP 10 * result set from each table would be handy as well. --Scoff! > -----Original Message----- > From: David E. Smith [mailto:dave@xxxxxxxxxxxxxxx] > Sent: Monday, February 18, 2002 11:55 PM > To: spoon-discuss@xxxxxxxxx > Subject: Re: spoon-discuss: So, what should I be doing? > > > On Sun, 17 Feb 2002, Donald Whytock wrote: > > > Were I to be greedy... > > Indeed. ;) > > > I'd want more intrapage links, so that if r123 references r234, the > > reference to r234 would be a link to r234, so that I can > flip back and > > forth between the two rules. > > I'd want something like that too, actually. :-) > > I'm a bit short for good ideas on how to implement it, though. > > There are two really obvious ideas: > > * Go through the whole ruleset and edit everything by hand. I > don't really > want to do that, because the ruleset is up to about 40 pages. (Yeah, I > printed it out.) > > * Find a way to do it at runtime. Really tricky... It's hard > for software > to distinguish between "Rule 100" and "starts with 100 points" in any > meaningful way. > > If you're just looking for meaningful groupings of rules, just suggest > more keywords. Since I now have the authority to add Keywords to the > database more-or-less at my discretion, and since it's really > really easy > to do, that may have to suffice as a stopgap. > > > Maybe an alphabetized rule name index at the beginning of > the rule list. > > That would be relatively easy to do... I'll try to bang one out. > > > Definitely a place for Limbo above or below the Grid, > because, thanks > > to football, things being in (1,1) may become an issue. > > Definitely in the queue. > > I may end up re-doing the whole Grid system again at some point. The > system I've got now is fairly good for most things that occur > infrequently, but moving those Gremlins around for GremBall > is frankly a > pain in the ass. > > > BTW, a thought about the database...Do you store the actual text of > > objects in the database, or is that stored in files that are > > referenced by the database? Which do you think would be less of a > > resource drain: hauling lots of text out of the database, or opening > > several text files in succession? > > The rules are stored in one big database table. > > Though I haven't formally benchmarked anything like this, I > imagine the > "lots of text files" would be more draining. PHP and MySQL > offer lots of > stuff to make database use reasonably efficient - persistent > connections, > a fair amount of internal caching, etc. And there's the less-tangible > benefit of the fact that everything is already IN the database. > > Rules, proposals, and CFJs are all stored in one big table > that has the > object number and revision number, object type, title, text, > other stuff > (nweek of origin, "owner" for proposals, and so on). Since > every revision > of every object is stored as a separate row, there's a total > of 557 items > already in there. > > If you want to look at the current rules, you can either: > * Make a couple quick queries and iterate through the result set > or > * Open up several hundred text files and start parsing like a madman. > (There's 217 items in the database with type "rule", but that > includes all > previous revisions of rules. I'm too tired to count up all the current > revisions right now.) > > The database also has tables for players, the grid, dimensions, and > keywords. Most of those are fairly self-explanatory. > > ..dave > > >