On Wed, 18 Apr 2001, ryc wrote:

> The subject field is a bit more tricky. You COULD change it to
> Char(255) but that would waste a lot of space seeing that most
> subjects are a lot shorter. You can move the subject into the table
> that holds the varchar bodies. This wont hurt anything because that
> table already has varaible length rows from the body column, adding
> the subject wont hurt.

Well, I was wondering if there is a point in putting the SUBJECT field in
a separate table, when every query that I would execute needs to retrieve
the SUBJECT field anyway...

> > Also, is it a good idea to make a field called size and use that instead
> > of calling length(message) (message is MEDIUMTEXT) when I don't need to
> > retrieve message, or does MySQL have length(message) cached?
>
> Yes definitly. Although it is tempting to calculate the length/count/other
> stats on the fly using database functions, it is not scalable.

Okay, I'll do that. The messages don't change once they're posted so it's
easy to keep another field indicating the size.

> Instead of splitting it into lines based on a newline, you can do a
> global replace using \n as an anchor. Something like: search for "\n>"
> and replace with "\n$colorcolor>".

It's not quite that simple; the color changes depending on how many >'s
there are. My current algorithm counts the (number of >'s + 1) % 6 at the
beginning of the line to decide what color to use.

If this were C, I could probably do this efficiently using character
pointers. Come to think of it, when I split the message into a list, that
causes two copies of the message to be held in memory: the unsplit
version, and the split version. Maybe that's what's slowing it down. I
can't think of doing it any other way though.

> thinking scalability you might want to do this conversion once, and store
> the results in the database. So you dont have to worry about parsing it into
> lines once you retrieve it from the db, you can just spit it out because it
> already has the color info in it.

I might do that once I get my system better developed. Most pages never
change once they've been created, and the ones that do change (e.g. when a
message gets replied to, its page needs to link to the new reply) can be
found and updated relatively simply. So I could just write out a lot of
this stuff to static HTML pages for the ultimate performance boost.

-Philip Mak ([EMAIL PROTECTED])






---------------------------------------------------------------------
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/           (the list archive)

To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php

Reply via email to