Avoid the top ten mistakes Find a database development shortcut

Although the hot technologies in software development are endless and changing, there are some things that have not changed, one of which is the developer's use and design of the database ...

You may be excited to follow the fashion to create an AJAX Web interface, or use the latest fascinating Windows user interface, but through these various appearance interfaces, you may still need to extract or access the required data from the background database This is like more than 10 years ago when people were doing the same thing with the database.

Surprisingly, however, there are still many developers who continue to repeat the mistakes of database usage and development that existed many years ago. Perhaps there are too many developers just to learn how to use a database, not really to study it. The following is the author as a developer, the individual in peacetime development work selected by the database developers often make the top ten mistakes, readers and peers.

1, the wrong database was selected

Not all databases can be used to accomplish your tasks, which means that you have to choose the right database before you use the database to do any development work and other things. For example, we often see a large-capacity dataset that some Access databases do not have the ability to handle, but for SQL Server it is as easy as playing a child's game. However, some people spend money to buy SQL Server for the need to handle only hundreds of rows of data. These are all wrong practices.

Broadly speaking, databases in today's market can be divided into three tiers: desktops and embedded databases--suitable for small tasks; Some large database products are also good for "Express" editions, which can handle several G-data, while real enterprise databases, like SQL Server, Oracle and DB2 data processing capabilities are amazing, and you can throw the data to them without hesitation.

Therefore, before you choose a database, you need to conduct an objective and factual analysis of your data to select the database products that are appropriate for your development work and actual needs.

2, the choice of too many databases

The advent of application programming interfaces such as ODBC, JDBC, and OLE DB greatly facilitates and improves database independence, meaning that developers can write your application: You can have your application support the use of any database for data storage.

However, there is a cost to this situation, and I have seen some development teams in the pursuit of the application's database "irrelevant", specifically written by the application to convert all the SQL statements to some of the underlying language, so that all the database can understand and execute, but, Doing so also loses some of the advanced functionality of the existing database.

So why do you do it? It may be that some customers may want to switch to Oracle or DB2 or FoxPro, or some other database in future use, perhaps by using the above approach is now ready to "take precautions".

Another way to do this is when you start developing a new product, choose a storage engine and start writing your application on that basis. If your product is good enough, people will install the database you specify, so you don't have to waste time and effort to support an "imaginary" user requirement.

3, to understand your data

There are a lot of issues to consider when we use the database, for example, some customer numbers may not be the seven digits we normally think of, but six, and some companies and businesses may not necessarily require employees to enter their ID numbers or bank accounts to protect their privacy. Therefore, the data types must be set to be nullable (NULL) in the database setup and development.

In other words, database development and design can not be divorced from the actual situation, not away from the actual business rules. For a database developer, it is necessary to fully understand what the user needs to actually enter data, and based on that data, to reasonably design the size, type, and rules of the data field, and so on. Otherwise, waiting for you will be to return to the head again and again to make the modification work. Therefore, you have to learn at the beginning of the data you need to deal with a very comprehensive, in-depth understanding, to try to take into account all kinds of accidents.

4, the database is not as Excel as everyone will use

Now there is an understanding of the misunderstanding, especially in the eyes of some small unit managers, they always think that any developer knows how to build a database reasonably.

Obviously, this misunderstanding makes me very confused. Since you don't assume that any developer knows how to program in C # or create a Web service, why assume that every developer is a database expert?

The final result of this assumption is that too many databases are designed by people who have never even heard of the term normalization (term normalization). Many database functions are not properly used, if you are such a developer, then before you design the database, you need to strengthen the training and learning. Efficient database design is a skill you have to understand and master, and don't expect to learn this through the lessons of failure.