I am hoping someone will provide an answer as this is a very serious issue for me. I tried posting in CCK Project but got no replies.

I build on-line transaction processing web applications and am trying to figure out how to build my web application in Drupal 7.

We have around 300 Content Types. A number of key tables have > 100 columns.
The database is fully normalized with the exception of some OLAP tables that have periodically summarized data, optimized for reporting purposes.

Some tables have hundreds of thousands of rows. Altogether we have several thousands distinct fields in the database (no redundantly stored data except foreign keys and the OLAP tables).

With exception of some lookup tables, many tables are very dynamic and at least some data changes every few hours and sometimes every few minutes.

In the current version of the app we have our own modules with our own SQL statements (we have several hundred such performance optimized queries).

Given the new content-by-field structure of D7 (as opposed to content-by-table), I am not sure how we would make our application work in D7. Some specific questions:

1. What is the recommended approach for dealing with large, complex data structures in D7?
2. What can one expect with regard to performance for large data-driven web-based OLTP applications in D7?
3. What is the rationale behind the switch to this new data structure? I have heard that it is performance related due to the existence of "shared data". What is that? I have never heard of "shared data" in a well designed database.
4. Is there any documentation that describes the rationale behind the new architecture or the thought process leading up to it?

I hope someone will respond as I do not want to reject D7 out of hand and my experience so far is that there are a lot of very smart people involved in the architectural design of Drupal. I am sure they had something in mind when contemplating this switch and perhaps if I understood that logic I could come up with a solution for my application.

Thanks in advance for any insights.

Comments

RumpledElf’s picture

RumpledElf commented

Subscribing, as I am writing a d7 app and people think I am insane for wanting to save my content types per table not one field per table, and I think its insane to have one table per field.

I'm sure someone will eventually write a module that re-implements the backend of d7 to one table per content type, I think this is a big issue that could kill d7 for some websites. Our next project is another one that will have a lot of wide content types and a lot of concurrent users and I really don't want to use d7 for it, purely because of the field-per-table thing, as well as d7's general slowness. D6 looks good though.

kars-t’s picture

kars-t commented
Status: Active » Fixed

Dear fellow Drupal enthusiasts,

this issue is now lasting for a very long time in the issue queue and was unfortunately never solved. As Drupal is a open source project everyone is helping on voluntary basis. So that this is was not solved is nothing personal and means no harm. But perhaps no one had time to deal with this issue, maybe it is too complex or did not pose the problem comprehensible.

But this issue is not the only one. There are thousands of issues on Drupal.org that have never been worked on or could not be processed. This means that we are building a wave that is unmanageable and just a problem for the Drupal project as a whole. Please help us keep the issue queue smaller and more manageable.

Please read again, "Making an issue report" and see if you can improve the issue. Test the problem with the current Core and modules. Maybe the problem doesn't exist anymore, is a duplicate or has even been solved within this issue but never closed.

Help can also be found for it on IRC and in the user groups.

In order this issue no longer remains, I put this issue to "fixed".

If there is new information, please re-open the issue.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.