Download Spreadsheet vs. Database article

Spreadsheet vs. Database
Office Computing
August 1998 • Vol.9 Issue 8
Spreadsheet vs. Database
Which One Offers The Best View Of Your Data?
You probably understand how to use most of Microsoft
Office's parts, but what about the Access application? You
know it's a database for keeping information, but the details
of using such a tool aren't so clear. Besides, you keep your
data in a spreadsheet, and it works just fine.
Meanwhile, the number of spreadsheets you work with is
increasing and you're doing lots of tweaking to get them to
pass data back and forth. There must be an easier way than
scrolling through rows of data to find answers. Maybe it's
time to revisit that database thing. Understanding when to use either a
spreadsheet or database for your records can mean the difference between facing
a bunch of overwhelming numbers and operating a business intelligently.
A database is simply an organized collection of information. Users record many
types of information in databases such as inventories, projects, addresses,
customers, and invoices. Recording lists of information in a database makes it
easier to organize and retrieve it later. Before computers, users kept databases in
file cabinets, in card files, and on graphed paper, even though they weren't always
called databases. The key difference between these storehouses and database
applications is the relational nature of the digitized databases.
Let's say you kept a list of contacts in a card file, with each card listing the
contact's name, business, and address. If you made several contacts at the same
business, you would end up rewriting the same address on each card. With a
relational database you enter the address once for that business, and then each
contact can be linked to that business and address. Through this behind-thescenes linking, every time you pull up a contact, all relevant information appears
as if it were stored in the same record. Relational databases keep the file size
smaller, make data access faster, and reduce the chance of incorrect information
by recording everything only once.
Spreadsheets tend to stand in for databases because spreadsheets are easy to use
and familiar to many users. Just create some categories in the columns, enter
some data, and you're done. Many users also get intimidated by the less-thanintuitive format of a database application. Despite their familiarity, however,
spreadsheets are a poor choice for data management. Their strength is in
crunching numbers, not organizing records.
The Spreadsheet Solution.
Spreadsheet applications such as Microsoft Excel and Lotus 1-2-3 exist largely to
process numbers for budgets, forecasting, and other mathematical calculations.
The spreadsheet's format of columns and rows, like that of a multiplication table
or ledger book, is familiar to most users. Other features such as the ability to
create complex formulas and automate computations make a spreadsheet
preferable over manipulating figures on paper.
The types of data best suited to a spreadsheet include "what-if" scenarios such as
budgets, involved computations such as taxes, or financial models such as
product and sales analyses. Inventory ordering and other rote calculations that
can be automated work well in a spreadsheet. These applications are also strong
in graphing and charting data that helps interpret numbers. If much of the data
you work with is numerical and requires computations or graphing, open a
spreadsheet. Do not even try detailed financial analysis with a database. If
needed, however, you always can store raw numbers in a database and export
relevant records to a spreadsheet when you need serious number crunching.
This spreadsheet is a
limited tool for
managing information.
Problems visible here
are inconsistent entries
in categories such as
Level and lack of space
for notes. This will
make managing the
information difficult
later.
This workhorse nature of spreadsheets makes
them a common choice for storing lists.
Microsoft estimates that more than 70% of Excel
users use it as a database. While some popular
spreadsheets include a few database functions
such as data entry forms and some data controls,
these functions are less comprehensive than
those in a database. For example, let's say you
want a list of all students in a class with a B
average or higher. If you kept these records in a
spreadsheet you would perform a sort; in a
database you would run a query, or search. A
sort would list all the students from the ones
with the highest grades to the lowest. A query
would produce a table of only those students
with the desired grade. Furthermore, a query can
provide much more detailed responses such as a
list of just seniors with at least a B average who
have taken calculus. You can't do this by sorting.
Databases also outperform spreadsheets in the
area of data integrity. A database can place
better controls that restrict data to specific ranges and default values ensuring
consistent and correct data. If you keep an inventory, you might want to make
sure item types are restricted to things such as "disposable" or "equipment" and a
receipt is filed for "equipment" items more than $100. A database can restrict
particular data to a list of acceptable values, in this case "equipment" or
"disposable," and refuse incorrect data with a detailed error message. Either a
database or spreadsheet could have a receipt reminder pop up each time an item
more than $100 is entered. Only the database, however, can cross-reference the
data to make sure the item is an "equipment" item as well as more than $100
before accepting the entry.
You can consider sticking with your spreadsheet-as-a-database approach if you
work with a small number of records; 2,000 or less is a very manageable number.
If you regularly create new spreadsheets to keep your information organized, you
should probably move to a database application.
You also can consider using a spreadsheet as a database if the relationships
between the data are simple. A simple list of customer orders could be organized
easily in a spreadsheet. However, if you need to link employee data to customer
orders and to payroll (say your salespeople earn a commission based on the size
of their orders), the relationships become more complex and better suited to a
database application.
The problems start when the spreadsheet can't keep up with your data needs.
Spreadsheet applications don't provide the depth of functions that ensure good
data such as restricting data to specific ranges or formats and maintaining links
among related data. Databases are better at providing data access by supporting
complex searches, intensive data entry, and multiple user access. If you currently
use a spreadsheet to store data, ask yourself the following questions:
•Do changes made in one spreadsheet force you to make changes in another?
•Do you have several spreadsheets containing similar information (such as
separate sheets with inventory for Dallas, D.C., and Detroit)?
•Do you want some data to be hidden from some users?
•Can you see all pertinent data on one screen or do you have to keep scrolling?
•Are several people accessing the data at the same time?
•Do you have a hard time viewing specific sets of data you want?
If you answer yes to at least two of these questions, you should think about
moving data to a database application.
The Next Step.
Detroit's Fresh Rolls bakery is a good example of a small business that outgrew
the spreadsheet approach. When Fresh Rolls had only two employees and offered
a few baked goods Owner Harold Cephus tracked products sold, supplies
purchased, and goods ordered on Excel spreadsheets. He printed monthly
spreadsheets to check his progress and see where he could make changes.
Through the years Fresh Rolls grew to a 10-person operation, offering specialized
wedding cakes and a sit-down café. Cephus says keeping track of inventory with
monthly spreadsheets became difficult. It took a long time to sort through the
order spreadsheets to find the status of specific orders. The spreadsheets grew too
numerous to manage. His assistant couldn't understand the system of spreadsheets
and would avoid using them. By the time Cephus was ready to open a second
shop, he was looking for a better way to track his business information.
Cephus' choice, like yours, deals with two types of databases: standalone and
server-based. Standalone databases (Microsoft Access, Lotus Approach, Corel
Paradox) can run on a single PC or share data among several users. Many
standalone databases are simple enough for a novice to start building immediately
and rugged enough to build multiple-user enterprise applications.
Server-based database applications (Oracle products, Microsoft SQL Server, IBM
dBase) store all data on a server (a computer that makes data available to a
network), while the applications that access the data reside on the workstations.
They can handle massive amounts of data and include features that make constant
multiple-user access fast and reliable. You'll need professionals to help you set up
these heavy-duty applications.
Standalone Databases.
Most standalone databases consist of several parts—tables, queries, forms, and
reports—that work together to organize and present data. The foundation of the
database is the table, which holds the actual data, defines the data categories (or
fields), and links related data. You use queries to find and retrieve specific
records. Forms are templates you can create to easily view, enter, and change
data in the tables. Reports are templates for the printed output.
A properly organized
database provides powerful
tools for sorting and
displaying information in
relevant ways.
These parts work together when the user
opens the database application. Users see a
form where they enter data, which is stored
in tables. Users may enter criteria in a form
to search for data, and the form runs a query.
The information returns in a form on-screen
or printed in a report if the data must be on
paper.
Several popular standalone databases make it
easy to get started. Tutorials and wizards
(pop-up screens that guide a user through
performing specific tasks) appear and help
novices become productive immediately. If your database requirements become
more complex, you'll have to spend time learning the application's tools through a
manual or class or hire a professional developer.
You usually can move existing data from another source into a database fairly
smoothly. The process is sometimes as simple as choosing a menu item to import
data. Most standalone databases can import data from text files, spreadsheet files,
and other databases.
Server-Based Databases.
There may come a point with an expanding business when a standalone database
is insufficient to hold the records.
Brigadoon.com, a small Internet service provider, found this out. Brigadoon.com
grew in 2 1/2 years to almost 20,000 users. Each user account included billing
information, Internet usage records, and a history of technical support.
Brigadoon.com kept this data in an Access database designed by the information
systems (IS) staff. The database was quickly growing and with eight users
constantly accessing it, it was quickly growing sluggish. By the time
Brigadoon.com reached 30,000 users, the accounts staff members could take 20minute coffee while they waited for the shared database to load on their
workstations.
Brigadoon.com's experience demonstrates the limits on using standalone
databases. As more users need to access data or data needs to be available
constantly, standalone database performance suffers. When this happens it's time
to consider a server-based database.
These setups generally consist of three parts: the database management system
(DBMS), the user application, and queries. The DBMS resides on the server and
does the work of storing and managing the data including allowing access,
processing queries, and running utilities. The application is the front end that
users see when adding information or entering criteria for queries. The
application usually resides on workstations and may be included with the DBMS
package, be custom-written by a programmer, or even be a standalone database
such as Access. Queries are written in a special programming language that runs
between the application and the DBMS. Structured Query Language (SQL) is one
of the most popular query languages used to request information from a database.
Which To Use?
The difference between standalone databases and server-based databases is the
latter requires a server. This may be simple, but the server-based solution
provides a few advantages over standalone.
The most significant is that many users can access, add, and change data
concurrently. While multiple users can share standalone databases on a server to
view data, only one user at a time can add or edit records. In addition the
performance of a shared standalone database typically slows down with each user
added. A server-based database separates the data storage and application
functions across more than one machine, easing the load on both and improving
performance.
Both a DBMS and a standalone database can hold massive amount of records. A
DBMS has an advantage of residing on a server (and on presumably servercapacity hardware) and not having to share disk space with the application stored
on workstations.
With tasks such as automatically compressing data, coordinating backups,
tracking usage statistics, and recovering data in the event of a power failure,
utilities included with a large database engine provide even more efficiency and
safety than a standalone.
Lastly, with a server-based database all data is stored in one place for a single
point of administration. Users can centralize management decisions on issues
such as hardware upgrades and personnel support. This provides a single point of
failure, but this risk can be minimized with tools such as tape backup and disk
mirroring, replicating a hard drive's contents on another drive.
Consider moving to a server-based database if the following apply:
• Many processes must run in parallel like backups while the database is open.
•Users must access the data at any time.
•Several users need to add or edit data during the same hours.
•Your current database takes a long time to open or to run queries.
A server-based platform involves an investment. Besides sturdy server hardware,
you will need to hire a programmer to develop the front-end application and
queries. You'll also need a database administrator (DBA) to build and manage the
DBMS structure.
Migrating data from other applications to a server-based database is more
involved and may be part of the professional developer's service. Many DBMS
applications provide utilities for importing data from other sources.
Find A Program.
Once you have an idea of which platform would best manage your data, list your
data needs before buying a program by answering these questions:
•What data are you working with (numbers, text, graphics) and what must happen
with it (reports, searches, data storage)?
•What type of information or analysis are you looking to get from your data?
•Will you import or export much data?
•How do you want users to access data?
•How does data flow in your current process?
After you complete this list, visit a software store or browse the Internet
(Yahoo!'s Computers, Software section lists many software packages) for
information on specific applications. Start by investigating applications you
already have in a software suite. There are also quite a few applications written
specifically for various businesses from art stores to toy manufacturers.
Programmers often write these programs on top of an existing database
application, so understanding how databases work is still helpful. These programs
are sold commercially or as shareware or freeware (low-cost and free software)
for the finding (http://www.download.com is one good site for shareware). If
you're looking for a professional developer, try listings on the Web or the yellow
pages under Computer Consultants.
Well-organized data is crucial to running informed businesses. With good data
management, business data becomes business intelligence for sound decision
making.
by Tracey Dishman