[development] Drupal 7 CCK fields in separate tables - why?

[Mukesh Agarwal]

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 at 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 at 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 at 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 at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20111021/82ee76e8/attachment-0001.html