How should we design a database? (2)

Recently, when the company wants to develop a new system, it basically decides to use the ORM high-level level and is still hesitating to worry about efficiency ). Since ORM is used, it is natural to think of designing a database with the idea of object-oriented.

This article aims to discuss how to abstract a user as an abstract example) and propose some decoupling ideas.

For the first time, I used the object-oriented idea to design databases in actual projects. I wrote this blog and hoped to communicate with you a lot.

Start of Text

First, analyze the requirements

Our system has front-end and back-end users: Man, Woman, SuperMan, SpiderMan and IronMan. The background user is Administrator.

Front-end users must fill in the contact information and address, and then both SuperMan, SpiderMan and IronMan have the Ability.

The requirement is simple. Based on this requirement, we will draw an inheritance relationship diagram. Among them, V indicates that the abstract class should be abstract. When drawing a picture, you may think that it is virtual and start with V. If you are too lazy to change the picture, let's take a look.) I indicates Interface. For example:

It can be seen that the abstract class Person is derived from the Administration class and the abstract class User. Class Man and class Womam implement the interface Address and interface Contact, while Inhumans implement the Ability interface.

Then the abstract class code:

 
 

  
  
View Code   
  
  
 
  
  
    public abstract class Person  
  
  
    {  
  
  
        public string Username { get; set; }  
  
  
        public string Password { get; set; }  
  
  
    }  
  
  
 
  
  
    public abstract class User : Person  
  
  
    {  
  
  
        public string Name { get; set; }  
  
  
    } 
 
 

Interface code:

 
 

  
  
View Code   
  
  
 
  
  
    public interface IAddress  
  
  
    {  
  
  
        string Address { get; set; }  
  
  
    }  
  
  
 
  
  
    public interface IContact  
  
  
    {  
  
  
         string Email{get;set;}  
  
  
         string WorkPhone { get; set; }  
  
  
         string MobilePhone { get; set; }  
  
  
         string Fax { get; set; }  
  
  
    } 
 
 

Finally, Man class and Woman class:

 
 

  
  
View Code
  
  
 
  
  
Public class Man: User, IContact, IAddress
  
  
{
  
  
Public string Address {get; set ;}
  
  
Public string Email {get; set ;}
  
  
Public string WorkPhone {get; set ;}
  
  
Public string MobilePhone {get; set ;}
  
  
Public string Fax {get; set ;}
  
  
 
  
  
Public bool HasCar {get; set;} // if both are false
  
  
Public bool HasHouse {get; set;} // the ghost wants to get married in his life
  
  
Public bool HasMoney {get; set;} // T my tears
  
  
}
 
 

 
 

  
  
View Code
  
  
 
  
  
Class Woman: User, IAddress, IContact
  
  
{
  
  
Public string Address {get; set ;}
  
  
Public string Email {get; set ;}
  
  
Public string WorkPhone {get; set ;}
  
  
Public string MobilePhone {get; set ;}
  
  
Public string Fax {get; set ;}
  
  
 
  
  
Public bool IsBeauty {get; set;} // This value is true, so you can never eat or drink
  
  
}
 
 

The code is very simple. The other categories are not so detailed in length.

Follow this model and use EF Model First to create a database. The Woman table is as follows:

The next step is the focus: Why not store the Contact and Address sub-tables. In this way, it will be very painful to write it together with the Man table and Woman table.

If you do not use ORM, this change is indeed very painful; but if you use the default ORM here, You can generate or change the database from the Model ), this change is no big deal. You just need to modify the interface definition and modify it based on the error message. As for database changes, it is OK to hand over to the ORM.

In this way, there is a benefit that decoupling can be achieved within a limited range, and the relationship is partially reduced-if you split the Contact and Address tables, Woman needs to Join twice, this seems no big deal, but if you zoom in, what if you join ten times? This makes it difficult to maintain the old system of the company. Now, we can join ten or twenty times without moving, and the changes are very laborious ).

The question of how to decouple is quite profound, So I dare not make an axe in this class.

Link: http://www.cnblogs.com/CrazyJinn/archive/2012/08/20/2637459.html