I have been using phpbb, and noticed some of the way phpbb handle posts, which is different from drupal handle node.
I appologize if anybody feel offended by my comparing them. I know Drupal is a great project, that's why I am here. And I am pretty new to Drupal, please feel free to correct me if I am wrong.
All post in phpBB has fields like id, poster (author), last updated, visit counts, etc. as well as subject (title) and post text. phpBB store the regular int or char fields in one table, and the subject and post contents (both are text) in another table. I am wondering if this is because this makes the post table smaller (not much text, most fields are int or char or varchar), and thus faster for regular query for display the list/index etc. It also has topic table which has subject but no content text.
As node is the fundamental type here, it has title, teaser and content, which probably every new type that inherits from it will have to carry, because Drupal is for content management. This is the best choice for content management. But it will become less efficient if it is used for management of items like contacts, directory, etc, which does not have much text content, but many different tiny or small fields.
As it is currently with Drupal, I don't see case where we are creating a node directly, mostly we are creating a story, a static page, or a book page, or other type of node. Thus, it sounds to me it might be faster to query the node table if we move the teaser and body content from node to it's child type, such as story, page, etc. I am not sure how much this will affect the query of node table. Anybody knows database please correct me if I am wrong. But the fact is that node table is the one been queried the most. A smaller node table should make all the queries on node table easier and faster.
Since we already have story and page as basic node type, and then we can move most of the display from node to it's child type. And the initial page will then just list the title of each node.
Since most query will now have to be execurted against at least two tables (node and it's child type table), I am not sure how this will offset what we gained by decrease the number of fields and size of the node table.
Or, if it's still true that all child type of node will have teaser and body content, it might still gain to split the basic field (nid, title, uid, last updated, visit count etc) and the text part (teaser and body) into two tables, this way the regular node listing will still be faster, provided that we are satisfied with a listing with only title, author etc, no teaser and content. Or, the teaser can be restricted to be smaller and thus put back to the node table. This will still be better in situation where the user might post really long pages. Or this does not matter for mysql? Can somebody clarify?
Thank you for taking your time read this.
Comments
Node system
As node is the fundamental type here, it has title, teaser and content, which probably every new type that inherits from it will have to carry, because Drupal is for content management. This is the best choice for content management. But it will become less efficient if it is used for management of items like contacts, directory, etc, which does not have much text content, but many different tiny or small fields.
You don't have to use the node system; only use it when it makes sense to.
Whether it becomes less efficient remains to be seen, IMO.
node system
To not use node system, sounds to me like not to use drupal.
I will have to use node system if I want to use drupal. Because node is the basic and every other module or type is based on node. Since story and page is based on node and has teaser and body, and so are book pages, etc. That's why we have node with teaser and body, but then all other types, regardless of what it is, will have to have teaser and body, though we might just leave it out.
But keep the body separate from the main node table will definitely make the system more scalable.
I don't believe you
But keep the body separate from the main node table will definitely make the system more scalable.
I don't believe you. I think we'll need more SQL queries to generate a page. You'll have to backup your statement and prove it. :)
I am not an database expert
So, I base on my general knowledge about it, if the table has huge text field, we should avoid querying that table if possible. Maybe somebody has more database knowledge can comment on this. I will check more resource on this.
We definitely need more SQL queries if we want to generate a page. But the frequencies that a overview page is generated should be by far more often than a node page. At least this is true for me. It depends on how many people click from the node list page to the actual node page. For book page, or for news management, the default layout, which shows author, submit time, the teaser, is very informative. I would not expect a 5% or more ratio of click from the node list page to the actual node page, especially considering a page like drupal.org, you may have 100 more links on the cover page (most likely the node overview page) other than the node list items. So, that ratio would be even smaller. Everybody who click on your homepage would make a query into the node table.
With the body contents in node table, every click on homepage will query in the node table which has huge body text, while if we separate the body from node, then we query the body table only when people actually click to view a node.
When to put the teaser into the node table or separate it into body table, depends on how the node will be listed most often. If node is listed only with title on the node list page, then the easer should go to the body table. However, if a site has static story or news only, then store teaser with node table is not a bad idea.
Of course, the core drupal design will have to balance between customer who list node with only title and customer who list node with teaser all the time.
query on nid, uid etc field
Also, there are many situations that you query the node table for only the node id, author, and last created, or visit count etc, without the title, teaser and body, with a node table that only has some fixed length field, it will be much faster. It maybe difficult to implement it as fixed length row because we probably still want to keep the title field. But in most situation it will still improve the performance if we separate the teaser and body.
a node class
Having seen the theme class, and various node type that implemented by the Drupal core (story and page) and all kinds of customized type, such as weblink, organization information, and the book page, forum, commence (I think all these are based on node type, correct me if I am wrong), I am wondering if there has been discussion on considering a node class, because we are all trying to implement some kind of "child class" of node in some hard way.
If we define a node class, with some basic implementation, including display it under list mode, page view mode, etc, and allow child class to either overwrite or extend these, it will be easier to develop new module that intends to add new type, which will greatly increase the possible applications and ease the customization of Drupal.