views:

58

answers:

2

Hello, Im currently evaluating Drupal to see if we can use it to replace our framework. My problem is I have this legacy tables which I would want to try to reflect in Drupal. It involves a join table. There's quite a lot of this kind of relationship in our existing web app so I am looking for possible ways to solve it. alt text

Thank you for your insight!

+5  A: 

There are several ways to do this, and it's hard to know which is best with no context about what you're actually doing with the data, but here are some options:

One way to do this is to make a content type representing each table (using CCK) with the foreign keys represented by type-specific node reference fields. Doing everything as nodes gives you a bunch of prebuilt functionality around nodes, but has a bit of overhead you may want to avoid.

Another option is to leave your database just like it is now. Drupal can do direct database queries, or you can use Data to expose your tables to Views.

Another option, if those referenced tables really only have 1 non-ID field, is to do the project_companies_assignments as nodes and do the other 3 as taxonomies. But this won't work if those are really more complex entities, and wouldn't be very flexible if they might become more complex.

Scott Reynen
When you say potential overhead ,does this mean storing everything as nodes will slow down my site?is this because drupal has to do several self joins?In reality the projects table has 15,000 records ,8000 for companies and around 44000 for the roles table.
r2b2
Mostly implementation overhead.
Jeremy French
The overhead of nodes is directly tied to the benefits: most modules in Drupal interact with nodes, so every time you do something with a node (load it, save it, view it), most modules you have installed are checking if they need to do something, and possibly actually doing something based on what you just did. Where that something is useful, nodes are useful. Where it's not, this is all overhead.
Scott Reynen
+1 for suggesting the data module
Sid NoParrots
A: 

Going with Views and CCK, optionally with the additional Data module has one huge disadvantage: it comes with complexity.

My preferred alternative, is to write your own module. Drupal offers little help wrt database abstraction, it comes not with a proper ORM or such. But with some simple CRUD functions for the data in the database, a few simple forms in front, and a menu-callback with some pages to present the data, you can -quite often- get your datamodel worked out much faster then going the route of the overly complex, often poorly documented CCK and views modules. KISS.

berkes

related questions