1

I was wondering, when should a drupal developer use normal er table instead a new content type? Is it never? When expected node entries reaches 100 000? i googled it and i didn't find any good answer.

selecting from custom content type with number of fields is very time consuming, because all the join-s. If you have 5-10 content types, each with 10 fields, and expect a lot of nodes, is then the right time to forget about content type?

What are your experiences in this matter?

2 Answers 2

2

If you are using Drupal 7, instead of using plain custom tables, use a custom entity type, this is really easy to do with Entity API This gives you basic integration with Views and some other modules such as Rules 'out of the box', and customisation is very easy to handle.

I do not see entities having much overhead above a plain database table when the entities are not fieldable. I have worked on a site with millions of rows of data, which is all available as entities, and we load several thousand of them at a time when necessary, this does require a memory limit larger than 128MB, but I haven't seen memory usage go over 256MB while paginating a thousand or so entities at a time out of the possible millions. (Bear in mind though the entities are not fieldable, and we are using APC which does reduce memory usage.)

You can then also use the full power of entity_metadata_wrapper(), which is really awesome, and simplifies code.

Basicly, entities give you the benefits of a content type, without the overhead of revisions or comments. In fact, nodes are entities, so are taxonomy vocabularies and taxonomy terms.

It is definitely a best practice to use entity API to access entities as this allows all the proper hooks to be run, such as clearing the necessary data from entity cache. However, you are not forced to always use the Entity API to access the database entity rows, but do be aware that there are extra risks and gotcha's attached to this.

2
  • What did you mean with "the entities are not fieldable"? i have never used entity api.
    – gregab
    Jun 19, 2013 at 9:36
  • @gregab There is an array key which you can define in entity_crud_hook_entity_info() which dictates whether an entity is fieldable or not, ie. can have fields on it or not, in the same way content types have fields. There is more work you would have to do get the same functionality as content types (ie. creating bundles) and being able to add fields through a UI. Entity API makes it easy to do though, as most of it is already handled, and it has decent example code.
    – Phizes
    Jun 19, 2013 at 9:39
1

It's a judgement call, really. If you need nodes, go nodes. Hundreds of them on page with thousands hits a day can be pretty OK if your hosting company is willing to help you fine tune your database. joins are not so costly if query planner works at it's best, and most of your content should sit in Boost cache anyway, before you start to worry. Caching in RAM is also a good idea.

On the other hand, if you need to record set of data that's not exactly a content, go custom table. No need to have editable fields in a log, for example.

If you will go custom table for content, over months and years you'll be missing some stuff that's given for nodes. So you will implement workarounds, reinventing the wheel. And you risk ending up with something just as complicated as core nodes, but unsupported and not versatile.

4
  • Yes, i agree.. the answer is far straightforward. In my case i have around 15 entities and relationships between them. I am not sure what to do.
    – gregab
    Jun 19, 2013 at 8:23
  • Drupal is pretty good at this, actually. Seen worse. If you don't need nodes for your content, maybe you would do better with Symfony? But unless you hit any particular problem, use content for content ;)
    – Mołot
    Jun 19, 2013 at 8:25
  • What was your biggest (successfull) project with content types? In number of nodes, content types .. ?
    – gregab
    Jun 19, 2013 at 8:34
  • Not strictly mine, but I maintained um.warszawa.pl Around 250`000 nodes (you can see node ids in some of their html so it's not a secret). Some, like "information cards for citizens" was using dozens of fields (yea, you can see it pretty well too). Number of content types is one thing you cannot see there yourself, so let's just say they are not thrifty about it.
    – Mołot
    Jun 19, 2013 at 8:40

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.