Project(11)- Summary after first release permissions

Go back to the beginning of the design

Section (8) : Branch role table

• Give five fields, for example: first, second, third, fourth, fifth

These five fields correspond to five levels. First is the highest level, and fifth is the role.

• All fields are named after the department. If a role is required in this field, add the role name to the field at the next level. The department can be defined as the head of the department on the front end and data processing is performed when the interface is obtainedfirst: [{name:second,children:[]},{name:second}]

Mistakes show

The design here has violated three paradigms of database design;

• First normal form: the relational schema R is said to satisfy the first normal form when none of its properties can be decomposed into more basic units of data, abbreviated to 1NF. Satisfying the first normal form is the minimum requirement for the normalization of the relational schema; otherwise, many basic operations cannot be implemented in such a relational schema.
• Second normal form: if the relational mode R satisfies the first normal form and all non-primary attributes of R are completely dependent on each candidate key attribute of R, R is said to satisfy the second normal form, abbreviated to 2NF.
• Third normal form: Let R be a relational pattern satisfying the conditions of first normal form and X be any set of attributes of R. If X is nontransitively dependent on any of the candidate keywords of R, R is said to satisfy the third normal form, abbreviated to 3NF.

My initial point was that the roles of superiors and superiors have permissions, but this is actually confusing.

However, I confused departments, roles and even positions into one table, which led to my complicated data processing.

Project summary

Summary of basic programming knowledge

1. The concept of classes

The 10 data types defined by ECMAScript can be divided into basic data types and reference data types

Basic data types: meet the concept of deep copy. namely

const a = 10;
let b = a;
b = 20;
console.log(a,b) / / 10 20
Copy the code

Reference data type: sender of shallow copy; namely

class Student{
	constructor(name) {
	        this.name = name; }}let z = new Student('z');
let s = z;
s.name = 's'
console.log(z,s)// both {name:'s'}
Copy the code

Let me add ts here

class Student{
    public school:string;
    private name:string;
    protected age:number;
    constructor(school:string,name:string,age:number) {
        this.school = school;
        this.name = name;
        this.age = age; }}class Book extends Student{
    constructor(school:string,name:string,age:number){
        super(school,name,age)
    }
    public getInfo() {
        return this.age; }}let c = new Book('a'.'b'.1);
let z = new Student('a'.'b'.2);
let s = z;
s.school = 's' // s cannot access the name and age properties but c can access getInfo()
console.log(c.getInfo()) / / 1
console.log(z,s) {school:'s',name:'b',age:3}
Copy the code

2. Object Orientation

There are three basic characteristics of object orientation: encapsulation, inheritance and polymorphism

What is the object? An object is an instantiation of a class.

// js
class Student{
    name;  
    constructor(name) {
            this.name = name; }}const a = new Student("Cao cao)// constructor is encapsulation
Copy the code

Use TS to illustrate the difference between an interface and a class in inheritance

interface Name{
	name:string;
}
interface Age{
	age:number|string;
}
interface Person extends Name,Age{
	sex:string;
}
let person = <Person>{};
person.name = 'Joe';
person.age = '14';
person.sex = 'male';
console.log(person) // {name: 'name ', age: '14', sex:' boy '}
class Name{
	name:string;
}
class Age{
	age:number|string;
}
class Person extends Name{
	sex:string;
}
let person = <Person>{};
person.name = 'Joe';
person.sex = 'male';
console.log(person) // {name: 'name ', sex:' male '}
Copy the code

Why can an interface inherit more than one, but a class only inherit one?

Here’s a look at the prototype chain

class Name{
    name:string;
}
interface Sex{
    sex:string;
}
interface Age{
    age:number|string;
}
class People extends Name{
    sex:string;
    getAge(){
        return 18; }}class Person extends Name{
    sex:string;
    getAge(){
        return 18; }}interface Man extends Sex,Age{
    name:string;
}
let people = new People;
let person = <Person>{};
let man = <Man>{};
people.name = 'Daisy';
people.sex = 'woman';
person.name = 'Joe';
person.sex = 'male';
man.age = 18;
man.sex = 'male';
man.name = 'bill';
console.log(people);// People {name: 'zhao liu ', sex:' female '}
console.log(people.getAge()); / / 18
console.log(person); // {name: 'name ', sex:' male '}
console.log(person.getAge()); / / error
console.log(man); // {age: 18, sex: ' ', name: ' '}
console.log('people-class',people instanceof Name); // true
console.log('people-obj',people instanceof Object); // true
console.log('person-class',person instanceof Name); // false
console.log('person-obj',person instanceof Object); // true
console.log('man-obj',man instanceof Object); // true
Copy the code

As you can see, Man’s prototype chain of objects points directly to Object, while people points first to Name and then to Object. We can think of the Object as the child, the interface as the child’s birth setting, and the class as the child’s father. Method properties in an interface can be combined and then inherited to an interface as the birth setting of a child. After the child is born, the child can implement methods in the interface and change the value of the property. The class is like the father of the child. The attributes of the child are inherited from the parent class. Parent-child relationship can be tested according to prototype. As you can see in the code above, people and Person are the same classes, but they are created differently, so they have different results. I got confused here. First of all, if I look at people, I just said new, which means that the people class is instantiated, which means that all the properties in the class are implemented. {} is the type that asserts an empty object. The object is instantiated, but it has no properties. When you add properties to the empty object, you need to satisfy the properties of the Person class to add them.

Add the concept of abstract classes

An abstract class is a special class,

• A class that contains abstract methods is an abstract class. An abstract class does not necessarily contain abstract methods.
• An abstract class cannot be instantiated directly but must be instantiated through its derived/subclass.
• A derived/subclass of an abstract class must implement all the abstract methods in the abstract class to be instantiated, otherwise it remains an abstract class.

3. Modular development

Difference: Require represents runtime loading. Import means load at compile time (more efficient)

CommonJS

The whole background is developed through CommonJS

• CommonJS three ways to write

const fs = require('fs')
exports.fs = fs
module.exports = fs
Copy the code

• Pass the code of the parameter module

const time = function(type){
    const date = new Date(a); Y = date.getFullYear(); M = date.getMonth()+1;
    D = date.getDate();
    h = date.getHours();
    m = date.getMinutes();
    s = date.getSeconds();
    if(type === 1) {return Y+"-"+M+"-"+D+""+h+":"+m+":"+s
    }
    if(type === 2) {return Y+"-"+M+"-"+D
    }
}
exports.time = time
Copy the code

ES6 Module

    // Select export and import
    import { Action } from '.. /components/index';
    export default { Action };
    // Rename the whole object export import
    import * as service from './service';
    export function a(){}
    export function b(){}
    // Export as a whole
    import store from '@/store/index';
    export default store
Copy the code

Project problem feedback

Front end:

• The main problem comes from the interface interconnection. The data structure of the interface does not meet the requirements.
• Secondary issues arise from vue’s mastery of the family bucket, and the details are dependent on documentation.
• Common problems arise from the degree of coupling between the fields and the modification logic.

Back-end issues:

• The main problem comes from the logic thinking of the early design, which is not fully considered.
• Secondary problems arise from inadequate data formats.
• Common problems arise from the degree of coupling between the fields and the modification logic.

Solution:

• Plan 1: Cultivate good overall logical thinking, test thinking
• Scheme two: one end is the main and the other end is the auxiliary cooperative development

Project Technical Framework

Node.js + ES6 +CommonJS+ Sequelize + KOA2 +mysql deployment: Nginx +pm2