Solution to the conflict between unique index and logical deletion

introduction

I encountered a problem in my project today ： When logical deletion and unique index exist at the same time , The data that has been logically deleted cannot be added again due to the constraint of the unique index , What should I do ？

This problem has been encountered in other projects before , At that time, I didn't think of any good solution , I didn't check the data , I think of a violent method ：

I directly removed the unique index , Then in the code logic implementation part, the uniqueness of the index field is constrained by code ;

This, of course, solves the problem , But it is wrong to do so , How can a designed database be modified at will ;

This time I encountered the same problem , Thinking of the last method is not only non-conforming , And it's very troublesome （ For a unique logical judgment, call the database query and then write the logical judgment ）, This time I found a solution , Here is a brief introduction ;

Solutions

All the solutions are just one idea ： Through logical deletion, fields and constraint fields are combined into an index ;

For example, there is a teacher surface , The unique index is name, The logical deletion field is is_delete：

Uniqueness index ：

In order to solve the problem of conflict , First, you need to modify the index , Let the logically deleted field and the unique field act as the index together ：

But one more thing to note ： Generally, we are used to deleting fields logically is_delete Set to 0 There is 1 Delete ; But this is not the case here ;

For example, delete the above table test Field , The index can be seen as test and 1 The combination of ; Create again test No problem , Because the newly created index is test and 0 The combination of , But if you delete it again test Then again test and 1 The combination of , Index conflict ;

So the only thing we have to do is find a way to make The deletion ID of the logical deletion field is unique , Undeleted fields do not need to be changed ;

Here are three ways ：

Set the deletion ID as the primary key id

Because the primary key id Is the only one. , Therefore, you only need to set the deletion ID of the logical deletion field as the primary key ：

But this method I think if id Too long , Will it take up more space ？（ Personal thoughts ）

Like this teacher In the table, I only is_delete Field set to tinyint The length is 3, If the primary key is too long, it must be modified to bigint, Please don't say , Does it take up more space ;

The deletion ID is set to the current time

This method is similar to setting the deletion ID to a timestamp , Because every period of time is different , So naturally there will be no repetition ：

Then you can use to get time mysql Of Now() function ：

But it also takes up space , And the field calling function may affect sql efficiency ; It's not a special recommendation ;

The deletion ID is set to NULL

This method is to set the deletion flag to NULL, It can solve the problem perfectly ：

I think this method is the best , I also use this method ;

It can be seen that there will be no conflict ;

Be careful ： Delete fields logically is_delete To set the allowed to null;

summary

I've also seen other ways ： For example, create a history table 、redis Weight determination 、 New fields and indexes are uniquely constrained …

But these methods are not convenient for direct modification , It's a bit superfluous ;

Of course, the above is only a personal point of view , If you have any questions, please contact us ;

Put it together ：