MySQL: Order Entry Abstract and Design
- Problem Definition and Design Issues
- User Interface
- Creating the Database
- Deploying the Application
- Upgrading the Application
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
This is the first of the "real world implementation" examples that will comprise the remainder of the book. In this case, the client is looking to do a "proof of concept" project in order to evaluate the viability of Linux and MySQL. The client, Specialty Electrical Supply, Inc. (SESI), has chosen an application that needs to be done: entering orders phoned in by customers. They are interested in the low price point of the Linux operating system and would consider converting to an all-Linux shop if they could be reasonably certain they would not have to hire an expensive server administrator.
The main goal of this chapter is to set out a basic design for a simple GTK+ and MySQL application. The project in question is entering orders for the client, SESI. Although this chapter does not attempt to outline a "formal specification," it does set out to describe the problem in sufficient detail so you can understand what the application should do and why. Its purpose is to give you a "big picture" view of the application so that when the application is built (in Chapter 7, "Construction of the SESI Order Entry Applications"), you will be able to understand how things work together, and you will have a point of reference to understand the coding process. There is an appendix in this book that goes along with this chapter and Chapter 7. It is Appendix A, "Glade-Generated Files from the SESI Order Application."
Currently, SESI uses a system that's based on Excel spreadsheets and Word documents, and one of the managers, who has a strong technical background, manages the LAN as one of his part-time duties. Their customer and product master files are Excel spreadsheets, and they cut and paste orders to Word. They then send the order to the PC's printer for a quick walk down to the warehouse—a very tedious process. The goal is to replace this with a GTK+ windowing interface that can then output each order to a separate text file. Then these text files can be sent to the individual(s) responsible for filling them by FTP, email, or whatever other mechanism may be chosen. Further, the next obvious step will be to create an application that the worker on the shop floor who is filling the order can use to record what was shipped and when and what had to go on backorder. For those of you more on the business end, this will be the "bookings" part of "booking/billing/backlog."
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.
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.