ReadySetGit/Design-Persistence.md

##### Project:
::PROJECTNAME

##### Internal Release Number:
::X.Y.Z

##### Related Documents:
- [Design](Design) > Design Persistence
- ::LINKS TO RELEVANT STANDARDS
- ::LINKS TO OTHER DOCUMENTS

---

### Overview

*TODO: Answer the questions below to help you design needed persistence
features. Some example text is provided. Add or delete text as needed.*

#### What are the most important facts that a developer should know about persistent data storage in this system?
::PARAGRAPH OR BULLETS

#### What are the ranked goals for persistence in this system?

1. ::[Expressiveness](Glossary-Standard-Terms#dg_expressiveness)
2. ::[Ease of access](Glossary-Standard-Terms#dg_easy_access)
3. ::[Reliability](Glossary-Standard-Terms#dg_data_reliability)
4. ::[Data capacity](Glossary-Standard-Terms#dg_data_capacity)
5. ::[Data security](Glossary-Standard-Terms#dg_data_security)
6. ::[Performance](Glossary-Standard-Terms#dg_data_performance)
7. ::[Interoperability](Glossary-Standard-Terms#dg_data_interop)

### Central Database

#### What is the logical database design?

::The logical database design is described in this [UML
model](LINK-TO-MODEL) or this [ER diagram](LINK-TO-DIAGRAM).

::Additional logical constraints on the database are:

- ::Students can repeat a course (and thus have two records for the
  same course in their transcript), if and only if they got a
  grade of "C-" or lower, or the course number is 198, 199, 298,
  or 299.
- ::A grade of "A+" is valid only for transcript entries during or
  after Fall 1990. Prior to that term, the highest possible grade
  was an "A".
- ::LOGICAL CONSTRAINT THAT CANNOT BE EXPRESSED IN THE DIAGRAM
- ::LOGICAL CONSTRAINT THAT CANNOT BE EXPRESSED IN THE DIAGRAM

#### What are the physical tables and views?

::The physical database design is described in this [UML
model](LINK-TO-MODEL) or this [ER diagram](LINK-TO-DIAGRAM).

#### How will objects in the application be stored in the database?

::We will use one database table for each class, and one row in the
database for each persistent instance of that class.

::We will use a [library](LINK-TO-LIBRARY) to do our
object-relational mapping. (E.g., torque, castor, JDO,
ADO, hibernate)

#### What database access controls will be used?

::A database user account has been created that has access to the
needed application database tables. The username and password for
this account is stored in a configuration file read by the
application server. The database limits login by that user to only
the IP-address used by the application server.

#### Is this application's central database accessible to other applications?

::Yes. The database is an important point of interoperability for new
applications to be added later. The database itself provides support
for access controls and checks validity constraints so that a
defective application cannot corrupt the database.

::No. This database should always be accessed through
this application. All relevant pieces of information are available
through the application interfaces. The database itself does not
protect against data corruption that could be caused by
other applications.

### File Storage

#### What data needs to be stored in files?

::Nothing is stored in files, everything is in the database.

::The server stores most data in the database, but mailing list
attachments are written to files on the server hard disk.

::All user documents are stored in files on their computer hard disk.

#### What are the conventions for directory structure and file naming?

::N/A

::Files are stored on the server as
   
```/var/data/attachments/msgNNNN-MMM.dat```

::Users store files anywhere on their computer, with the filename
extension ```.TST```.

#### What file system access controls will be used?

::N/A

::Files for message attachments are only readable and writable by the
mailing list archiving process that runs as operating system
user "archdaemon".

::Users can use whatever file permissions they like.

#### What file format will be used?

::The [XYZ](LINK-TO-STANDARD) standard file format.

::A java .properties file.

::A window's .ini file.

::An XML file using [this DTD file](LINK-TO-DTD).

::A simple text file with the following format: ...

::A custom binary file in the following format: ...

### Distributed Storage

#### What information (if any) will be stored on client machines? For how long?

::A cookie will be stored on the user machine for the purpose of
identifying a user session. When the user logs out or closes their
web browser, the cookie is deleted. Most browsers will not even
write this cookie to the disk.

::The a cookie is stored on the user's computer that is equivalent to
their password (but it is NOT actually their password). This cookie
is needed for the auto-login feature. The cookie lasts a maximum of
30 days, and it can only be used from the same IP address.

::User preferences for color scheme are stored in cookies in
their browser. This information is not at all sensitive, so it is
kept indefinitely.

::All the user data will be stored on files on their computers.

### Persistence Mechanisms Checklist


#### Expressiveness: To what extent has this been achieved?

::2-4 SENTENCES

#### Ease of access: To what extent has this been achieved?

::2-4 SENTENCES

#### Reliability: To what extent has this been achieved?

::2-4 SENTENCES

#### Capacity: To what extent has this been achieved?

::2-4 SENTENCES

#### Security: To what extent has this been achieved?

::2-4 SENTENCES

#### Performance: To what extent has this been achieved?

::2-4 SENTENCES

#### Interoperability: To what extent has this been achieved?

::2-4 SENTENCES

#### Has the persistence design been communicated to the development team and other stakeholders?

::Yes, everyone understands. Feedback is welcome.

::No, this is a risk that is noted in the [Risk Management](Project-Plan#risks)
section.