MySQL: Building User Interfaces (Landmark)

Problem Definition and Design Issues

This section describes the problem in greater detail and works through some design decisions. Because this is a relatively simple problem and should be a straightforward implementation, this chapter does not go into much of the detailed design that a large multi-person project would need in order to ensure success.

Hardware Specifications

A PC will have Linux installed on it; the hard drive will be wiped, and a new Linux distribution will be installed: Red Hat 6.2 with the GNOME desktop (the version current when this book was written, Red Hat 7.x should work fine when it comes out). This is the out-of-the-box default configuration for Red Hat 6.2 (for a total cost of approximately $30 so far). The target machine will probably be a first-generation Pentium box with a 1- or 2-gigabyte hard drive; although you can put Linux on a hard drive as small as 300 megabytes, a 1-gigabyte hard drive is probably the minimum hard drive that should be used. There will be no need for modem/dialout, printing, and so on from this machine; initially, it will exist solely to run this application.

Network Information

The client already has a static IP LAN for file sharing and drive mapping under MS Windows. The existing LAN consists of 15 machines, all running either Windows 95 or Windows 98.There is no central server. No one else will need to access the Linux box except the data entry operator and the LAN administrator.

Existing Data Information

The customer master file and product master file are currently stored in Microsoft Excel spreadsheets. The data is relatively straightforward; no more information is kept than is needed.The client is confident of the data stored in the spreadsheets; only the data entry operator has touched or altered them in two years . Key values, such as item number, are unique, addresses are complete and correct, and so on. These files will be output to text files, transferred to the Linux box, and then uploaded to the MySQL database using MySQL utilities (see Listing 6.1).

After that, the database will be considered the source of record for this information, and the spreadsheets will be retired .

The item master file currently has about 600 items in it, and it changes only once or twice a month, if at all. The customer master file currently has about 170 records in it and changes as needed. The user must be able to add a new customer quickly and easily while that customer is on the phone.

Existing Process Specification

The existing process works as described here:

• The data entry clerk receives a phone call (or retrieves the information from the answering machine) with the order information. He or she uses Notepad to enter the following information: customer information, the order, and any special instructions.

• The data entry clerk processing the order then opens three files: the customer and product master files in Excel, and a Word document (template) that will become the order form.

• Using cut and paste, he or she fills out the Word template with the necessary information until the Word document is complete. At that point, it is sent to the printer. The cut-and-paste operation is the single most tedious , time-consuming part of the whole operation because of the differences in format between Excel and Word; for example, you must put in carriage returns (vice tab characters ) to separate address lines and so on.

• Several times a day, whatever orders come out of the printer are taken across the building to the warehouse and are given to the individual who will fill the order.

The Desired Process

In the new improved process, the data entry clerk will have access to two PCs ”one with Windows and the other with Linux. He or she will be able to click an icon for a new order select from a pick list of existing customers, edit their customer information, or enter a new one if needed. The customer information will be filled in and displayed. From there, the data entry clerk can proceed to enter the items ordered by the customer. It is possible to directly type in the item number if it is available, select it from a list of all items, or search on a keyword of the character (not numeric) fields of the item master file.

When the order is complete, the application will write the order to the hard disk in the form of a text file (there will be a command button in the application for this, the data entry clerk will initiate it). The title of the text file will be the name of the customer and the date and time the file was created. Each order will be stored in a separate text file and formatted for quick printout on a printer in the order fulfillment office. Although the current Word document has some formatting, this is not necessary to the work flow and will be done away with.

At the desired time, as desired by either the person creating the order or the people in the order fulfillment section, the completed order text files will be transferred to the PC in the order fulfillment office. The mechanism for this could be any of the following:

• FTP.This method would be either a push operation instigated by the data clerk (i.e., sending the data from the Linux box to the PC in order fulfillment) or a pull operation instigated by the order fulfillment office staff (for example, someone in the order fulfillment office logs in to the Linux box and pulls the files over the network). The only potential problem with a pull operation is the possibility that a file will be pulled during its write operation.

• Email

• Mapped drives , via Samba

• Other similar mechanism

Whatever mechanism is used, it will be manually initiated by one of the concerned parties. From that point, the order fulfillment office will print each of the text files in turn . Once done, the files will be moved to an archive directory on the local PC. Again, this might be a batch file, or even a manual process. The users in order fulfillment will know how to do this, or they can be taught. From that point forward, the process will proceed as before.

Desired Characteristics of the Software

The following characteristics and other concepts should be included or excluded at the application level:

• The application should allow the user to keep his or her hands on the keyboard as much as possible, avoiding the mouse.

• There is no need for auditing or detailed logging.That is, the application doesn t need to record who changed what data and when. First, the data is not that sensitive, and second, because the data entry clerk is so familiar with the data, he or she can be relied on to understand and solve any problems that come up.

• There is no need for security at the application level beyond that which is standard for a PC (for example, a login). Again, the data is not that sensitive, and after it is processed into orders, it will be copied or transferred from the Linux machine anyway.

• The MySQL database server, client, and application will all be on the same machine.

• There won t be any need to save orders, read or edit existing orders; the process will proceed from start to finish, or else all order information will be lost. This is considered acceptable because an order rarely exceeds 20 items. So, if a customer gets halfway through an order and needs to call back later to finish, there will not be a significant penalty to start over from the beginning. Because of this, each instance of the application can be a different order and can remain open all day if necessary.