[Typo3-dev] I don't want to fork!

[JoH]

>> I think both should remain, but without redundant data. All info
>> about the account should be in fe_user, and all info about the
>> user should be in tt_address. And then you have a relation
>> between them.
>>
>> Example:
>> Move all the fields like Name, Address, Phone, Fax, www, Image,
>> MSN/AIM/Yahoo screen name etc from fe_user to tt_address.
>> Instead add a field (like the Groups field) in fe_user where you
>> just choose a person from tt_address. Voila!
>>
>> But! I guess this is even more difficult to realize than other
>> solutions, but IMHO it it the most "clean" one. I mean, isn´t
>> this the reason why we use a relational database like MySQL?  ;-)
>>
>>
>> /Peter Kindström
>
> The advantage is, that you can relate multiple adresses to one
> account. I guess that was the original idea to set up two tables.

Exactly - and this is how these tables are used in many TYPO3 installations
I know of.
fe_users is for real users (be it with or without login) that are using the
site itself or services offered by the site owner (like newsletters, shops
...)
www.flyerking.de for example is using the fe_users table for managing
account info of the user himself.
Things like "delivery adress", "other billing adress" or "contact person"
are handled with tt_adress.
Therefor we added a field "owner" to the adress table, so that the logged in
fe_user can only see or edit adress records belonging to him.

> The first disadvantage is that you need to query to query two tables,
> which makes things more complex for most extensions.
>
> The second disadvantage is, that it seems impossible to integrate this
> complexity into already existing extensions.
>
> The compromise would be to put a *main* address into fe_user, which
> serves for most cases and to use tt_address only for *additional*
> addresses. Then the mayority of extensions can use the simple
> approach.

IMHO it's not a compromise but the only acceptable solution to serve all
possible situations and stay backwards compatible.
The only thing you have to do is: Blow up tt_adress with all necessary
fields and make it compatible to existing software packages that handle
adresses.
A complete "no-no" is i.e. the fact that "adress" is just one field instead
of separate fields like "street", "nr", "additionalinfo" (like: 2nd floor,
Appartment 123) and there are others as well.
Additionally you will need a field "owner" which will be a relation to the
fe_users table.

> The price for this compromise is, that in special cases you have to
> query two tables if you are searching for an address .

You don't have to pay the price if you insert one field tt_adress.
fe_users will get a TCA based checkbox modifying the TCEform:
Use adress data from tt_adress? [ ]
Maybe a wizard would be good here, to create the related adress directly
while editing the fe_user account.
tt_adress will get a checkbox:
Is main adress of the owner? [ ]

This way you keep the possibility to do it the "oldschool" way _and_ for
users who don't want to query two tables there's still the option to use
tt_adress only.
While doing things like fe_user registration from the FE you can check, if
the TCA setting points to tt_adress or fe_users and fill in the data to the
correct table.
Requires a rewrite of fe_adminLib.inc though ...

What do you think of this approach?

Joey

-- 
Wenn man keine Ahnung hat: Einfach mal Fresse halten!
(If you have no clues: simply shut your knob sometimes!)
Dieter Nuhr, German comedian
openBC: http://www.openbc.com/go/invuid/Jo_Hasenau