Four preparatory work for improving the effect of database development

Pre-work one: Define the standard object naming conventions.

Be sure to define the naming conventions for database objects, which is a point that I have repeatedly insisted on. Before developing a database project, the project development team first discusses naming conventions that determine database objects. Includes naming rules for functions, procedures, tables, views, fields, and so on. Because we are referencing these objects repeatedly during the development of the database. Without a uniform naming convention, only the owner of the object knows what it means. When other database developers want to refer to an object, they are at a loss to know where to begin. Therefore, the establishment of a unified database object naming specification, this is a database design a necessary preparatory work.

1, the use of prefixes to distinguish between each object. In an Oracle database, basic objects have functions, procedures, tables, views, and so on. For objects other than tables, the author suggests that they be distinguished by prefixes. For example, the function name is prefixed with the fun prefix, and the view is prefixed with the view prefix. So, when you call a view or function in another object, you can enter the view prefix to have the database system list all the current view objects for the database. In this way, we can reduce the scope of our choice and improve the efficiency of object reference.

2, can be based on different functional modules to the basis of the name of the table. For ERP, there are thousands of light base tables. How can so many tables be managed in an orderly manner? The author suggests that the Software function module may be prefixed by its abbreviation. For the underlying tables used by the financial module, you can use the FI prefix, and the base tables involved in the Sales module take the SA prefix. With this naming convention, you can associate the purpose of a table with the prefix you see. Undoubtedly, this can improve the readability of table names and also facilitate database developers ' references to table objects.

3. For fields, the naming conventions involve more techniques. For example, the author often adds a suffix to the following fields to indicate the data type of the field. If the order quantity is a typical numeric type field, the author will add the num suffix later. After this process, when they want to refer to the field in other objects, do not bother to think, to find information, determine the data type of the field. If you set the field column name, the author likes to add the prefix of the table to the field name. If there is a field of sales order ID in the sales order now, the author named it or_order_id, and in the shipping list, it also needs to use this field, the author named ou_order_id. When we do the order delivery schedule, reference these two fields, you do not need to enter a specific table name before. If we add the prefix to the table and the fields in both tables are named order_id, the ID field of the referenced table is added to the table name when referencing them. If more tables are associated with the query, each table must be added to the table name to be able to reference it. Obviously, the former way of referencing is to save effort.

Of course, the above naming conventions will be based on the hobby of your project team. In short, a basic principle is to unify the naming conventions. Not enough for a development team to have three developers in one set, which is not conducive to collaboration between project teams.

Pre-work two: Consider the flexibility of the system.

A good database administrator, in the database development, often take into account the needs of users in the future changes in order to improve the flexibility of the database. If the user changes the requirements every time, by changing the database object to achieve, the database is too rigid.

Therefore, the author believes that the database administrator before the development of the database, to communicate with customers. Determine which aspects of the future may change, and then take some strategy to control it. In the case of no adjustment to the database, through some simple configuration, to achieve the requirements of the adjustment.

If the author in the development of a supermarket retail system database, the author in communication with customers, it encountered such a detailed problem. The prices of supermarket products may have some seasonal price adjustment problems. According to the previous design, the system can only achieve the regular conditions, such as the number of a certain kind of product unification to pick a percentage point and so on. However, this is far from meeting the needs of enterprises. Because before adjusting the price, they will pass the form of excle form, with the supplier to confirm the condition thing. Therefore, the supermarket manager would like to be able to directly based on this form to update the price of the system. After the author understands this information, it involves a batch process of price update, which facilitates the user to update the price in batches.

These features do not look small, but they can give the customer a very good feeling. To tell the truth, now the same system of plagiarism between the phenomenon has been very serious, homogenization of the phenomenon more and more prominent. We only in the user friendliness and system flexibility to work hard to win customers, attracted a better visibility.