[TYPO3-dev] New relational concept for personal data

[bernd wilke]

On Mon, 25 Jan 2010 11:29:14 +0100 JoH asenau wrote:

[...]
> The important thing we have to take care of, is a semantically correct
> separation of tables for persons, locations, dates and content. These
> four tables and a sophisticated system of relations between them would
> be enough for most of the shops, blogs, news, calendars and forums.
> 
> An adress will never contain any name or salutation, since this will
> belong to the person.
> An event will never contain the adress or names of the organizers but
> just a related date and a related content.
> A blog entry will have content and a relation to the person who created
> it. An fe_user will be connected to a person, so the fe_user table just
> needs loginname, password, group, displayname and maybe some information
> about the login behaviour and status. The rest will belong to the person
> related to this fe_user
> 
> If we have the chance to introduce proper normalization to the TYPO3
> database, this would simplify the use of real objects and increase the
> overall performance as well.
> 
> Any other ideas?
> 
> Joey

as Dmitry said: keep it simple for login-purposes as this might be the 
most used case. Therefore a not normalized table might be the best 
solution.
But also this simple mechanism can't be enough.

As nowadays the tendency is for payed content there also is the 
requirement to keep users for a limited time in a paid (premium) 
membership and outside allow a basic membership. this can't be solved 
with the current fe_user-table, as a user is either active with all his 
usergroups or inactive completely.
for current TYPO3-versions I created the extension  "timed 
usergroups" (timed_ugs) as an add-on to the usual login-feature.
I wish this kind of timed relation is possible for each relation between 
these tables. as this is not neccessary for each usage it might be 
realized as add-ons/extensions, so everyone can decide wether to use the 
simple (data-)model or the complex one.

as persons move, change jobs or use another delivery-address I can 
imagine each relation as a timed relation, where it might be neccessary 
to reconstruct an earlier state or just have a history with relations 
(eg. curriculum vita or genealogy)

maybe the amount of fields in each table can also be extended in simple 
steps (add-ons/extensions) so everyone can decide how much storage each 
record will consume and also get the fields he needs.


bernd
-- 
http://www.pi-phi.de/cheatsheet.html