1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
|
\pagebreak
\subsection{Database Relations}
TODOLIST \{ UID, DueDate, StartDate, EndDate, Completed, Description, Summary, Priority, Progress, Parent, Status \}\\
DueDate can be null \\
StartDate and EndDate are for timetracking reasons.
\\
\\
\noindent
DATEBOOK \{ UID, ID, Item, Value \}\\
ID autoincrement\\
Type element \{ Description, Location, Type, start, end, note, created \}\\
\\
\noindent
RECURRANCE \{ UID, TID, RType, RWeekDays, RPosition, RFreq, RHasEndDate, REndDate \} \\
The TID (TableID) is needed here, since both, TODOLIST and DATEBOOK use it, and in future maybe more.\\
\\
\noindent
ADDRESSBOOK \{UID, ID, Item, Value \}\\
ID autoincrement\\
For contact to a person:\\
Type element \{Title, FirstName, MiddleName, LastName, Suffix, Note \}\\
For contact to a company:\\
Type element \{ CompanyName, Department, Note \}\\
\\
\noindent
POSTAL \{ UID, TID, Type, Street, City, State, Zip, Country \} \\
where Type can be Home, Business as predefined or any other as custom fields (not syncable) \\
\\
\noindent
PERSONAL\_DATA \{ UID, ID, Item, Value \}\\
ID autoincrement \\
Item element \{ Company, JobTitle, Department, Office, Profession, Assistant
\footnote{What is Assistent and Manager ?? (se), and what about multiple assistents? Maybe by same UID but different ID and same Item - ugly(max)}, Manager, Spouse, Children, Gender, Birthday, Aniversary, Nickname, Note, \\
DefaultEmail, Email, HomeWebpage, Homephone, HomeFax, HomeMobil \}\\
\\
\noindent
TABLEID \{ TID, Name, DefaultRep, Version \} \\
TID Autoincrement \\
The first 3 TIDs are set: 0 == datebook, 1 == addressbook, 2 == todolist.\\
The rest can are assigned in order of registration of the service/app.
DefaultRep is the default representation. That are fields from the table of the app itself which should be shown when crosslinked. \\
\\
\noindent
CROSSREF \{ TID1, UID1, Item1, TID2, UID2, Item2 \}\\
Item \emph{x} defines the field-type in the table which should be addressed. It may be empty if no special field should be addressed. \\
Maybe add a field ``discription'' like ``verwaltet'', ``schaut an''
\noindent
Thus, it is possible to crossreference i.e. a Child (Item1 = ``Child'') in the Table PERSONAL\_DATA (TID1 = 0) with an entry in the Table ADDRESSBOOK (TID= 1, Item2 = ````) which stores the data of that child.\\
\noindent
Using ``Item'' to select which element should be referenced (instead using the ID which may only exist in our table) should guarantee that this reference may survive conversions between different formats. I.e.: For converting our Database into a XML-File, the Item should be converted directly into a attribute-name which is placed into a tag. Therefore the cross reference will stay correct!
\noindent
Still unclear is, how to synchronize our database (as XML-File, directly or via C++ Interface access) with outlook or other systems, without loosing this cross reference. We could not expect that this fine granularity or referencing may be supported by other systems...\\
\\
\noindent
ALARM \{ TID, UID, Sound, Day, Month, Year, Time \}\\
TID is needed since more then one app can have alarms and UID is not necessarly unique over different apps. \\
A exclusive table for all alarms\\
\\
\noindent
CATEGORY \{ UID, Parent, Name, ApplicationName, ForeGroundColor, BackGroundColor \}\\
UID due to making syncing sane\\
Parent is used for subcategories \\
\\
\noindent
RECORD\_CATEGORIES \{ TID, UID, CategoryUID \}\\
\\
\noindent
FILES \{ UID, Type, Url \}\\
\\
\noindent
APPLICATION \{ UID, TYPE, URL \}\\
\\
\noindent
LOCATION \{ UID, Name\}\\
|
