How should we design a database? (2)

Recently, when the company wants to develop a new system, it basically decides to use the ORM (the senior management is still hesitating and worried about efficiency ). Since the ORM is used, it is natural to think of designing a database with the object-oriented approach.

This article aims to discuss how to abstract (using users as abstract examples) 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 represents an abstract class (it 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 represents 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 all three items are false, public bool hashouse {Get; set;} // in this life, everyone wants to get married 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 is true, so you can never eat or drink it for a lifetime}

 

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 (for example, adding a new contact method ).

If you do not use Orm, this change is indeed very painful; but if you use it (the default ORM can be used to generate/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's okay to leave them 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? It is difficult to maintain things like this (now the company's old system is like this, it can join 10 times and 20 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.

 

Put aside

 

PS: the homepage of the previous rdlc was cut down, praying that this article will not be cut down

PS: How do we design a database? (1)