The best way to understand it, is by thinking of a spreadsheet with contact information: names, addresses, phone numbers, email, etc. Each person’s information is contained in a single row, and each column holds one specific piece of data.  If that spreadsheet were a database, each row would be a “record” and each column would be a “field”. In a spreadsheet, you can view many records on a single screen, but very often, you cannot view all the fields for those records that same screen; you must scroll to the right. In a database, data can be presented in a spreadsheet format known as a table (or list), but more commonly, data is presented with all the fields for one record on a single screen, known as a form. In the form view of the data, multiple records can be viewed by “paging” through the data, one record at a time.

In my opinion, there are many advantages a database has over a spreadsheet. One is that custom views of the data, and custom manipulations of the data can be created, saved and re-deployed. For example, with a contact database, it is possible to build reports for mailing labels, call sheets, lists and rosters. It is possible to conduct a search by various criteria, sort the found records, switch to a report layout and store that process to be conducted again in the future. There is virtually no limit to the number of processes that can be stored in a database.

Another advantage is that a database can be used by more than one person simultaneously throughout an office, or over the internet. Spreadsheets can only be used by one person at a time.

I would be remiss if I didn’t acknowledge that very sophisticated data manipulations can be constructed and saved with spreadsheets. However, only someone capable of building that type of spreadsheet is able to use it, and even the most sophisticated users have been known to make mistakes which “break” underlying caclulations.  With a database, it is possible to build a sophisticated application and to establish a set of user rights and privileges to protect the structure and contents of the database.

Related Databases

Sometimes, data needs to be stored separately to be made most useful. Related databases are put into use when there is a “one to many” relationship between data types. The best way to define a “one to many” relationship is by describing an example.

Imagine an invoicing system. There are customers, invoices and items. Customer records might consist of company, address, phone, email and contact name. Item records might consist of name, description, SKU, cost and price. Each invoice would contain the ordering customer’s details and the ordered item’s details. Each customer would have many invoices, and each invoice would have many items. In order to build a system that would customer details and item details onto an invoice, each data type would need to be stored in a separate database table.

FileMaker Pro

I am a proponent of FileMaker Pro for several reasons.

For the developer, a FileMaker Pro solution it is easily taught to users, and for clients and end users, it is easily learned.

Depending on the client and the user community, as people become more sophisticated in their understanding of the application, users can be empowered to make changes to design and functionality. Some of my clients welcome this evolution and take over the responsibility for maintenance and development, and others reject the concept and prefer to bring all requests for database enhancements to me.

Lastly, for me anyway, it is an enjoyable medium to use.