-rw-r--r-- | development/pim/dbpaper/intro.tex | 4 |
1 files changed, 2 insertions, 2 deletions
diff --git a/development/pim/dbpaper/intro.tex b/development/pim/dbpaper/intro.tex index c456333..fd790d7 100644 --- a/development/pim/dbpaper/intro.tex +++ b/development/pim/dbpaper/intro.tex @@ -9,23 +9,23 @@ This draft paper describes the database layout of the Opie PIM applications. Design goal is a fast and extendable layout on a sql database to support cross referencing. \subsection{Copyright} Copyright notice -\copyright 2002, Maximilian Rei{\ss} \& Stefan Eilers \& Holger Freyther +\copyright 2002-2004, Maximilian Rei{\ss} \& Stefan Eilers \& Holger Freyther \pagebreak \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 5 attributes: \begin{enumerate} \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 ID: This defines a number to seperate the rows of an entry. UID + ID must be unique for every entry (primary key). \item Type: Describes the type of this entry. \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. |