[TYPO3-ect] Symmetric MM-Relations

[Oliver Hader]

Hi Elmar,

thanks for the invitation and hint! It's an really interesting and
neccessary topic!

Elmar Hinz wrote:
> Mads Brunn and Rene Fritz try to solve the problem with the extensions
> "bidirectional" and "mmforeign" by doing exactly this. They make the
> unbalanced relation accessible from the other side. But that is only
> half of the solution.

I'll have a closer look to this extensions and possibly give a feedback
on that later.

> The relation itself is still anbalanced. It can relate one table type to
> many table types by setting the field "tables". It is still not possible
> to select from many table types from both sides of the relation. We
> would need to fields "tables" to do this.
> 
> uid1 - ui2 - table1 - table2 - sorting1 - sorting2 - type/role(?)
> 
> One relation table obviously would take up all possible MM relations
> this way.
> 
> Do we need this kind of realation? If so, how could we get it into the
> core and into TCE?

I would add an index to every relation-record, as you have already
mentioned in the "Roles" posting - how a combination with roles or
attributes could look like, is another (or *the* other) topic.

So we have a fieldset of this (I added some fields):
id - crdate - tstamp - deleted - hidden - table1_id - table2_id - table1
- table2 - sorting1 - sorting2 - [role]

I think that this also could be a possibility of handling 1:n or 1:1
relations in the TYPO3 context. Imagine you have a system where you
store data of persons (also called "party") and many addresses - in fact
the following example should be a mm-thing, but we use it as 1:n here.

Some example cases:
1) <person_1> lives at		<address_1>
2) <person_1> works at		<address_2>

3) <person_2> lives at		<address_3>
4) <person_2> works at		<address_4>
5) <person_2> owns a flat at	<address_5>

Now the sitiation comes, that <person_2> sells his flat, so the case
number "5" becomes obsolete. There would be the possibility of
completely removing this relation or to set the record to "deleted".
If setting to "deleted" we could use an undo-function if the used had
done a mistake or if it was correct, we can see, that <person_2> once
hat a flat at <address_5>. So in the last case it also would be
interesting, when (at which date) the "person owns flat" relation got
lost, so we have a tstamp field there.

I think this normalized model (on 1:n) gives more flexibility and
performance, than storing many uids in one comma separated blob- or
text-field, exploding them all and fetching only that ones that we
actually wanted to have.
This leads to the other topic of roles, or possibly called "attributes"
in general.

As some of you possibly know, I'm trying to get the "Inline-Relational
Editing" to the core of 4.1. So it would be possible that we/I
additionally try to integrate this into TCE. But first, I totally agree
Elmar, we should get a solution for the "How do we do it?", before
implementing anything.


olly
-- 
Oliver Hader
http://inpublica.de/