Reflection

Database development should be a methodical process involving discussion with your clients, assuming you are the systems analyst and designer. Complex situations will be more difficult than simple ones, and some databases are very complex. It is also true that your client might not have thought about many of the issues that make a difference in the design. The analysis stage is for defining requirements, and the design stage is for generating the plans for building the system.

The concepts you learn by reading this text and the experience you gain by implementing and enhancing the examples will serve you if and when you choose to use other DBMS products, because they all follow the same SQL standards. The reasons to seek out other products (Oracle, SQL Server, DB2, etc.) generally involve issues of scale. The more expensive products generally provide support for managing what are termed transactions and handling system outages and recoveries. Transactions are combinations of database operations that need to be considered as a unit in terms of blocking out other access to the database. System outages do happen, and building a robust system means that you need to have procedures for recovery.

Another technology coming into widespread use for storing and handling data is XML, or eXtensible Markup Language. In XML, individuals or groups of people define their own tags. Like HTML, tags have names and attributes and can contain other tags. The nesting is strict: a child tag has to be totally contained in its parent tag. You will need to decide if the content and the functions of your application are suited to the tables and relationships of standard databases, or to the tree-like structure of XML, or both. Independent vendors and the DBMS vendors are offering products that support XML and traditional databases, now called structured databases.