Create relation N:N and specify properties for each relation

Question

I have two content types: "Car" and "Options". My cars can have different options, so I could associate options to a car with References Module. But my problem is I'd like to specify the price of the option for each car/each relation.

Example:

Seat    - Airbag - 100 €  
Citroen - Airbag - 88 €

The relation is not only a node reference, it has "metadatas".

For the moment, I plan to develop my own module, maybe "Relations" module will be the solution, but I tried it with no success.

How can I solve this problem?

Answer 1

If there is an existing contrib module for that, that would be Relation. It works at the level of Entities. It should provide a generic API/framework that can be used for what you describe.

If Relation doesn't fit your needs or is not ready for you, then writing a custom module would be the only option. For a custom module, I would work at the Entities level (with the help of the Entity API module), not directly in SQL. While Drupal doesn't provides scaffolding for Entities, it provide helper functions such as field_attach_form() or field_attach_insert() to deal with fields on entities. Unfortunately, the documentation on how to properly use entities is still scarce. The Model module is an attempt to help there since it aims to provide a model entity and entity administration interface to kick-start your entity development.

Answer 2

Field Collection is another option. IMO it has a better user interface than Relation out of the box, especially if the relationships can be considered directional.

Answer 3

A good module is the Dynamic properties module which does exactly what you want. There is a demo.

Maybe you would like to check the Entity Construction Kit (ECK), which helps you to develop entities, and maybe rules and relation integration for multiple values field collection.

Answer 4

As you point out, you have the option to develop your own module. In this case, that would be my advise.

Nodereference module (packaged in the CCK bundle) is not a generic relations-module. It can be used for what the description says it is: Defines a field type for referencing one node from another. With some creativity one can abuse this to create generic N:N and 1:N and even polymorphic relations, but that is never optimal; both technical/performancewise as usabilitywise.

Things you cannot do (well) with this module:

1. Associate things to things other then nodes-to-nodes.
2. Keep the SQL and tabledefinitions optimal for your specific cases, filters and searches.
3. Validate across relations: If child misses a required field, don't proceed with parent.
4. Atomic updates and inserts: If Relation X fails, don't write its parent Y (or roll it back)
5. Implement businesslogic: e.g. An order is either unshippable OR has a shipping-address associated.

However, Writing your own solution comes with a lot of downsides, most notably:

1. Drupal (6) has no ORM, Drupal 7 has one, but is underused. You will be doing all the DBA interaction "by hand". Required effort one might not expect in a "framework"
2. Drupal gives no scaffolds, APIs and such for CRUD-actions: you will be writing all the forms, pages, storage- and update- handlers by hand. Obviously using Drupal-APIs, but nonetheless, often over 2000 lines of PHP just to manage some "items" and their associations. Nodes on the other hand, do come with such benefits "for free".
3. Drupal has little or no validation-helpers. You will be writing all your validations in your own PHP. The FormAPI comes with basic (but solid) mass-assignment-protection, but offers little validations on things like dates, lengths[1], sizes, ranges etceteras.

[1] As such, many contributed modules (and even core) have quite often bugs where the input allows a lot longer texts or numbers then the database can store according to its schema: simply because developers did not write validators for them.