By DrupalNovice on

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?

Comments

jon nunan’s picture

jon nunan commented

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...

A user could add a new content type easily through a form, without database knowledge

Do you know about the CCK module (Content Creation Kit)?
http://drupal.org/project/cck
It does exactly that!

yelvington’s picture

yelvington commented

Wouldn't it be more flexible? A user could add a new content type easily through a form, without database knowledge

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.

jpederson’s picture

jpederson commented

Too much clutter and complexity, no end user benefit. Oops, they built this into core, didn't they? lol...

eaton’s picture

eaton commented

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 — Partner at Autogram

DrupalNovice’s picture

DrupalNovice commented

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 ;-)

radhakrishnama’s picture

radhakrishnama commented

hi ,
can any one explain me .
how drupal stores the content in content_type tables and content_field tables? in details and can i know difference between them.!!

praveenmr1979’s picture

praveenmr1979 commented

In Drupal 7, the entity_id is the foreign key for all tables which can be join with node.nid. If we have installed views and enable the query disply, we can identify the relation b/w different content field tables with node table.

grzesag’s picture

grzesag commented

Hi

I am working on the D6 website and trying to understand the logic behind these to tables: content_type_{type} and content_field_{field_type} and cannot find any explanaiton how and when they are used to store content type data.

It looks that for some content types all fields are in the content_type_CONTENT_TYPE but for some stored in content_field_FIELD_NAME.

Did you find answer to this problem? Apart from this everything else how content for nodes is handle seems good.

Thanks

dman’s picture

dman commented

Unfortunately, CCK in D6 went through some growing pains.

When you first make a content type, that includes SIMPLE fields, those got added as columns directly to the content_type_CONTENT_TYPE and that was sort of OK.
However, if you then decided to reuse a field, or make it multi-valued, CCK would rewrite its own schema on the fly and suddenly what used to be a column in the home table became a whole new table with a lookup to join back to the base table! Which ended up being not much more than a placeholder for the revision ID.
This certainly can be mindbending. And created nasty surprises for anyone who thought they could poke directly at the database without using the API.

One day you have:

table content_type_CONTENT_TYPE_A
| nid | vid | simple_field_value |

Then, next week you add CONTENT_TYPE_B, and add the same sort of field to it, and now suddenly you have:

table content_type_CONTENT_TYPE_A
| nid | vid |

table content_type_CONTENT_TYPE_B
| nid | vid |

table content_field_SIMPLE_FIELD
| nid | vid | simple_field_value |

This happened to me recently in some old code I have to support.

I'm imagining that for historical reasons, and to placate the non-relational-database-thinkers like the OP, and possibly for performance - all fields did start off just as columns in the home table like the OP expects. The 'multiple' support architecture and support for re-use was tagged on afterwards, and so only used that extra schema when it was determined to be absolutely necessary. But supporting both methods led to a hybrid situation that only really made sense if you learned the API calls to use - and did NOT try to look directly at the database.

With the benefit of hindsight, each of D7s fields start by always assuming they may be revisioned, may be multiple, and may be multilingual, and are always in a joined table of their own from the start.

.dan. is the New Zealand Drupal Developer working on Government Web Standards

grzesag’s picture

grzesag commented

Hi

thanks for your time - this is how I did understand this but wanted to confirm with someone else.