Once the database is up and running and
populated with data, you will need a way of talking to it.
Essentially, there are two ways of doing that: connecting to the
database directly using a command shell or by connecting to the database
over the network using sockets (if that database allows such interaction).
Command shells are pretty common and come bundled with
just about every database. These are usually simple filters which allow you to log
on to the database, execute commands and receive output. They can either
be very simple command-line shells or nice, fanciful graphical user
interfaces. Whichever the case, command shells provide access to the
database from the machine on which the database is running. We will see
more examples of this methodology when we discuss CGI-based web
databases in part three
Socket-based middleware does the exact same thing,
but over a network. Thus, with a socket-based system, I could send
commands to my database in Los Angeles while I am working in Singapore
by perhaps using TCP/IP over the internet to connect to my
database. We will see more examples of this when we look at JDBC-based
web databases in part four.
You will almost certainly want to get access to a
database and its command shell just to try things out during this tutorial.
Hopefully your ISP will provide a database to test, but if not, you can
probably install a database like Microsoft Access on your local system just
to play with SQL commands.
Of course, whether you choose a command shell or a socket
based connection, you will need to know the language of the
database in order to send commands. For this tutorial, we are
going to focus on SQL which is actually the defacto language of databases today.
SQL comes in many flavors depending on the
proprietary database system implementing it. However, regardless of
the proprietary extensions, the core of the language is the same
in every environment. Fortunately, for most web uses, generic SQL will be
more than sufficient.
SQL protects us from the implementation of data storage and
retrieval. Essentially, so long as we use the standard
commands such as
SELECT * FROM database1
It is up to the database itself to figure out what to do.
We don't need to know any of the internal workings of the database
or how it stores data on the file system.