Chen Jun Qi:
The skilful use of powerdesigner concept of the production model and the physical model, in a hands-on perfect 15 post-tensioned form database design, you can find more in-depth understanding of the database. In doing database design should strongly consider the significance of the table, the type and value range of fields, so to have better scalability. From probability entities, analyze what data needs in the entity involved is required, what is the relationship that will analyze it clear, in order to make a more useful database.
On the other hand, they are more familiar paradigm in the field of good form and design, with the third paradigm of rules to judge whether more perfect, reduce the cost of post-table design unreasonable because. In addition, the form data deletion respect for, due to the policies and regulations and notices that do not involve the deletion, so to form a database of deleted We intend to intend to add a significant bit represents simplify the removal process as well as among the inconvenience of whether the data is deleted way.
Once open Deere:
About database design our projects, but also have a little experience. In fact, for database design is the first time we do, just start doing it extremely difficult, even with the prototype but doing database design considerations than done far more than the prototype considered, although we encountered difficulties in the designs, but under the leadership of our guidance of assistant professor and head of Chen Jun Qi's we successfully completed the preliminary design, we first met to discuss the basic prototype of the database, then we again under the guidance assistant additions and deletions to complete the design of the database.
Lan Qi poem:
1. Be sure to consider counter-paradigm design paradigm and the design of the database. We must analyze our business which is the case belongs, as the case may be, which way in what way the specific use.
2. Data scalability design needs to consider. The initial project data model is one to one business scenarios, and analyze the latter may be turned into many. Do this situation in order to facilitate the initial design data into one model. The latter may do so Debu loss of taste.
3. Data constraint is best in the beginning of the design data is well defined. Non-null data comprises a unique constraint constraint. This will solve a lot of empty exception system, and make the data better maintenance. If you do not do this, a time when the system is running. Some data should not become empty again fill the empty data you'll see what I care and thought. And it has made things give you extra line of defense against it.
4 . When there are multiple ways for data processing should be more comprehensive aspects, be considered to select the most suitable solution to the current project.
Tan Haoqin:
First to figure out before the database design requirements, it is important, if the demand for the software to be designed not understand, then designed the database is absolutely wrong, after the clear requirements, we must analyze our product its user / role which, in addition to user entities as well as achieve some product features required,
After determining entity, we need to determine what attributes of each entity, at this stage do not need to think entirely clear, probably came up with it.
After determining the good properties, we have to consider the relationship between entities is one to one or one to many or many-to-many relationship, it is best and then an additional one table, so many relationships become a field of two-to-many relationship, the relationship is stored in the entity table in a relational table or create a new one, and after determining the relationship we then turn to consider each field in the entity is reasonable, if there is anything missing field where best practice is against the demand list, think about this process, the database should be some changes.
First to figure out before the database design requirements, it is important, if the demand for the software to be designed not understand, then designed the database is absolutely wrong, after the clear requirements, we must analyze our product its user / role which, in addition to user entities as well as achieve some product features required,
After determining entity, we need to determine what attributes of each entity, at this stage do not need to think entirely clear, probably came up with it.
After determining the good properties, we have to consider the relationship between entities is one to one or one to many or many-to-many relationship, it is best and then an additional one table, so many relationships become a field of two-to-many relationship, the relationship is stored in the entity table in a relational table or create a new one, and after determining the relationship we then turn to consider each field in the entity is reasonable, if there is anything missing field where best practice is against the demand list, think about this process, the database should be some changes.