Adobe
GoLive 6 Dynamic Content Samples
Welcome
Understanding Databases
Feature Index

S A M P L E S


Album
Calendar
Catalog
E-Commerce
Search Engine
Stories
User Forum

Understanding Databases

Each site contains a How it Works page that describes its database design. These pages include pictures like this one, which shows the database for the Stories sample:

A database consists of a number of tables, each of which stores information about a different kind of object. In this example there are three tables: Stories, Editors, and Statuses. A story has an ID, a title, an author, a summary, and various other fields of information. You can picture a table as a giant spreadsheet, where the columns are the fields, and each row is a distinct object. These rows are usually called records. In the current example, if there are eight stories then there are eight records in the Stories table.

A given field always contains information of a single type. Most of the fields in the Stories table are text fields that store either plain text or HTML. The ShouldPublish field is a yes/no boolean field that indicates whether a story should be published. The Priority field is a numeric field. The Editors and Statuses tables contain information about story editors and the publication workflow. Neither table contains much information, but in a more complete design, the Editors table might have additional fields like PhoneNumber, Office, and AreaOfExpertise.

Relationships

The lines that connect the tables show the relationships between them. The line connecting the Stories.Editor field to the Editors.Name field, for example, indicates that information about a story's editor can be found in the Editors table. The labels on the ends of the line, infinity and 1, mean that this relationship is many-to-one between stories and editors: many different stories can have the same editor.

Queries

Databases use a query language called SQL to access information in the database tables. SQL allows you to filter records, sort records, and combine information from multiple tables. The GoLive user interface lets you construct the most common kinds of SQL queries in a natural way, without having to write any code. There are a few samples that use custom SQL to achieve a particular effect. By studying these examples you should be able to create your own custom SQL queries queries.

A database designer will often create permanent queries that are part of the database. These queries look just like tables, because when you combine or filter information from multiple tables, the result still looks like a table. Permanent queries and tables show up together when GoLive displays the tables in a database.

Record Keys

The record key for a table is a set of fields that can uniquely identify each record. These fields are shown in bold in the database diagrams. It is a good idea to make sure that every table has a key, since database lookups can run much more slowly without them.

You can distinguish tables from queries in the database diagrams because the queries do not have a key. Even so, most queries really do have a key, and it is simply that the database program does not recognize it. It a good idea to make sure that GoLive knows about these keys. The Album sample shows how to manually add them so that your pages are more efficient.