When not to use Drupal – A Rant

The last two days I have been working on migrating our clients database from a custom built Drupal modules to something a bit more sane and relational. Now don’t get me wrong Drupal has its place in the CMS space but for something as simple as keeping tabs of client data, equipment and the such it is a bit of overkill.

One, your performance is going to suffer because of all the extra heavy lifting.

Two it is much easier to build something in house that any developer can understand in the future – god forbid your dev team leaves vs requiring someone(myself in this case) to reverse engineer how Drupal is storing data; how best to retrieve said data and then transpose it to a new format.

First let me show you the query used to get the data from Drupal:

SELECT DISTINCT node.nid AS nid,
   SUM(search_index.score * search_total.count) AS score,
   node_data_field_customer_id.field_customer_id_value AS node_data_field_customer_id_field_customer_id_value,
   node.type AS node_type,
   node.vid AS node_vid,
   node.title AS node_title,
   node_data_field_customer_id.field_contract_date_value AS node_data_field_customer_id_field_contract_date_value,
   node_data_field_customer_id.field_original_date_value AS node_data_field_customer_id_field_original_date_value,
   node_data_field_customer_id.field_contract_term_value AS node_data_field_customer_id_field_contract_term_value,
   node_data_field_customer_id.field_billtocontactonename_value AS node_data_field_customer_id_field_billtocontactonename_value,
   node_data_field_customer_id.field_billtocontactonevox_value AS node_data_field_customer_id_field_billtocontactonevox_value,
   node_data_field_customer_id.field_billtocontactoneemail_value AS node_data_field_customer_id_field_billtocontactoneemail_value,
   node_data_field_customer_id.field_account_status_value AS node_data_field_customer_id_field_account_status_value,
   node_data_field_customer_id.field_account_current_value AS node_data_field_customer_id_field_account_current_value
FROM node node 
  LEFT JOIN search_index search_index ON node.nid = search_index.sid
  LEFT JOIN search_total search_total ON search_index.word = search_total.word
  LEFT JOIN content_type_client_account node_data_field_customer_id ON node.vid = node_data_field_customer_id.vid
  WHERE (node.status = 1) AND (node.type in ('client_account')) AND (search_index.type = 'node')
  GROUP BY search_index.sid, node_title, nid, node_data_field_customer_id_field_customer_id_value, node_type, node_vid, node_data_field_customer_id_field_contract_date_value, node_data_field_customer_id_field_original_date_value, node_data_field_customer_id_field_contract_term_value, node_data_field_customer_id_field_billtocontactonename_value, node_data_field_customer_id_field_billtocontactonevox_value, node_data_field_customer_id_field_billtocontactoneemail_value, node_data_field_customer_id_field_account_status_value, node_data_field_customer_id_field_account_current_value
  HAVING COUNT(*) >= 1
  ORDER BY node_title ASC
  LIMIT 0, 50

Now, as MySQL queries go this one could be worse but overall it is pretty horrid to look at and is almost impossible to reverse engineer via looking at a show tables. So to start reverse engineering how Drupal was working, I cheated. I enabled general query logging in MySQL:

vim /etc/my.cnf

Added one line

general_log = 1

Restarted MySQL and started tail -fing; Yep this is a rant therefore I can make command arguments verbs; Digressing now. Do not use Drupal for a single purpose application. Either build it from scratch or find a pre-built solution for your problem.

In this case there are dozens of CRM’s that would provide a solution for this need. Or where I am building something that needs to be heavily integrated all around I built it from the ground up into an existing project.

Write a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.