Как реализовать удаление пользователя?

Question

Я разрабатываю свой тестовый проект, который представляет библиотеку.Что касается его разработки, я постоянно отвечаю на вопросы.

Не могли бы вы помочь мне с одним из них?

Мой дизайн модели включает в себя сущности User и LeasingHistory, поэтому, когда пользователь заимствует книгу LeasingHistory tableзаполняется соответствующей записью.

create table USER
(
 ID BIGINT not null serial primary key,
 ADDRESS VARCHAR(255) not null,
 DOCUMENT_ID VARCHAR(255) not null,
 FIRST_NAME VARCHAR(255) not null,
 SUR_NAME VARCHAR(255) not null
);

create table LEASING_HISTORY
(
 ID BIGINT not null serial primary key,
 BOOK_INSTANCE_ID BIGINT not null,
 USER_ID BIGINT not null,
 START_DATE DATE(10),
 ARRANGED_END_DATE DATE(10),
 ACTUAL_END_DATE DATE(10),
 foreign key (BOOK_INSTANCE_ID) references BOOK_INSTANCE,
 foreign key (USER_ID) references USER
);

Теперь я должен реализовать удаление пользователя.Как я должен это делать?Как это реализовано в Google, Facebook или в StackOverFlow?

Я не думаю, что удаление сирот является подходящей стратегией в этом случае, потому что история не должна быть очищена.

Я полагаю, яМожно добавить поле isActive в таблицу пользователей.В этом случае я могу очистить личную информацию и назначить isActive = false, когда пользователь нажимает кнопку «Удалить учетную запись».

Что вы думаете об этом?

ОБНОВЛЕНИЕ: Я думаю, что пользователь должен иметьвозможность восстановить свой аккаунт, таким образом, в этом случае вариант @killjoy лучше.Можете ли вы проверить меня, правильно ли я понимаю?Я ввел дополнительную таблицу UserInternalData, и в случае удаления пользователя я очищу все данные (кроме id) от сущности User и установлю isDeleted в true и dateStamp в текущую дату в 'UserInternalData'

@Entity
@Inheritance(strategy = InheritanceType.JOINED)
@NoArgsConstructor
@AllArgsConstructor
@Getter
@EqualsAndHashCode
@ToString
class Person {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String firstName;

    private String surName;

    @JsonFormat(pattern="yyyy-MM-dd")
    private LocalDate dateOfBirth;

}

@Entity
@NoArgsConstructor
@Getter
@EqualsAndHashCode(callSuper = true)
@ToString(callSuper = true)
public final class User extends Person {

    @Builder
    public User(Long id, String firstName, String surName, LocalDate dateOfBirth, String documentId, String address) {
        super(id, firstName, surName, dateOfBirth);
        this.documentId = documentId;
        this.address = address;
    }

    private String documentId;

    private String address;

}

@Entity
@NoArgsConstructor
@AllArgsConstructor
@Builder
@Getter
@EqualsAndHashCode
@ToString
public final class UserInternalData {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @OneToOne
    private User user;

    boolean isDeleted;

    @JsonFormat(pattern="yyyy-MM-dd")
    private LocalDate dateStamp;

}

Я прав?

Answer 1

Несколько подходов к рассмотрению.

1. Добавьте столбец isActive (или, что эквивалентно, столбец isDeleted) в таблицу USER.Очистить (или установить) бит при удалении пользователя.Вы, вероятно, также хотите стереть другую конфиденциальную информацию.Это оставляет открытой возможность повторной активации удаленных пользователей в будущем.

2. Замените поле USER_ID во всех затронутых строках в LEASING_HISTORY специальным зарезервированным идентификатором, представляющим удаленногоuser (возможно, с именем типа "Deleted User").

3. В соответствии с @killjoy, нормализуйте две таблицы, добавив третью таблицу, которая относится от USER_ID к BOOK_INSTANCE_ID, и удалитестолбец USER_ID от LEASING_HISTORY.Затем вы можете просто удалить затронутые строки из этой третьей таблицы, не теряя историю аренды книг.

Приложение

Если подумать, (3) может быть не очень хороший подход.Идея заключалась в том, чтобы выделить внешний ключ USER_ID в отдельную таблицу, но это не решает проблему висящего удаленного внешнего ключа.

Возможно, более работоспособный подход:

Не ограничивайте USER_ID внешним ключом.Таким образом, вы можете безопасно удалять USER строк без необходимости какой-либо очистки.Конечно, вам все еще нужно обеспечить ссылочную целостность (программно) во время создания каждой новой строки LEASING_HISTORY.

Я предпочитаю (1), потому что вы не удаляете какую-либо историю пользователей, толькоконфиденциальная информация пользователя.