Although, at the simplest level databases and spreadsheets are similar in that they contain tabular data with values organised in columns and rows, a distinction between the two applications can be made based on their intended functions. Spreadsheet applications, based originally on paper accounting worksheets, specifically aim to deal with mathematical data (e.g. accounts) and to perform on-the-fly calculations and processing. Database applications, however, are designed to store data of a wide variety of types and to provide complex searching and reporting functions upon this data.

Spreadsheets

Spreadsheets are arguably a simpler format than databases and generally consist of single or multiple ‘sheets’ containing tabular data. The data itself can be used within a spreadsheet to create additional values (e.g. column totals) via formulas and can also be used to generate any number of graphs and charts which in turn can be placed within a sheet or exist as a sheet themselves. Formatting, of either cells or of the values within them, can also be an important element of a spreadsheet and can be often used to convey meaning or highlight specific elements. Data entry and use of a spreadsheet can also be controlled to limited degree through the use of protected or locked cells and cell-specific formatting (e.g. rounding values to limited decimal places or displaying them in currency formats).

Databases

In contrast to spreadsheets, which largely share a similar fundamental design and approach, databases can be divided into a number of types (known as models or architectures). The two of these most commonly found in use in archaeology are Flat File and Relational databases although there is a slowly growing movement towards the use of Object-oriented database models. The flat file model is broadly similar to that of a spreadsheet in that tabular data is organised into horizontal rows, representing records, and vertical columns or fields representing a type of value or attribute to be recorded. In flat file databases there can be an inherent looseness in the way that data is defined and recorded along with a significant duplication of sets of information from record to record. The relational model addresses these and other issues by requiring a data structure to be pre-defined and by splitting related groups of attributes into separate tables which are then linked together through key fields (Primary or Foreign keys). In contrast to spreadsheets and many flat file databases, most database applications allow (and in fact require ) the strict specification – in terms of field length, data type (numeric, etc.) of the data types to be recorded

As with charts generated from spreadsheet data, databases can potentially consist of more than just data values. Forms, used for data entry or for running queries, are often the only way in which many users interact with databases and can be viewed as part of the database but separate from the data itself. Likewise, the queries and results or reports that result from user interaction may also be considered as ‘non-data’ components of a database.