Custom Thread Fields >> Custom Tables?

[ZiNgA BuRgA]

(04-14-2011 02:00 AM)RateU Wrote:  I really really don't know what magic has been done with this table
When I try to create my own table, I never succeed to make it optimized like that table

I don't really see how.  There's nothing particularly special, just a table that is usually joined with the threads table...

(04-14-2011 06:08 AM)Firefox Wins Wrote:  If (for example) someone was asking a question about planning to code a custom CMS and they said "...the events are stored in `cms_events` table and downloads are stored in `cms_downloads` table."

Oh okay, I see where you're comming from now.

Yes, it's "better" to have separate tables as it means less redundancy (XThreads will have heaps of blank cells with different applications) and it models the data more closely, as well as provide more flexibility.  It's basically what separate tables are for.
On the other hand, XThreads does not have a predefined data model (for threadfield data).  It relies on the user to provide the structure.  This already erodes some of the advantages of a dedicated data model.
There are quite a number of other problems XThreads needs to respond to that your CMS example doesn't need to worry about.  For example, it will never be possible to move an event into a download, but for XThreads, it's certainly possible for a moderator to move a thread from the events forum to the downloads forum.  Probably the biggest issue of separate tables is pulling threadfield data on the search/portal page - since this could be pulling data from all forums at once, you're going to end up with a very ugly long series of joins.
These problems can probably be worked around, but probably require significant redesign in some parts.  It would probably need to introduce the idea of "forum groups" and you assign each forum to a group (which maps to a table).  Alternatively, one may just create a separate table for each forum, but that itself may be considered fairly redundant.  The advantages of this would be natural partitioning (rather than explicitly using MySQL table partitioning) and fewer redundant data, but the problem would be very ugly handling of search, and much more complicated, and sometimes problematic, handling routines overall (eg handle cases when admin decides to assign the forum to a different group -> shift data over the place; move thread = shuffle data around different tables (also potentially causing data loss); delete a bunch of threads = you've got to track which forum they're from and which tables to delete from etc).

Only real disadvantages with keeping it all in one table is the amount of redundant empty cells, and perhaps semantics, if that really matters to you.  IMO, storage is relatively cheap these days and blank cells take up very little space anyway, so this disadvantage really isn't significant.

XThreads will never be able to match the speed and flexibility of a well written dedicated script, but it can come very close (ie negligible difference) in a number of circumstances (and in fact, be better in others).  That's the price you pay for flexibility really.
However, the pretense is that we're comparing against a well written script.  Most, for MyBB, I've seen aren't, so XThreads will probably be better than them anyway.