From 154ef04f6d74044a750ec89c14f3521b0602e795 Mon Sep 17 00:00:00 2001 From: harlekin Date: Mon, 16 Sep 2002 19:45:19 +0000 Subject: pre draft of the db layout --- (limited to 'development/pim/dbpaper/rel.tex') diff --git a/development/pim/dbpaper/rel.tex b/development/pim/dbpaper/rel.tex new file mode 100644 index 0000000..b7d0990 --- a/dev/null +++ b/development/pim/dbpaper/rel.tex @@ -0,0 +1,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\}\\ + + -- cgit v0.9.0.2