Avoid Drupal 7 database for CCK

Posted by mykmallett on December 10, 2012 at 12:39am

I chose Drupal 6 because the structure of the database for custom content types was closest to our data model, albeit with the centralised Node table added. It works better in terms of normalisation and in terms of our system this was vitally important to us. We have been building logical data models for 30 years and the idea of doing everything from the front end and using the hideously convoluted views method to pull out data in awful SQL queries makes little sense to us.

Anyway, point being that the data model is still extremely important to us, but we are aware that the need to upgrade to Drupal 7 is going to get ever more urgent. My question is whether it is possible to keep a similar data structure, or whether you have to use the method that Drupal has adopted for its database in its core CCK module. The idea of having a table for each field, as I understand is the case, is so completely absurd to me that it makes me a bit nauseous. If I'm wrong, please correct me because I would love to be wrong about this.

So is there any way I will be able to upgrade my system and keep a relatively similar data structure, whilst still leveraging the advantages to using the Node system? I've avoided similar problems in d6 by making sure never to use the apparently useful feature to share fields across different content types. Something else which makes me shudder slightly...

BTW I do really like Drupal, honest

Thanks
Mike

Comments

The table structure used for

Posted by nevets on December 10, 2012 at 1:42am

The table structure used for fields works well and is actually a good example of a relational database model. The is nothing absurd about it.

I disagree, and so do many

Posted by mykmallett on December 10, 2012 at 2:04pm

I disagree, and so do many others. I think it might work well in the UI, but this seems symptomatic of a lot of frameworks and CMS's, or software solutions that rely too much on UI and not writing efficient, clean and concise code that is scalable. I struggle to see how this would work for our current model, nor how you would programmatically use the data structure. It seems to have taken a huge step backwards. Maybe I'm just old fashioned, but I don't see anything broken with good quality, normalised data structures and queries, whereas there is now added complexity that makes it much harder for me to justify using drupal to my clients and my partners.

This point for example:

Why would Drupal 7 see individual field tables as being a step in the right direction? Plus - I found someone saying it was a big bonus that you could share field tables between content types - woo hoo. This solution would never pass any solution review I've ever been a part of. Complex content types may have 50 or more fields, so pulling back one complete content type record would involve hitting 50 different tables (either multiple queries, or one query joining 50 tables, lol!!), which is really an incomprehensible way of doing things. Crazy.

Am I misunderstanding? Because that strikes me as absurd.

Last version of drupal that I would use Drupal 6

Posted by senthiln on December 22, 2012 at 6:17am

A table for each field? Some insane idea forced upon long time drupal users. I have over 25 columns in my custom content type. And close to a million record of that type. I am already battling with performance issues. I can't imagine what 25 joins will do to the performance of my sytem. Drupal 4.x was my first version and perhaps 6.x will be my last version. I am afraid I would die with just drupal 6.0 because I don't have the energy or resource to migrate to different CMS from drupal. Once I thought I made the right choice but now I deeply regret choosing drupal as my CMS.