author | eilers <eilers> | 2002-10-09 14:36:57 (UTC) |
---|---|---|
committer | eilers <eilers> | 2002-10-09 14:36:57 (UTC) |
commit | 273d5329e29c43b287876202de2f0c500a312b7b (patch) (side-by-side diff) | |
tree | 04dfc8d29dd57dd2bea76beb98f154825ba178b3 | |
parent | f9f2d227b3cfbc2187b4f7f535fc59f9735798d0 (diff) | |
download | opie-273d5329e29c43b287876202de2f0c500a312b7b.zip opie-273d5329e29c43b287876202de2f0c500a312b7b.tar.gz opie-273d5329e29c43b287876202de2f0c500a312b7b.tar.bz2 |
Changes regarding the tips of Robert Wittams
-rw-r--r-- | development/pim/dbpaper/dbpimpaper.tex | 1 | ||||
-rw-r--r-- | development/pim/dbpaper/intro.tex | 63 | ||||
-rw-r--r-- | development/pim/dbpaper/rel.tex | 22 | ||||
-rw-r--r-- | development/pim/dbpaper/tables.tex | 23 |
4 files changed, 50 insertions, 59 deletions
diff --git a/development/pim/dbpaper/dbpimpaper.tex b/development/pim/dbpaper/dbpimpaper.tex index f664a05..fe060de 100644 --- a/development/pim/dbpaper/dbpimpaper.tex +++ b/development/pim/dbpaper/dbpimpaper.tex @@ -36,6 +36,7 @@ 0.0.5 & Holger Freyther & zecke@handhelds.org \\ \hline
0.0.6 & Stefan Eilers & eilers.stefan@epost.de \\ \hline
0.0.7 & Maximilian Reiß & harlekin@handhelds.org \\ \hline
+0.0.8 & Stefan Eilers & eilers.stefan@epost.de \\ \hline
\end{tabular}
}
diff --git a/development/pim/dbpaper/intro.tex b/development/pim/dbpaper/intro.tex index 0a26b90..c456333 100644 --- a/development/pim/dbpaper/intro.tex +++ b/development/pim/dbpaper/intro.tex @@ -18,17 +18,18 @@ Copyright notice \section{Relations} \subsection{About Cross Referencing and Horizontal Data Storage} Before you read on, it may be helpful to get some information about the solution of ``horizontal'' data storage into the tables and cross referencing. -Some of the tables are just using 4 attributes: +Some of the tables are just using 5 attributes: \begin{enumerate} -\item UID: This countains an unique ID for the complete entry. -\item ID: This defines a number to seperate the rows of an entry. +\item UID: This countains an unique ID for the complete entry. An entry may consist of multiple +rows, seperated by ID. +\item ID: This defines a number to seperate the rows of an entry. UID + ID must be unique for every entry. \item Type: Describes the type of this entry. -\item Value: And the data which was described by ``Type'' is stored here. +\item Priority: For instance: Your default email-address will get the priority 1 and the other 2.. . 0 means ``not defined''. +\item Value: The data which was described by ``Type'' is stored here. \end{enumerate} -These kinds of tables are very flexible in what they may contain, due to the fact that the ``Type'' may be without any constraint. Therefore it is perfectly for storing personal information, which may change in the future, or should be increased. The other advantage is the fact that these tables are automatically convertable into XML: -The ``Type'' has just to be converted into an ``attribute'' in a XML-tag. Thats all, and that will work for all future Types ! - +These kinds of tables are very flexible in what they may contain, due to the fact that the ``Type'' may be without any constraint. Therefore it is perfectly for storing personal information, which may change in the future, or should be increased. +\\ Let's see how such an entry may look like for the table ``ADDRESSBOOK'': \begin{tabular}[ht]{|l|l|l|l|} @@ -44,69 +45,63 @@ Let's see how such an entry may look like for the table ``ADDRESSBOOK'': \end{tabular} \\ \\ -We need some additional information about this entry, which is stored into the table ``PERSONAL\_DATA\_CONTACT'': +We need some additional information about this entry, which is stored into the table ``PERSONAL\_DATA'': \\ \\ -\begin{tabular}[ht]{|l|l|l|l|} +\begin{tabular}[ht]{|l|l|l|l|l|} \hline -\underline{UID} & \underline{ID} & Type & Value\\ +\underline{UID} & \underline{ID} & Type & Priority & Value\\ \hline - 2345& 00& Email& eilers@sra.uni-hannover.de, eilers.stefan@epost.de\\ + 2345& 00& Email& 1& eilers.stefan@epost.de\\ \hline - 2345& 01& DefaultEmail& eilers@sra.uni-hannover.de\\ + 2345& 01& Email& 2& eilers@sra.uni-hannover.de\\ \hline - 2345& 02& HomeWebPage& www.sra.uni-hannover.de/$\sim$eilers/\\ + 2345& 02& WebPage& 1& www.sra.uni-hannover.de/$\sim$eilers/\\ \hline \end{tabular} \\ \\ -The last question is: How to get these information together? This is the job of the cross-referencing-table\footnote{We expecting that the table ``PERSONAL\_DATA\_CONTACT'' was registered in the table ``TABLEID'' as table ``03''!}: +The last question is: How to get these information together? This is the job of the cross-referencing-table\footnote{We expecting that the table ``PERSONAL\_DATA'' was registered in the table ``TABLEID'' as table ``03''and ADDRESSBOOK with ``01''!}: \\ \\ \begin{tabular}[ht]{|l|l|l|l|l|l|} \hline -\underline{TID1} & \underline{UID1} & \underline{Type1} & \underline{TID2} & \underline{UID2} & \underline{Type2} \\ +\underline{TID1} & \underline{UID1} & \underline{ID1} & \underline{TID2} & \underline{UID2} & \underline{ID2} \\ \hline - 01& 1231& & 03& 2345&\\ + 01& 1231& (NULL) & 03& 2345& (NULL) \\ \hline \end{tabular} \\ \\ -Type was left empty, due to the fact that we wanted to link the complete entry and not some rows of the entry. +ID was left empty, due to the fact that we wanted to link the complete entry and not some rows of the entry. \\ In some cases, it may be useful to reference in a much more smaller granularity than complete entries. What should we do, if we want to store the children of a person ? -The easiest way is to store the children into the table ``PERSONAL\_DATA'':\footnote{We expecting that the table ``PERSONAL\_DATA'' was registered in the table ``TABLEID'' as table ``05''!}\\ +The easiest way is to store the children into the table ``PERSONAL\_DATA'':\footnote{We remember that the table ``PERSONAL\_DATA'' was registered in the table ``TABLEID'' as table ``03''!}, too.\\ \\ -\begin{tabular}[ht]{|l|l|l|l|} +\begin{tabular}[ht]{|l|l|l|l|l|} \hline -\underline{UID} & \underline{ID} & Type & Value\\ +\underline{UID} & \underline{ID} & Type & Priority & Value\\ \hline - 2344& 11& Children& Amaly, Karl, Clarissa\\ + 2345& 11& Child & 0 & Amaly \\ \hline -\end{tabular}\\ -\\ -and reference it again with the table ``ADDRESSBOOK'':\\ -\\ -\begin{tabular}[ht]{|l|l|l|l|l|l|} + 2345& 12& Child & 0 & Karl \\ \hline -\underline{TID1} & \underline{UID1} & \underline{Type1} & \underline{TID2} & \underline{UID2} & \underline{Type2} \\ + 2345& 13& Child & 0 & Clarissa\\ \hline - 01& 1231& & 05& 2344&\\ -\hline -\end{tabular} -\\ +\end{tabular}\\ \\ + But what happens if you want to store additional information about the children, as there mobile phone numbers, etc? In this case we need an entry in addressbook and a reference to this entry. Lets expect ``Amaly'' was stored in the table ``ADDRESSBOOK'' with UID 9213 and Karl with UID 7654. A cross-reference will look like this:\\ \\ \begin{tabular}[ht]{|l|l|l|l|l|l|} \hline -\underline{TID1} & \underline{UID1} & \underline{Type1} & \underline{TID2} & \underline{UID2} & \underline{Type2} \\ +\underline{TID1} & \underline{UID1} & \underline{ID1} & \underline{TID2} & \underline{UID2} & \underline{ID2} \\ \hline - 05& 2344& Children& 01& 9213& \\ + 03& 2345& 11& 01& 9213& (NULL) \\ \hline - 05& 2344& Children& 01& 7654& \\ + 03& 2345& 12& 01& 7654& (NULL) \\ \hline \end{tabular} \\ diff --git a/development/pim/dbpaper/rel.tex b/development/pim/dbpaper/rel.tex index b7d0990..967155d 100644 --- a/development/pim/dbpaper/rel.tex +++ b/development/pim/dbpaper/rel.tex @@ -29,30 +29,24 @@ 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 \}\\ +PERSONAL\_DATA \{ UID, ID, Type, Priority, 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 \}\\ +Type element \{ Personal, Company, University, Birthday, Aniversary, Gender, Child, Jobtitle, Department, +Office, Profession, Assistant, Nickname, Spouse, Manager, Note, Email, WebPage, Phone, Fax \}\\ +Priority: Highest = 1, Undefined = 0\\ \\ \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. \\ +DefaultRep is the default representation. That are fields from the table of the app itself which should be shown when crosslinked\footnote{This should be described much more detailed to be clear! (se)}. \\ \\ \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. \\ +CROSSREF \{ TID1, UID1, ID1, TID2, UID2, ID2 \}\\ +ID\emph{x} defines the ``line'' in the table (grouped by UID) which should be linked. 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...\\ \\ diff --git a/development/pim/dbpaper/tables.tex b/development/pim/dbpaper/tables.tex index ac28a47..64ae02d 100644 --- a/development/pim/dbpaper/tables.tex +++ b/development/pim/dbpaper/tables.tex @@ -62,7 +62,7 @@ Recurrence:\\ \begin{verbatim} CREATE TABLE RECURRENCE ( UID int NOT NULL UNIQUE, - TID int NOT NULL + TID int NOT NULL RType int, RWeekDays int, RPosition int, @@ -128,11 +128,12 @@ Personal data: \\ \hline \end{tabular} \begin{verbatim} -CREATE TABLE PERSONAL_DATA_CONTACT ( - UID int NOT NULL UNIQUE, - ID int AUTOINCREMENT, - Ident text, - Value text, +CREATE TABLE PERSONAL_DATA ( + UID int NOT NULL UNIQUE, + ID int AUTOINCREMENT, + Ident text, + Priority int, + Value text, PRIMARY KEY(UID,ID) ); \end{verbatim} @@ -171,10 +172,10 @@ CrossRef: \\ CREATE TABLE CROSSREF ( TID1 int NOT NULL, UID1 int NOT NULL, - Item1 int NOT NULL, - TID2 int MOT NULL, + ID1 int NOT NULL, + TID2 int NOT NULL, UID2 int NOT NULL, - Item2 int NOT NULL, + ID2 int NOT NULL, PRIMARY KEY() ); \end{verbatim} @@ -194,7 +195,7 @@ CREATE TABLE CATEGORY ( UID int NOT NULL UNIQUE, Name text, ApplicationName text, - ForeGroundColor text, <-- maybe hex? + ForeGroundColor text, <-- maybe hex? BackGroundColor text, PRIMARY KEY(UID) ); @@ -237,7 +238,7 @@ CREATE TABLE APPLICATION ( \end{verbatim} \noindent -Location: \\ +Location: \\ \begin{tabular}[ht]{|l|l|} \hline \underline{UID} & Name \\ |