2

I am creating a content type in Drupal - a content management system for our business rules. This content type will ultimately contain about 40 fields. I notice that for each field I create for the content, Drupal creates a table in MySQL.

It sounds like when I go to query the content in MySQL from a remote system using, say, JDBC, will I need to create a query joining 40 or so tables?

Does that sound right? Can I be doing something wrong? I cannot believe that a query, even with adequate indexes in place, would be performant when 40 tables are joined together.

Improve this question
3
  • I'm not sure I understand what you are asking. Yes, if you have 40 fields, by default you will get 40 tables, and 40 joins.
    – Letharion
    Commented Apr 8, 2012 at 22:00
  • I am asking if this is normal and standard to have this many fields? That seems like a lot of tables to join - especially since those fields that are not required will need to be left outer-joined
    – Jerry
    Commented Apr 8, 2012 at 22:42
  • 1
    First : Drupal Version 6 or 7 ? Second : 40 fields created as plain text fields or select fields ? All text fields will be in parent table i.e content type table , if fields are select drop downs then only it will create seperate tables for each fields in CCK
    – GoodSp33d
    Commented Apr 9, 2012 at 9:50

1 Answer 1

Reset to default
2

40 fields on a single content type sounds a lot to me, although I'm aware of sites with a great deal more.

  1. The very first thing you probably want to to, is use Entity Cache which should significantly reduce the query complexity for you, though honestly I haven't examined the module in detail.

  2. Aggresively cache higher up the chain as well. Varnish, Page manager and Cache actions are all your friends here.

  3. Is it possible for you to meaningfully break down the content type into pieces? If you can identify parts of the content type that will not always be necessary, use a Relation to a second content type. At the price of two optional extra joins, you can potentially skip a lot of them.

  4. Still no luck? Define your own content type where all your data columns are properties instead of fields. This will store all data in the same table, at the cost of flexibility. It's probably also possible to make field api do the same thing with fields, but I have never even considered how to do that.

Improve this answer
2
  • Thanks for the great details. Since I'll be querying these tables from JDBC, won't I not be able to take advantage of caching?
    – Jerry
    Commented Apr 9, 2012 at 11:15
  • You are right that directly interfacing with the DB will at the very least make caching more complicated. I just tried to give a general answer. However, nothing prevents you from looking at how entity cache retrieves cached data and perform the same query. You could also make the external request with Services instead of JDBC.
    – Letharion
    Commented Apr 9, 2012 at 11:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.