Users Addresses

From TYPO3Wiki

List Projects	The Users Addresses - Best Practice Discussion-project list pages	See Current Project Members, Wishlist
		you can help if you like!

Title:	FE users to addresses relations
Main editor: Document status: Major revision: Minor revision: Original model: Table names: Dependencies:	Elmar Hinz Discussion 4 Dez 2005 See page's Last modified date Kasper Skårhøj fe_users, tt_address --

This document is published under the Open Content License The content is related to TYPO3 - a GNU/GPL CMS/Framework available from www.typo3.com

Targets

The superordinate target is to reach best cross extension cooperation.

The primary target of this project is to discuss the different possible database-models.

Based on the results we will set up a recommendation that should find it's way into the official documents like project coding guidelines.

If it comes to certification or awards for extensions or developers the proper implementation of the recommendation should be one of the criterias.

Possible Relations between current fe_user and tt_address:

1:1-model

sr_feuserregister stores address data into fe_user itself. No relation to tt_address. Every user gets exactly 1 address this way.

1:1-model extensions

Please list extensions that use the 1:1 model here:

• Front End User Registration - sr_feuser_register
• Shopping System - tt_products
• Extra fields for FE-user registration - feuserextrafields

Pros

Cons

Not so good to mix account information with user information. You get a big table where both login extensions and address extensions have to look for information. When you want to keep user information for both visitors/employees and fe_users, you have to update user information in two tables. And if an employee also is a fe_user...?

Another big disadvantage is the missing naming convention. For example "sg_userdata" adds a field "firstname" and "sr_feuserregister" adds a field "first_name". The extension manager can only identify fields with exactly the same name. If you install both extensions, you have two fields for the first name...

1:m-model

Every user can get several adresses of different types (home, home2, postatl, holyday, etc.). This model is more compatibel with the kind that email programms store and exchange contacts. (vCard, .vcf)

Every address belongs to one user.

1:m-model extensions

Please list extensions that use the 1:m model here:

Pros

Cons

m:m-model

In real life there are often addresses, that belong to different people, i.e. the delivery address of a company, the home address of a family. I think this model is not very common. But it would be consequent from the philisophy of database normalization.

m:m-model extensions

Please list extensions that use the m:m model here: tt_news

Pros

You can assign many addresses to one person. And when several people live at the same address then this has to be stored only once and not multiple times. This can be helpful if you have a big flat with 80 persons living there and when you have to put all of them into your database.

Cons

There is a clear disadvantage. If you import .vcf from several people with the same postal address for example, you need a tool to connect them to the same tt_address postal dataset. They give you a single one for each person. That probably needs to be conntrolled by hand.

You will have to make very sure, that those users who are allowed to change an address which is valid for multiple people, know what they are doing. In some cases that will be impossible!

Where exactly to put which user information?

I define user information as name, address, telephone, fax, e-mail, company etc.

There are different philosophies about where to store information about the user. Some prefer to put it in fe_users and some prefer tt_address. And different extensions use different approaches... we have to decide one way to go and it could be one of these:

1. No user information in fe_user at all (only username and a relation to tt_address)
2. Some basic information in fe_user and additional information in tt_address (like today)
3. All user information in fe_user, so we don?t have rely on tt_address at all

Pros and cons with 1

Pro:

I like this alternative, because this is the "cleanest" when it comes to the database model(?). We get all account information in fe_user and all user information in tt_address.

I would like to create a special tt_person with which one person gets identified. When he has no or several frontend user accounts then he will still exist in the database.

Con:

An extension which uses only fe_users will have more work because it needs a second table for the addresses now.

Pros and cons with 2

This make things a little messy and we still have to rely on tt_address. And extension developers will never know which table they should extend when they want to add user information fields.

Pros and cons with 3

Pro: Only one dataset has to be edited

Con: Multiple addresses of one user not supported
This is a problem when some user wants to have several user accounts. For different extensions he would maybe need different accounts. Or maybe he wants to have special accounts for near relatives (child, wife).

Not every person (contact) necessarily is a user!

DB model to discuss

I would like to discuss the database model of fe_user and tt_address. I?m no DB expert nor an PHP developer, but I am very interested in getting a good database model as a platform for further development of login and address extensions!

This picture is some kind of illustration to the discussion above on where to put personal information. The model is made in DBDesigner 4.

Peter

---

You do not have a name for the feuser. This is missing because some data is needed to identify him even after the address has been deleted. Why not add an additional table tt_person where all the personal data are stored?

And for the address I would like to see that the ZIP code will come from static data. The town would not need to get entered when someone knows the ZIP code. A wrong ZIP code for a town should produce an error message. We should also define some behaviour for the country. There should be a static country table. The country needs to be translated into different languages, maybe the city needs also 2 different names.

Franz

---

I think that the central entity in a new model should not be fe_users or tt_address, but a "generic" table such as tt_partner or something alike. A "Partner" can be defined as a real person or an organization such as a firm or a club. A partner does not have to be a frontend-user. He can just be a customer, an employee, a church member, whatever. Please refer to the ERD I have proposed in the Partner Framework.

The existing static_info tables should be used wherever possible. The proposal by Franz is great, but will be difficult to implement, because not every country in the worlds makes their ZIP-code directory public. But this might be implemented as an additional static_info table and then be used as a wizard for the ZIP-code field when editing the partner-record. --Dbruehlmeier 20:46, 7 Dec 2005 (CET)

Current Project Members

Wishlist

Relations

Other relating projects to Party Information Framework (edit this, in alphabetical order)

• Commerce Shop Extension This extension use an 1:N relation for addresses and included an own addressmanagement, which should be part of the Party Information Framework.
• Enhanced Rights Management - a pear class for a RBAC / Role Based Access Control.
• Inline Relational Record Editing - 1:n relations for BackEnd-Forms -- Oliver Hader
• Newloginbox development coordination - Ingmar Schlecht and Stefan Strasser
  The User list plugin (pi3) of Newloginbox is related to the Party Framework. If the Party Framework will ship with a user listing plugin, the pi3 of Newloginbox wouldn't be needed any more.
• Users Addresses - relations between fe_user and tt_address, best practice discussion - Elmar Hinz
• dkd_feuser_belogin - relation between fe_user and be_user