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. <div>
<br></div><div>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. </div>
<div><br></div><div>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. <br>
<br><div class="gmail_quote">On Thu, Oct 20, 2011 at 11:33 PM, Ernst Plüss <span dir="ltr"><<a href="mailto:ernst.pluess@gmail.com">ernst.pluess@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Properties is handy if you have a few properties for a lot of nodes.<br>
If your problem with D7 fields is performance (most likely insert<br>
performance) it does not help because you will have one insert<br>
statement for every property instance. That's exactly the same as with<br>
D7 fields.<br>
<br>
<br>
2011/10/20 Simon Hobbs <<a href="mailto:simon@hobbs.id.au">simon@hobbs.id.au</a>>:<br>
<div><div></div><div class="h5">> Coolio. Like I say, it might already exist, I'm going to have a closer<br>
> look at the properties module myself. I had a situation where I was<br>
> mapping Netsuite entities to content types and the fields tables were<br>
> getting out of hand, IMO. I had content types with dozens of fields<br>
> and to display the full content type with a view could feasibly break<br>
> the 61 join limit of MySQL 5.x. You might never get there, but if you<br>
> do you can bet it's late in the build and you will be crying into your<br>
> free beer.<br>
><br>
> .s<br>
><br>
> On 20 October 2011 17:53, Mukesh Agarwal <<a href="mailto:mukesh.agarwal17@gmail.com">mukesh.agarwal17@gmail.com</a>> wrote:<br>
>> @Michael: thank you for the clear explanation. I'll sure try the module.<br>
>> @Simon: In the current scenario of my application, I might end up building<br>
>> the "cheesefields" module (wonder whether you add cheese to name your<br>
>> modules :P) and then contributing it to the community.<br>
>> On Thu, Oct 20, 2011 at 12:07 PM, Simon Hobbs <<a href="mailto:simon@hobbs.id.au">simon@hobbs.id.au</a>> wrote:<br>
>>><br>
>>> Hey Mukesh<br>
>>><br>
>>> There is really nothing wrong with the approach in core, and making it<br>
>>> generic. It fits a wide variety of use-cases.<br>
>>><br>
>>> But, sure, maybe we don't always want it that way. That's why Drupal<br>
>>> is awesome. Entity API and other hooks.<br>
>>><br>
>>> I'm waiting/looking for a module (call it "cheesefields"):<br>
>>> 1. Your DBA makes a pretty table.<br>
>>> 2. You expose the info (via hook_schema) to drupal<br>
>>> 3. You implement hook_cheesefields_info() and to say which field is<br>
>>> the key and which entity type it maps to.<br>
>>> 4. cheesefields then implements the entity api hooks based on our<br>
>>> tables fields and their data types. We get widgets and everything,<br>
>>> with the ability to do an alter on the autodetected widgets and<br>
>>> specify alternative widgets.<br>
>>><br>
>>> To put it a different way, all your fields in one table is not<br>
>>> different to a field module that defines multiple fields. We just need<br>
>>> to expose it correctly.<br>
>>><br>
>>> Simon<br>
>>><br>
>>> PS. If you know of this cheesefields module please tell me.<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> On 20 October 2011 17:11, Mukesh Agarwal <<a href="mailto:mukesh.agarwal17@gmail.com">mukesh.agarwal17@gmail.com</a>><br>
>>> wrote:<br>
>>> > Thank you Ernst for the advice.<br>
>>> > I think we could have achieved different revisions for each field by<br>
>>> > marking<br>
>>> > a field in UI as something that requires revision which would mean only<br>
>>> > those fields that require a different revision can do that. Same goes<br>
>>> > for<br>
>>> > translation. I think the entire field entities API is nice and makes<br>
>>> > programmers life easier. But in trying to make things generic, we have<br>
>>> > added<br>
>>> > a lot of overhead on Drupal core - content management system.<br>
>>> > Using MongoDb is a good option. I like the idea but since the support<br>
>>> > system<br>
>>> > for the same is not that strong, I'm sure clients will have a concern.<br>
>>> > I'm not sure if I want to chuck Drupal as a solution to our problem.<br>
>>> > Will<br>
>>> > have to find different ways.<br>
>>> > Not convinced with the separate fields idea though.<br>
>>> ><br>
>><br>
>><br>
>><br>
>> --<br>
>> Cheers,<br>
>> Mukesh Agarwal<br>
>> ________________________________<br>
>> Innoraft Solutions || +91 8017220799<br>
>><br>
><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Cheers,<div>Mukesh Agarwal</div><div>________________________________</div><div><font color="#999999"><a href="http://www.innoraft.com" target="_blank">Innoraft Solutions</a> || </font><span style="color:rgb(153, 153, 153)">+91 8017220799</span></div>
<br>
</div>