Operation log to do? Eldest brother, I worry.-CodePudding

Demand is the operation of the system to record the user to the database, the user's operation, such as adding users edit users, delete users... And so on,

Question 1: diary database tables to save the user's identity and foreign keys to the users table, then I DELETE the user, this is not the all of the user's operation logs to DELETE, but I don't think to DELETE, how to do, don't put the ON DELETE NO ACTION?

Question 2: save operation diary database table the user's identity, my diary is the query table, I know the name of the user, but if the user in the users table has been deleted?

I hope you do bosses guidance,

CodePudding user response:

Suggest building table operation logs alone, operator name is stored in the string field directly

CodePudding user response:

reference 1st floor zgl7903 response:

suggest building table operation logs alone, operator name is stored in the string field directly

You said, the method of save the operator name, operator name change, you this diary table name is wrong, the other user actions just a user ID and action object ID, I this not every interface to query the user ID and operation object ID so trouble

CodePudding user response:

Deposit name again afraid they changed the name, id and afraid of being deleted,
In fact, wrong is wrong, this is no way,
Suggested that cannot use foreign key synchronization delete, save database id and name, id exists read operator table name, id does not exist when reading log table name,

CodePudding user response:

reference mmcanyu reply: 3/f

save name again afraid they changed the name, id and afraid of being deleted,
In fact, wrong is wrong, this is no way,
Suggested that cannot use foreign key synchronization delete, save database id and name, id exists read operator table name, id does not exist when reading log table name,

Each ID of the operation, and from the database to find the name not trouble? Operation log did this?

CodePudding user response:

Your problem is not design problem, but demand
Better to ask yourself back to the log itself needs is need a permanent operation history or an existing user operation
Maybe look back business requirements will understand
If you are not sure can take conservative strategy to save all came operations such as important objects are not allowed to delete (marked for deletion, and does not provide completely delete)

CodePudding user response:

Upstairs positive solution, marked for deletion, not delete, is indeed a cheaper way, many people did the same,

CodePudding user response:

refer to 6th floor mmcanyu response:

upstairs positive solution, marked for deletion, not delete, is indeed a cheaper way, many people did the same,

reference 5 floor Chen Zhongfu reply:

your problems are not design problem, but need
Better to ask yourself back to the log itself needs is need a permanent operation history or an existing user operation
Maybe look back business requirements will understand
If you are not sure can take conservative strategy to save all came operations such as important objects are not allowed to delete (marked for deletion, and does not provide completely delete)

Marked for deletion, that actually use the SQL user table SQL will rule out delete users, this change is also very much, because there is a lot of SQL to change

CodePudding user response:

reference 7 floor kyosuke kanou response: 1989

Quote: refer to the sixth floor mmcanyu response:
upstairs positive solution, marked for deletion, not delete, is indeed a cheaper way, many people did the same,

reference 5 floor Chen Zhongfu reply:
your problems are not design problem, but need
Better to ask yourself back to the log itself needs is need a permanent operation history or an existing user operation
Maybe look back business requirements will understand
If you are not sure can take conservative strategy to save all came operations such as important objects are not allowed to delete (marked for deletion, and does not provide completely delete)

Marked for deletion, that actually use the SQL user table SQL will rule out delete users, this change is also very much, because there is a lot of SQL to change

this shows a hard-coded leads to a lot of code duplication, you can try to reconstruct the part, such as the screening of the user's action is encapsulated as a function, is on the way is to put the filter in the presentation layer, you can also delete the time will be marked as deleted data in another table, in the library, this part of the data is usually cold,

CodePudding user response:

Top, you have done the log guide friends about how do you do,

CodePudding user response:

Can also modify the operator name? Design problem, you should have a single operator name registration cannot be modified, a nickname,
Log suggest forever