By leeuwnhawk on

Now, my application currently has more than 600 tables in the database, owing to a number of content types and their corresponding custom fields that my application has. Obviously, this is not the most optimal way to organize data in my database, but I don't know any better to be honest. I do understand how Drupal's database schema works (every custom field has a different table and entities like node, users, etc have different tables too, and while retrieving any node information, multiple JOINS happen between the node table and the custom field tables and the node information is thus retrieved.

So my question is this - is there a better way to organize my Drupal database? Can't I just create custom tables for each content type as a whole with its fields as columns instead of each custom field having its own tables, which just increases the number of tables in the database? What is the standard that advanced Drupal programmers use to decrease the number of tables in their database and optimize their schema?

⋅ Categories: Drupal 7.x

Comments

Jaypan’s picture

Jaypan commented

The main thing is to ensure you have some caching going on. The entitycache module is good, and adding the Redis module on top of that will improve your caching. You can also look at memcache.

These will not make your database smaller, but they will prevent the database from even being accessed when retrieving your entities (or if Entitycache is used by itself, then there is only a single request for each node).

leeuwnhawk’s picture

leeuwnhawk commented

Would building custom entities for each of my existing content types instead of creating custom fields on top of nodes (content types) be a better approach since that would eliminate the custom tables created for fields in my database?

Jaypan’s picture

Jaypan commented

It's a lot more work, but to be honest, that's exactly what I'm doing right now for a site I'm working on. I've actually bypassed Drupal's entity system altogether, and created my own data types that are entirely independent of Drupal. The advantage is a more lightweight system. The disadvantages is that you lose out on any modules that extend Drupal's entity system.

You could go half-way between what you have now, and what I'm doing, and create Entities that tie in with Drupal's Entity system, but don't use the Field API.