Dan McCullough wrote:
I've come into this discussion pretty late so please bear with me if I
go over something that has been ruled out.
You are trying to print out in a threaded method the first post in a
thread followed by each post after that, that is a child/reply to that
post. Is that correct?
So something like
Example 1
Thread1
Post1
Post2
Post3
Post4
.....
or
Example 2
Thread1
Post1
Post2 - reply to post 1
Post3 - reply to post 2
Post4 - reply to post 1
Post5 - reply to post 1
Post6 - reply to post 2
Post7 - reply to post 3
Not a valid example, because there is no guaruntee that the posts are in
order. In your example, the order could easily be:
Thread 1
Post 1
Post 6
Post 7
Post 2
Post 3
Post 4
Post 5
Since somebody can reply to any leaf in the tree at any time.
Example 1 is very common and is the easiest to implement. From what I
remember you would need a couple of DB tables for post, post_thread,
post_post, thread
So for your question thread isnt very relative but I thought I would
throw it in.
thread {
threadid int(11) auto_increment,
threadname
threadsort
...
thread_post {
threadid int(11)
postid int(11)
....
Tables that serve only to tie two other tables together are a waste. I
suggest you look up your normal forms again. But to sum up the
reasoning, there is no point to have thread_post because you can simply
have a "threadid" field in the "post" table, because it's a one-to-many
relationship. A post can't belong to more than one thread.
post {
postid int(11) auto_increment,
postname
posttext
...
post_post
postid int(11),
postid2 int(11)
....
Same thing, I think. A post can't have more than one parent, so you
might as well put the parent id into the post table. Unless you have one
"post_post" row for every parent that a post has. This spams the
database like nobody's business, but makes queries easier.
Please note I have two kids fighting over the cat, trying to cook
dinner and stave off a flood of water from the rising river so the SQL
structure is for example.
You can get everything in one query from the DB and lay it out based
on the id of the post, if you DB is properly indexed and setup and
queries are optimized you'll hardly notice a blip when the load gets
up. You do not want to be doing multiple queries on a page when one
well written query will do the trick.
I'm not seeing it. Unless you have a many to many relationship on
post_post, you're going to need multiple queries. Unless I'm missing
some SQL syntax that allows references to previously found rows. It's
been a long while since I did advanced SQL queries.
I think your example relies on getting everything in one query by
getting all posts with the same threadid, and then sorting by ID, but
the problem is that we don't want to sort posts by ID, since a higher ID
might could easily go before a post with a lower ID based on where
people replied.
Regards, Adam.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
