Re: spoon-discuss: So, what should I be doing?

["Donald Whytock" <dwhytock@xxxxxxxxxxxxx>]

On 2/19/02 at 5:54 AM David E. Smith wrote:

>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.

Hmm...special delimiters around items that would serve as links, such as "Rule 100", that could be translated at runtime into either same-page anchors or parameterized CGI calls, depending on the type of query done...?  The rule texts would still need to be edited by hand, but that should be significantly less editing...perhaps something like "~Rule 100~r100~" to indicate that the text "Rule 100" should be made into a link to r100, whether r100 is on the same page or not.

>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.

Is the Grid generated automatically?  It could be...using (x,y) coordinates, with y indicating which <tr> and x indicating which <td>.  That way you never have to change the Grid itself...just the coordinates stored with the object.

>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.)

Understood.  What I was thinking was that if hauling a lot of text through interprocess communications was bogging the database server down, the text itself doesn't have to be in the database.  Instead of a big block of text in a field, just have the name of a file, so that, as records are retrieved from the database, files are opened at the same time and the text streamed through.  Should get smaller, tighter database tables that way.  Granted, it'd make text searches a pain, but you're not doing those right now anyway, and if you did you could spawn a grep command.  And it seems like it'd be easier to call up a text file with vi than to modify a database record.

But then, I'm not that familiar with how blobs got implemented.  Maybe they store text separate from the main, hard-limit-field data anyway.

						Glotmorf