[SOLVED] Why doesn't Drupal store Content Types in specific tables?
Hello!
I was just checking the Drupal database searching for some content types I've set up.
To my suprise, it was hard to find what I was looking for..=P
I don't understand why Drupal doesn't store all content types in specific tables, like so:
EXAMPLE 1:
- Content Type: Pictures
- Table name: node_type_pictures
- Table fields/content metadata: pic_id, pic_caption, pic_data...
EXAMPLE 1:
- Content Type: Articles
- Table name: node_type_articles
- Table fields/content metadata: artc_id, artc_name...
Wouldn't it be more flexible? A user could add a new content type easily through a form, without database knowledge
There could still be the node_type table which would contain the name of the content type, description, etc. - but all
content-specific fields would be stored in a custom content type table.
Or am I stupid?
CCK
At a guess the reason the data is spread out over mutltiple tables could be that:
Each content type needs to still have a unique node id, so you need all content types to at least put their basic details in the node table.
You also need all node revisions kept unique (regardless of content type), so they get a separate table.
If you're worried about exporting the data later the Views with Views Bonus Pack module allows you to export pretty much any data in Drupal into a .csv or excel file...
Do you know about the CCK module (Content Creation Kit)?
http://drupal.org/project/cck
It does exactly that!
No
No. It would be much less flexible. It would make tools like CCK and Views even more horrendously complex internally. And it would deliver zero value to the end user.
What you describe is how CCK works.
The reasons most Drupal content is stored in a single "node" table is simple: all nodes share the same fundamental data. Title, author, creation and modification data, publication status... These bits of information are common to all nodes regardless of their type. Fields that you add usign the CCK module -- ones the differ from one content type to another -- are stored in their own custom tables, just as you described. The common, shared fields are still in the general "node" table however.
Storing them in a single table also gives Drupal the flexibility to treat all content as one big "soup" of information when it's desired: a listing of the latest blog, news, event, and article content would be MUCH MUCH slower if it had to pull in data from three separate (but structurally identical) tables.
Eaton, with all do respect,
Eaton, with all do respect, that wasn't exactly what I described. My idea was that every field for every content type should be in a different table. CCK gives us the ability to add new fields - but the Title and Body fields are still present for any custom content type.
Although I must adming, after mixing around with the Drupal and learning the Core, I'm now starting to realize the power behind the whole concept. With the present approach, sharing CCK fields becomes very easy, among many other things..
So, Drupal wins ;-)