Drupal 7 CCK fields in separate tables - why?
Hi Everyone, I'm sure I'm asking a question that people might have been asking for long. Please bear my ignorance on following all the development threads. I'm right now designing information architecture for one of my clients in Drupal 7 and it turns out that there are many attributes associated to the entities. Now that CCK fields are all stored in separate tables, my node pages now have sql queries that have numerous joins and the performance goes for a toss. Does anyone know a good reason for moving from the previous schema? Single valued cck fields are in the content type and multiple valued fields form a new table. What was wrong with that? -- Cheers, Mukesh Agarwal ________________________________ Innoraft Solutions <http://www.innoraft.com> || +91 8017220799
I know of two reasons why this is: 1. You can have different revisions by field. 2. You can translate by field By normalizing the DB tables this is much easier to accomplish. BUT: You are right DB performance, especially write performance is very bad. I've seen a big drupal project failing because we had about 300 DB tables for a lot of fields. If you have big and complex data structures the standard field implementation of Drupal 7 will not make you happy. I think you have the following options: 1. Use MongoDB. There is a fields storage engine module in Drupal 7. The only problem I see is much less mature DB system than MySql or Postgress DB. 2. User entities API. This is of course much more work, especially if you have to write alle the views and may be fields integration. 3. Look for something else then Drupal. Currently we go for Ruby on Rails with Hobo for projects with a lot (>10-200) business entities. HTH Ernst 2011/10/20 Mukesh Agarwal <mukesh.agarwal17@gmail.com>:
Hi Everyone, I'm sure I'm asking a question that people might have been asking for long. Please bear my ignorance on following all the development threads. I'm right now designing information architecture for one of my clients in Drupal 7 and it turns out that there are many attributes associated to the entities. Now that CCK fields are all stored in separate tables, my node pages now have sql queries that have numerous joins and the performance goes for a toss. Does anyone know a good reason for moving from the previous schema? Single valued cck fields are in the content type and multiple valued fields form a new table. What was wrong with that? -- Cheers, Mukesh Agarwal ________________________________ Innoraft Solutions || +91 8017220799
Ernst Plüss wrote:
I know of two reasons why this is:
1. You can have different revisions by field. 2. You can translate by field
#1 was possible with CCK, the real benefit is that there is no longer any fancy logic around determining what table a field will be stored in. While EntityFieldQuery would be possible without this, it is somewhat easier with consistent per field storage.
1. Use MongoDB. There is a fields storage engine module in Drupal 7. The only problem I see is much less mature DB system than MySql or Postgress DB. 2. User entities API. This is of course much more work, especially if you have to write alle the views and may be fields integration. 3. Look for something else then Drupal. Currently we go for Ruby on Rails with Hobo for projects with a lot (>10-200) business entities.
Your #2 doesn't make any sense. Nodes are already entities and fields are fields regardless of what entity/bundle they are attached to. Your first point should have been to just install Entity cache <http://drupal.org/project/entitycache> and be careful how you load entities. If you think custom development with Rails (and designing your own models) is less work than carefully enabling a few modules and clicking through the fields UI, then I don't know why you would ever even try Drupal in the first place. -Mike __________________ Michael Prasuhn 503.512.0822 office mike@mikeyp.net
Hi Mike, the real benefit is that there is no longer
any fancy logic around determining what table a field will be stored in
Removing the small piece of fancy logic does not really cover up for the overhead multiple tables create. Your first point should have been to just install Entity cache
<http://drupal.org/project/entitycache> and be careful how you load entities.
Entity cache does not help me in case of logged in users. The application I'm developing now is an enterprise app. IMO, caching also does not cover up for multiple tables overhead. I'm sorry if I've misunderstood the workflow of entity cache module but from what it seems, this is just a caching technique for entities. On Thu, Oct 20, 2011 at 11:38 AM, Michael Prasuhn <mike@mikeyp.net> wrote:
Ernst Plüss wrote:
I know of two reasons why this is:
1. You can have different revisions by field. 2. You can translate by field
#1 was possible with CCK, the real benefit is that there is no longer any fancy logic around determining what table a field will be stored in. While EntityFieldQuery would be possible without this, it is somewhat easier with consistent per field storage.
1. Use MongoDB. There is a fields storage engine module in Drupal 7. The only problem I see is much less mature DB system than MySql or Postgress DB. 2. User entities API. This is of course much more work, especially if you have to write alle the views and may be fields integration. 3. Look for something else then Drupal. Currently we go for Ruby on Rails with Hobo for projects with a lot (>10-200) business entities.
Your #2 doesn't make any sense. Nodes are already entities and fields are fields regardless of what entity/bundle they are attached to.
Your first point should have been to just install Entity cache <http://drupal.org/project/entitycache> and be careful how you load entities.
If you think custom development with Rails (and designing your own models) is less work than carefully enabling a few modules and clicking through the fields UI, then I don't know why you would ever even try Drupal in the first place.
-Mike
__________________ Michael Prasuhn 503.512.0822 office mike@mikeyp.net
-- Cheers, Mukesh Agarwal ________________________________ Innoraft Solutions <http://www.innoraft.com> || +91 8017220799
Mukesh Agarwal wrote:
Hi Mike,
the real benefit is that there is no longer
any fancy logic around determining what table a field will be stored in
Removing the small piece of fancy logic does not really cover up for the overhead multiple tables create.
Your first point should have been to just install Entity cache
<http://drupal.org/project/entitycache> and be careful how you load entities.
Entity cache does not help me in case of logged in users. The application I'm developing now is an enterprise app. IMO, caching also does not cover up for multiple tables overhead. I'm sorry if I've misunderstood the workflow of entity cache module but from what it seems, this is just a caching technique for entities.
Actually Entity cache does not pay any regard to whether a user is logged in or not, or even users at all. What it does is cache the fully loaded entity, after it has been loaded from the database (however many tables are required). This means that the first time you load a node you will hit all the necessary tables including node, node_revision, user, all the fields tables, etc and the node object is stored in the cache. Subsequent calls to load that node will retrieve the fully loaded node object from the cache instead of using the node and field tables. The module is also able to determine when changes are made to the node through hook_entity_update and clear/expire the cache accordingly. The Entity cache module works very well logged in users. (If entity loading is truly the source of your performance problems) -Mike __________________ Michael Prasuhn 503.512.0822 office mike@mikeyp.net
2011/10/20 Mukesh Agarwal <mukesh.agarwal17@gmail.com>:
Hi Mike,
the real benefit is that there is no longer any fancy logic around determining what table a field will be stored in
Removing the small piece of fancy logic does not really cover up for the overhead multiple tables create.
Your first point should have been to just install Entity cache <http://drupal.org/project/entitycache> and be careful how you load entities.
Entity cache does not help me in case of logged in users. The application I'm developing now is an enterprise app. IMO, caching also does not cover up for multiple tables overhead. I'm sorry if I've misunderstood the workflow of entity cache module but from what it seems, this is just a caching technique for entities.
If you're building an entrprise app. I'd recommend to think twice whether Drupal is the right system for you. If different Drupal modules do solve most of your business requirements (user management, content, commerce, etc.) and you have to add some glue code and a module or two, go for it. If you find yourself with implementing 20+ entities (objects, classes, tables, you name it) to implement you business Drupal does give you some helper code, but that's it. There are systems which let you doe this with much less work. HTH Ernst
Thank you Ernst for the advice. I think we could have achieved different revisions for each field by marking a field in UI as something that requires revision which would mean only those fields that require a different revision can do that. Same goes for translation. I think the entire field entities API is nice and makes programmers life easier. But in trying to make things generic, we have added a lot of overhead on Drupal core - content management system. Using MongoDb is a good option. I like the idea but since the support system for the same is not that strong, I'm sure clients will have a concern. I'm not sure if I want to chuck Drupal as a solution to our problem. Will have to find different ways. Not convinced with the separate fields idea though. On Thu, Oct 20, 2011 at 11:25 AM, Ernst Plüss <ernst.pluess@gmail.com>wrote:
I know of two reasons why this is:
1. You can have different revisions by field. 2. You can translate by field
By normalizing the DB tables this is much easier to accomplish.
BUT: You are right DB performance, especially write performance is very bad. I've seen a big drupal project failing because we had about 300 DB tables for a lot of fields.
If you have big and complex data structures the standard field implementation of Drupal 7 will not make you happy. I think you have the following options:
1. Use MongoDB. There is a fields storage engine module in Drupal 7. The only problem I see is much less mature DB system than MySql or Postgress DB. 2. User entities API. This is of course much more work, especially if you have to write alle the views and may be fields integration. 3. Look for something else then Drupal. Currently we go for Ruby on Rails with Hobo for projects with a lot (>10-200) business entities.
HTH Ernst
2011/10/20 Mukesh Agarwal <mukesh.agarwal17@gmail.com>:
Hi Everyone, I'm sure I'm asking a question that people might have been asking for long. Please bear my ignorance on following all the development threads. I'm right now designing information architecture for one of my clients in Drupal 7 and it turns out that there are many attributes associated to the entities. Now that CCK fields are all stored in separate tables, my node pages now have sql queries that have numerous joins and the performance goes for a toss. Does anyone know a good reason for moving from the previous schema? Single valued cck fields are in the content type and multiple valued fields form a new table. What was wrong with that? -- Cheers, Mukesh Agarwal ________________________________ Innoraft Solutions || +91 8017220799
-- Cheers, Mukesh Agarwal ________________________________ Innoraft Solutions <http://www.innoraft.com> || +91 8017220799
Hey Mukesh There is really nothing wrong with the approach in core, and making it generic. It fits a wide variety of use-cases. But, sure, maybe we don't always want it that way. That's why Drupal is awesome. Entity API and other hooks. I'm waiting/looking for a module (call it "cheesefields"): 1. Your DBA makes a pretty table. 2. You expose the info (via hook_schema) to drupal 3. You implement hook_cheesefields_info() and to say which field is the key and which entity type it maps to. 4. cheesefields then implements the entity api hooks based on our tables fields and their data types. We get widgets and everything, with the ability to do an alter on the autodetected widgets and specify alternative widgets. To put it a different way, all your fields in one table is not different to a field module that defines multiple fields. We just need to expose it correctly. Simon PS. If you know of this cheesefields module please tell me. On 20 October 2011 17:11, Mukesh Agarwal <mukesh.agarwal17@gmail.com> wrote:
Thank you Ernst for the advice. I think we could have achieved different revisions for each field by marking a field in UI as something that requires revision which would mean only those fields that require a different revision can do that. Same goes for translation. I think the entire field entities API is nice and makes programmers life easier. But in trying to make things generic, we have added a lot of overhead on Drupal core - content management system. Using MongoDb is a good option. I like the idea but since the support system for the same is not that strong, I'm sure clients will have a concern. I'm not sure if I want to chuck Drupal as a solution to our problem. Will have to find different ways. Not convinced with the separate fields idea though.
@Michael: thank you for the clear explanation. I'll sure try the module. @Simon: In the current scenario of my application, I might end up building the "cheesefields" module (wonder whether you add cheese to name your modules :P) and then contributing it to the community. On Thu, Oct 20, 2011 at 12:07 PM, Simon Hobbs <simon@hobbs.id.au> wrote:
Hey Mukesh
There is really nothing wrong with the approach in core, and making it generic. It fits a wide variety of use-cases.
But, sure, maybe we don't always want it that way. That's why Drupal is awesome. Entity API and other hooks.
I'm waiting/looking for a module (call it "cheesefields"): 1. Your DBA makes a pretty table. 2. You expose the info (via hook_schema) to drupal 3. You implement hook_cheesefields_info() and to say which field is the key and which entity type it maps to. 4. cheesefields then implements the entity api hooks based on our tables fields and their data types. We get widgets and everything, with the ability to do an alter on the autodetected widgets and specify alternative widgets.
To put it a different way, all your fields in one table is not different to a field module that defines multiple fields. We just need to expose it correctly.
Simon
PS. If you know of this cheesefields module please tell me.
On 20 October 2011 17:11, Mukesh Agarwal <mukesh.agarwal17@gmail.com> wrote:
Thank you Ernst for the advice. I think we could have achieved different revisions for each field by marking a field in UI as something that requires revision which would mean only those fields that require a different revision can do that. Same goes for translation. I think the entire field entities API is nice and makes programmers life easier. But in trying to make things generic, we have added a lot of overhead on Drupal core - content management system. Using MongoDb is a good option. I like the idea but since the support system for the same is not that strong, I'm sure clients will have a concern. I'm not sure if I want to chuck Drupal as a solution to our problem. Will have to find different ways. Not convinced with the separate fields idea though.
-- Cheers, Mukesh Agarwal ________________________________ Innoraft Solutions <http://www.innoraft.com> || +91 8017220799
Coolio. Like I say, it might already exist, I'm going to have a closer look at the properties module myself. I had a situation where I was mapping Netsuite entities to content types and the fields tables were getting out of hand, IMO. I had content types with dozens of fields and to display the full content type with a view could feasibly break the 61 join limit of MySQL 5.x. You might never get there, but if you do you can bet it's late in the build and you will be crying into your free beer. .s On 20 October 2011 17:53, Mukesh Agarwal <mukesh.agarwal17@gmail.com> wrote:
@Michael: thank you for the clear explanation. I'll sure try the module. @Simon: In the current scenario of my application, I might end up building the "cheesefields" module (wonder whether you add cheese to name your modules :P) and then contributing it to the community. On Thu, Oct 20, 2011 at 12:07 PM, Simon Hobbs <simon@hobbs.id.au> wrote:
Hey Mukesh
There is really nothing wrong with the approach in core, and making it generic. It fits a wide variety of use-cases.
But, sure, maybe we don't always want it that way. That's why Drupal is awesome. Entity API and other hooks.
I'm waiting/looking for a module (call it "cheesefields"): 1. Your DBA makes a pretty table. 2. You expose the info (via hook_schema) to drupal 3. You implement hook_cheesefields_info() and to say which field is the key and which entity type it maps to. 4. cheesefields then implements the entity api hooks based on our tables fields and their data types. We get widgets and everything, with the ability to do an alter on the autodetected widgets and specify alternative widgets.
To put it a different way, all your fields in one table is not different to a field module that defines multiple fields. We just need to expose it correctly.
Simon
PS. If you know of this cheesefields module please tell me.
On 20 October 2011 17:11, Mukesh Agarwal <mukesh.agarwal17@gmail.com> wrote:
Thank you Ernst for the advice. I think we could have achieved different revisions for each field by marking a field in UI as something that requires revision which would mean only those fields that require a different revision can do that. Same goes for translation. I think the entire field entities API is nice and makes programmers life easier. But in trying to make things generic, we have added a lot of overhead on Drupal core - content management system. Using MongoDb is a good option. I like the idea but since the support system for the same is not that strong, I'm sure clients will have a concern. I'm not sure if I want to chuck Drupal as a solution to our problem. Will have to find different ways. Not convinced with the separate fields idea though.
-- Cheers, Mukesh Agarwal ________________________________ Innoraft Solutions || +91 8017220799
also there's per bundle storage module: drupal.org/project/pbs Does the old cck, single value fields in one table
Hi Lee, I dont see a release for pbs. On Thu, Oct 20, 2011 at 2:07 PM, Lee Rowlands <contact@rowlandsgroup.com>wrote:
also there's per bundle storage module:
drupal.org/project/pbs
Does the old cck, single value fields in one table
-- Cheers, Mukesh Agarwal ________________________________ Innoraft Solutions <http://www.innoraft.com> || +91 8017220799
I'm building a "cheezefield" module right now myself. Perhaps this is pure Frankenstein, or maybe it's good: I have a complex content type managing a variable number of files, with variable attributes and properties for each file. Also this content type has references to other nodes of the same type. To implement, I created a fieldset holding all of these possible fields, and generated 10 of them in a loop. For the UI, they appear as needed via jquery, and js validation makes only the fields appear that correspond with a given file type. The module's DB presence is my one table for the additional content type, and for each of the datatypes in the fieldset I have a big varchar field holding a serialized keyed array of values entered by the user. It's really simple to just assign my data arrays to the node, at insert/update serialize them and at load unserialize to recover my keyed arrays. I'm 75% of the way done with with after a day, expecting to wrap up today. Considering that serialize/unserialize can't be less performant than ooodles of DB calls, this looks like a winner to me... Sincerely, -Blake bsenftner@earthlink.net www.BlakeSenftner.com www.Droplabs.net www.MissingUbercartManual.com On Oct 20, 2011, at 1:29 AM, Simon Hobbs wrote:
Coolio. Like I say, it might already exist, I'm going to have a closer look at the properties module myself. I had a situation where I was mapping Netsuite entities to content types and the fields tables were getting out of hand, IMO. I had content types with dozens of fields and to display the full content type with a view could feasibly break the 61 join limit of MySQL 5.x. You might never get there, but if you do you can bet it's late in the build and you will be crying into your free beer.
.s
On 20 October 2011 17:53, Mukesh Agarwal <mukesh.agarwal17@gmail.com> wrote:
@Michael: thank you for the clear explanation. I'll sure try the module. @Simon: In the current scenario of my application, I might end up building the "cheesefields" module (wonder whether you add cheese to name your modules :P) and then contributing it to the community. On Thu, Oct 20, 2011 at 12:07 PM, Simon Hobbs <simon@hobbs.id.au> wrote:
Hey Mukesh
There is really nothing wrong with the approach in core, and making it generic. It fits a wide variety of use-cases.
But, sure, maybe we don't always want it that way. That's why Drupal is awesome. Entity API and other hooks.
I'm waiting/looking for a module (call it "cheesefields"): 1. Your DBA makes a pretty table. 2. You expose the info (via hook_schema) to drupal 3. You implement hook_cheesefields_info() and to say which field is the key and which entity type it maps to. 4. cheesefields then implements the entity api hooks based on our tables fields and their data types. We get widgets and everything, with the ability to do an alter on the autodetected widgets and specify alternative widgets.
To put it a different way, all your fields in one table is not different to a field module that defines multiple fields. We just need to expose it correctly.
Simon
PS. If you know of this cheesefields module please tell me.
On 20 October 2011 17:11, Mukesh Agarwal <mukesh.agarwal17@gmail.com> wrote:
Thank you Ernst for the advice. I think we could have achieved different revisions for each field by marking a field in UI as something that requires revision which would mean only those fields that require a different revision can do that. Same goes for translation. I think the entire field entities API is nice and makes programmers life easier. But in trying to make things generic, we have added a lot of overhead on Drupal core - content management system. Using MongoDb is a good option. I like the idea but since the support system for the same is not that strong, I'm sure clients will have a concern. I'm not sure if I want to chuck Drupal as a solution to our problem. Will have to find different ways. Not convinced with the separate fields idea though.
-- Cheers, Mukesh Agarwal ________________________________ Innoraft Solutions || +91 8017220799
Properties is handy if you have a few properties for a lot of nodes. If your problem with D7 fields is performance (most likely insert performance) it does not help because you will have one insert statement for every property instance. That's exactly the same as with D7 fields. 2011/10/20 Simon Hobbs <simon@hobbs.id.au>:
Coolio. Like I say, it might already exist, I'm going to have a closer look at the properties module myself. I had a situation where I was mapping Netsuite entities to content types and the fields tables were getting out of hand, IMO. I had content types with dozens of fields and to display the full content type with a view could feasibly break the 61 join limit of MySQL 5.x. You might never get there, but if you do you can bet it's late in the build and you will be crying into your free beer.
.s
On 20 October 2011 17:53, Mukesh Agarwal <mukesh.agarwal17@gmail.com> wrote:
@Michael: thank you for the clear explanation. I'll sure try the module. @Simon: In the current scenario of my application, I might end up building the "cheesefields" module (wonder whether you add cheese to name your modules :P) and then contributing it to the community. On Thu, Oct 20, 2011 at 12:07 PM, Simon Hobbs <simon@hobbs.id.au> wrote:
Hey Mukesh
There is really nothing wrong with the approach in core, and making it generic. It fits a wide variety of use-cases.
But, sure, maybe we don't always want it that way. That's why Drupal is awesome. Entity API and other hooks.
I'm waiting/looking for a module (call it "cheesefields"): 1. Your DBA makes a pretty table. 2. You expose the info (via hook_schema) to drupal 3. You implement hook_cheesefields_info() and to say which field is the key and which entity type it maps to. 4. cheesefields then implements the entity api hooks based on our tables fields and their data types. We get widgets and everything, with the ability to do an alter on the autodetected widgets and specify alternative widgets.
To put it a different way, all your fields in one table is not different to a field module that defines multiple fields. We just need to expose it correctly.
Simon
PS. If you know of this cheesefields module please tell me.
On 20 October 2011 17:11, Mukesh Agarwal <mukesh.agarwal17@gmail.com> wrote:
Thank you Ernst for the advice. I think we could have achieved different revisions for each field by marking a field in UI as something that requires revision which would mean only those fields that require a different revision can do that. Same goes for translation. I think the entire field entities API is nice and makes programmers life easier. But in trying to make things generic, we have added a lot of overhead on Drupal core - content management system. Using MongoDb is a good option. I like the idea but since the support system for the same is not that strong, I'm sure clients will have a concern. I'm not sure if I want to chuck Drupal as a solution to our problem. Will have to find different ways. Not convinced with the separate fields idea though.
-- Cheers, Mukesh Agarwal ________________________________ Innoraft Solutions || +91 8017220799
Thank you Ernst for your advice. I'm right now doing a study of how my information architecture looks without any framework (assuming i'm building a custom system) and how it would look with Drupal. I think I'll get a good understanding of the pros and cons and should then be able to decide. As far as enterprise application is concerned, Drupal is an awesome fit for this application and I would have done it right had it been Drupal 6. I still need to understand the implications of breaking fields into separate tables coz I think this will be a hindrance for developers to maintain with changing data. Guys, if you think you like the separate tables model, please mention the PROs for the same and I'll post the same on d.o. forums as I think more developers like me would be interested in weighing this model. On Thu, Oct 20, 2011 at 11:33 PM, Ernst Plüss <ernst.pluess@gmail.com>wrote:
Properties is handy if you have a few properties for a lot of nodes. If your problem with D7 fields is performance (most likely insert performance) it does not help because you will have one insert statement for every property instance. That's exactly the same as with D7 fields.
2011/10/20 Simon Hobbs <simon@hobbs.id.au>:
Coolio. Like I say, it might already exist, I'm going to have a closer look at the properties module myself. I had a situation where I was mapping Netsuite entities to content types and the fields tables were getting out of hand, IMO. I had content types with dozens of fields and to display the full content type with a view could feasibly break the 61 join limit of MySQL 5.x. You might never get there, but if you do you can bet it's late in the build and you will be crying into your free beer.
.s
On 20 October 2011 17:53, Mukesh Agarwal <mukesh.agarwal17@gmail.com> wrote:
@Michael: thank you for the clear explanation. I'll sure try the module. @Simon: In the current scenario of my application, I might end up building the "cheesefields" module (wonder whether you add cheese to name your modules :P) and then contributing it to the community. On Thu, Oct 20, 2011 at 12:07 PM, Simon Hobbs <simon@hobbs.id.au> wrote:
Hey Mukesh
There is really nothing wrong with the approach in core, and making it generic. It fits a wide variety of use-cases.
But, sure, maybe we don't always want it that way. That's why Drupal is awesome. Entity API and other hooks.
I'm waiting/looking for a module (call it "cheesefields"): 1. Your DBA makes a pretty table. 2. You expose the info (via hook_schema) to drupal 3. You implement hook_cheesefields_info() and to say which field is the key and which entity type it maps to. 4. cheesefields then implements the entity api hooks based on our tables fields and their data types. We get widgets and everything, with the ability to do an alter on the autodetected widgets and specify alternative widgets.
To put it a different way, all your fields in one table is not different to a field module that defines multiple fields. We just need to expose it correctly.
Simon
PS. If you know of this cheesefields module please tell me.
On 20 October 2011 17:11, Mukesh Agarwal <mukesh.agarwal17@gmail.com> wrote:
Thank you Ernst for the advice. I think we could have achieved different revisions for each field by marking a field in UI as something that requires revision which would mean
only
those fields that require a different revision can do that. Same goes for translation. I think the entire field entities API is nice and makes programmers life easier. But in trying to make things generic, we have added a lot of overhead on Drupal core - content management system. Using MongoDb is a good option. I like the idea but since the support system for the same is not that strong, I'm sure clients will have a concern. I'm not sure if I want to chuck Drupal as a solution to our problem. Will have to find different ways. Not convinced with the separate fields idea though.
-- Cheers, Mukesh Agarwal ________________________________ Innoraft Solutions || +91 8017220799
-- Cheers, Mukesh Agarwal ________________________________ Innoraft Solutions <http://www.innoraft.com> || +91 8017220799
#4 Or You can use http://drupal.org/project/properties or something like that for a huge fields data * --------------------------------------------------------------------------------------------------------------------------------------------------------- * *Andriy Podanenko* *podarok@ + podarokua@ + podarok_ua@* Own Blog <http://my.ukrweb.info/blog> | Homepage <http://podanenko.com> | Twitter <http://twitter.com/podarok> | LinkedIn<http://www.linkedin.com/in/podarok>| Profeo <http://www.profeo.ua/podarok> | vKontakte<http://vkontakte.ru/podarokua>| Connect <http://connect.ua/user-657054> | Facebook<http://www.facebook.com/podarok>| FriendFeed <http://friendfeed.com/podarok> | Drupal ID<http://drupal.org/user/116002>| Drupal UA ID <http://drupal.ua/users/podarok> | Yahoo ID<http://pulse.yahoo.com/_3SZUYBNZG4OQJCUJOZYF2D3UJY>| SlideShare <http://www.slideshare.net/podarok> | Delicious<http://www.delicious.com/podarok>| Live ID <http://cid-3c79f9bdf923693a.profile.live.com/> | Google ID<http://www.google.com/profiles/podarokua>| Formspring <http://www.formspring.me/podarokua> | Digg<http://digg.com/podarok>| WMID *560874932971* | ICQ *499918925* | YahooIM *podarok_ua* | Jabber * podarok@jabber.org* | Gtalk *podarokua* | AIM *podarokua* | | | | *Меня не интересует, почему «нет», меня интересует, что нужно сделать для того, чтобы было «да»* 2011/10/20 Ernst Plüss <ernst.pluess@gmail.com>
I know of two reasons why this is:
1. You can have different revisions by field. 2. You can translate by field
By normalizing the DB tables this is much easier to accomplish.
BUT: You are right DB performance, especially write performance is very bad. I've seen a big drupal project failing because we had about 300 DB tables for a lot of fields.
If you have big and complex data structures the standard field implementation of Drupal 7 will not make you happy. I think you have the following options:
1. Use MongoDB. There is a fields storage engine module in Drupal 7. The only problem I see is much less mature DB system than MySql or Postgress DB. 2. User entities API. This is of course much more work, especially if you have to write alle the views and may be fields integration. 3. Look for something else then Drupal. Currently we go for Ruby on Rails with Hobo for projects with a lot (>10-200) business entities.
HTH Ernst
2011/10/20 Mukesh Agarwal <mukesh.agarwal17@gmail.com>:
Hi Everyone, I'm sure I'm asking a question that people might have been asking for long. Please bear my ignorance on following all the development threads. I'm right now designing information architecture for one of my clients in Drupal 7 and it turns out that there are many attributes associated to the entities. Now that CCK fields are all stored in separate tables, my node pages now have sql queries that have numerous joins and the performance goes for a toss. Does anyone know a good reason for moving from the previous schema? Single valued cck fields are in the content type and multiple valued fields form a new table. What was wrong with that? -- Cheers, Mukesh Agarwal ________________________________ Innoraft Solutions || +91 8017220799
participants (7)
-
Andriy Podanenko -
Blake Senftner -
Ernst Plüss -
Lee Rowlands -
Michael Prasuhn -
Mukesh Agarwal -
Simon Hobbs