![]() ![]() ![]() ![]() Gravitybox Schedule Primer
Page 55
1998-2004 Gravitybox Software LLC
Chapter 5
Database Access
In Chapter 4, we learned how to save and load information to files. This may work on a
limited scale. In this scenario, all schedules are saved in their own separate files. This
makes searching through multiple schedules extremely difficult. For a serious
application, you need the power of a database. A database can be your repository of
appointments and other information that may be loaded, searched, and saved at will.
You may also only load the information you need. It is possible to accumulate years of
appointment data. You defiantly would not want to load every appointment for 10 years
just to see todays appointments. This is the muscle of a database used in conjunction
with the schedule. This chapter basically creates an example application and perhaps
should be in the examples section; however it pertains more to the database access
category than it does to the example category. This is actually another example
application and its code may be downloaded from the Gravitybox website.
Creating the Table Structure
The first thing to be done is to create the table structure. We need to decide on a
structure that will save all of our information in an efficient format. Let us assume that
we are building an application to schedule patients. We will need to keep up with the
patients as well as their appointments.
We will define a simple scheduling database. We will build an application that displays
the rooms of an office, so the schedule will be in room-only mode. We will display each
day in a separate window and make all schedules MDI child windows. This will organize
the display somewhat so that the user may view one day in a window. We will assume
that we need to add the functionality to setup categories and rooms as well.
We will need three tables: Category, Room, and Schedule. These will save all of the
information that is needed to construct a fully functional database scheduling
application. The first two tables are configuration tables and the last table stores the
appointments. For a bare-bones application we would really only need the Schedule
table, but we are going to allow the user to configure categories and rooms as well.
We start with the Room table. It will store each room that is to be displayed. The table
structure follows.
RoomId AutoNumber
Name String
SortOrder Long Integer
|