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