[Gpephone-devel] Which database is better to store treestructure?

[Sebastien Armand]

A way to do it that seemed quite interesting to us was to have a
component table for the VEVENT, VTODO, VJOURNAL and VFREEBUSY components
which are very similar in their structures
And to store VALARM and VTIMEZONE in other tables since they differ
quite a lot.

This way the main component table would be like:

uid	| rid	| property 1	| property 2	| ... | x-props
1	| 24	| whole property| ...		|     | all x-props
	|	| as a string	| ...		|     | as 1 string

for example, if property 1 is the ATTENDEE property, the corresponding
database field would be filled with the string:

"ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT;CUTYPE=GROUP:MAILTO:employee-A at host.com
ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT;CUTYPE=GROUP:MAILTO:employee-B at host.com
ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT;CUTYPE=GROUP:MAILTO:employee-C at host.com"

In case there are x-properties, all of them are stored in the last
field. To do this, they are stored under their iCal string
representation.

This way we reduce the parsing step for usual properties and only have
to do it all for the x-properties. But we have to use other tables at
least for VALARM which is too different to be stored in the same one.




On Thu, 2007-04-12 at 04:13 +0200, YANG Lin RD-ILAB wrote:
>  Hi,
> 
> >
> >Do we actually have that many different value types? Currently 
> >we have five fundamental data types in SQL, so it should be 
> >possible to reduce the amount of
> >   value types to these five. 
> 
> Some of the value types is strucutre type. We can convert them into
> strings. The value types is not a big problem.
> I think the more complex thing is that each property may have its own
> parameter and more than one values.
> 
> Take "attendee" property as an example:
> 
> ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;
> RSVP=TRUE;CN=lin;LANGUAGE=en:MAILTO:lin.yang at orange-ftgroup.com
> ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;RSVP=TRUE;
> LANGUAGE=en:PARTSTAT=DECLINED;MAILTO:san.zhou at orange-ftgroup.com
> 
> There're 2 attendee properties here. The first one has a string value 
> "MAILTO:lin.yang at orange-ftgroup.com";
> and several parameters:
>       type			  	value
> CAL_CUTYPE_PARAMETER  		INDIVIDUAL
> CAL_ROLE_PARAMETER		REQ-PARTICIPANT
> CAL_PARTSTAT_PARAMETER		ACCEPTED
> CAL_RSVP_PARAMETER		TRUE
> CAL_CN_PARAMETER			lin
> CAL_LANGUAGE_PARAMETER	en
> 
> 
> The second one has a string value "MAILTO:san.zhou at orange-ftgroup.com", 
> and several parameters
> 	type				value
> CAL_CUTYPE_PARAMETER  		INDIVIDUAL
> CAL_ROLE_PARAMETER		REQ-PARTICIPANT
> CAL_PARTSTAT_PARAMETER		DECLINED
> CAL_RSVP_PARAMETER		TRUE
> CAL_LANGUAGE_PARAMETER	en
> 
> The parameter can't be stored into a property table like this:
> 
> Property1 | property2  | property3 | ...
> Value 1    |  value2      |  value3    |...
> 
> >The only case where this would 
> >not make sense if if we have fields where it is useful to 
> >entrust the data validation to the database.
> >Me might want to take a look at the libeventdb implementation 
> >in GPE which needs to do provide the same.
> >
> 
> There're some differrence.
> In libeventdb, each event has some properties. Each property may
> have one value. The value are all coverted into string.
> Parameters are not supported here.
> The table is like this:
> 
> Uid   |         tag       |      value  |
> Uid1 |  description   | meeting   |
> Uid1 |  start	     | 20070410 |
> Uid1 | ...                 | ...            |
> Uid2 |....
> ...
> 
> 
> 
> _______________________________________________
> Gpephone-devel mailing list
> Gpephone-devel at linuxtogo.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/gpephone-devel
>