Im thinking even if you had separate tables for content types, you'd still need a master table to track all your objects anyway, even if all it does is list content types. Either way, you've got JOINs, so it's probably harder to work outside the default Drupal model (though index's are one route for custom code, as discussed). chris On 12/02/2011, at 6:11 AM, Scott Reynolds wrote:

http://drupal.org/project/pbs

I am assuming you mean something like that, where the fields are stored in the same table. There are advantages and disadvantages to all approaches, this module though, while it hasn't been improved in awhile is the right step towards what you want. It should work with Views as it implements the FieldAPI and Views works with the FieldAPI.

Of course, as people have pointed out, make sure you are positive that this will have any performance improvement on your site as it is probably going to break some other modules bad assumptions and it also might have a negative performance impact. O and it also might not work with the lastest FieldAPI. So there is a development cost to this, so its worth evaluating the development cost vs the performance gains. Oftentimes, it is better to throw money at a performance problem first, then code.