The cells in the table are filled with the values contained in the record set...

The while loop allows you to walk through the result set and post the values that were in the SELECT query.

Figure 21.7 Search ad results.

- 270 -

Test and Deploy
The final steps in the creative process are to test your code and then put it into production. When you are finished thoroughly testing your code, give it to someone else. You can bet that 9 times out of 10 he or she will find something that you missed. Programmers, as a rule, don't make very good testers. We know how our product is supposed to work, so that's how we test it. We don't try the unexpected. Users will. Test your scripts well before you deploy them. Also test your Web pages (or the output of your scripts) using Internet Explorer as well as Netscape Navigator. You may be surprised at how well things turn out in one browser and look terrible in another. Finally, test your output using various screen resolutions. The user's screen resolution greatly affects how your Web page looks.
The final step is deployment. This is where you take your system and put it into production—your ultimate goal. The hard work and hours of design are all for this crowning moment. There should be no surprises at this point. You should know before your product ever reaches this point whether it will be a success or a failure. If you followed the creative process, along with the database design process, you can almost be guaranteed your system will be successful.

Summary
Today, you learned about the creative process and the steps that are involved. You saw how the database design process meshed with the creative process to help you reach your goal. You also learned the importance of design; with proper planning, it is an easy transition from an idea to a working system.
You also reviewed the key events that took place on your three-week journey. You reviewed how to create a database, as well as the supporting tables and columns. You saw how to import data from an existing database, and you also went over security and how to implement it. Finally, you created a series of Web pages and Perl scripts that took your design and made it reality.

Q&A
Q:
The

Products table had a picture column in it. How are images stored
in MySQL?
A:
MySQL can store images as BLOB types. They first must be escaped before
they can be stored. There has been much debate in the newsgroups as to
whether it is better to store images in the database or to store a link to a

directory where the file is located instead. The argument is that BLOB types are inefficient. They take up too much space and cannot be OPTIMIZEd.
However, the file system is probably the best place to store files. Your best
bet is to store images in a directory outside your database.
Q:

How often should I OPTIMIZE my database?
A:
You should OPTIMIZE your database regularly, especially when your

database is young. The OPTIMIZE command is needed when a large
number of records have been either deleted or inserted into your database.

Exercises
1. There are two scripts that you did not create on the flow chart—the script to display items from the Products table and a script to create an order. Create these scripts using Perl and the DBI/DBD.
2. The same task as the first exercise, but this time use ADO and ODBC.
Week 3 In Review
You have finished your third and final week of learning MySQL. You started the week with a look at a highly-used interface. In the middle of the week, you covered a lot of database administration tasks. You ended the week with a full review of what you have learned by building a Web site using MySQL from the ground up.
You now possess the basic knowledge to go out and fully deploy MySQL in real-life situations.

Appendix A: ASQL Syntax and Commands

- 271 -
Overview
This appendix will provide you with a list of SQL commands for your reference. The commands are listed in alphabetical order. The command will be followed by a list of possible parameters. Optional parameters will be enclosed by brackets[ ]. Examples will be provided where appropriate.
ALTER
[IGNORE] TABLE table_name specification [, specification]
Specifications can be
ƒ ADD [COLUMN] column name ( column definitions) [FIRST or AFTER
column_name]
ƒ ADD INDEX [index_name] (column_list)
ƒ ADD PRIMARY KEY (column_list)
ƒ ADD UNIQUE [index_name] (column_list)
ƒ ALTER [COLUMN] column_name {SET DEFAULT default_value or DROP
DEFAULT}
ƒ CHANGE [COLUMN] old_col_name create_definition
ƒ DROP [COLUMN] col_name
ƒ DROP PRIMARY KEY
ƒ DROP INDEX index_name
ƒ MODIFY [COLUMN] create_definition
ƒ RENAME [AS] new_tbl_name
This is a ton of information, but it is really straightforward. The IGNORE keyword causes rows with duplicate values in unique keys to be deleted; otherwise, nothing happens. Any one of the previous specifications can be used in the ALTER TABLE statement.
Examples:
ALTER TABLE Customers ADD COLUMN Account_Number INT
ALTER TABLE Customers ADD INDEX (Customer_ID)
ALTER TABLE Customers ADD PRIMARY KEY (Customer_ID)
ALTER TABLE Customers ADD UNIQUE (Customer_ID)
ALTER TABLE Customers CHANGE Customer_ID Customer_Number INT
ALTER TABLE Customers DROP Customer_ID
ALTER TABLE Customers DROP PRIMARY KEY