Какие ограничения использовать для FK пользовательских данных?

Question

У меня есть пользовательская таблица, в которой есть user_id. Таким образом, весь пользовательский контент, журналы, подробные таблицы и т. Д. Имеют user_id как FK для родительской таблицы User. Это социальный сайт. Поэтому, когда пользователь регистрируется, ему назначается случайный user_id. Очевидно, что идентификатор никогда не изменится после назначения, поэтому:

1) Я предполагаю, что мне не нужно использовать «ON UPDATE CASCADE» на любой ссылке FK, потому что user_id никогда не может измениться в любом случае?

2) Нужно ли устанавливать «ON DELETE» или «SET NULL» в любом месте для FK user_ID в любом случае использования?

3) Если участник удалит свою учетную запись по большей части, я установлю флаг удаления. Но я даю пользователям повышенную конфиденциальность, чтобы удалить всю свою запись из базы данных, как будто их никогда не было, поэтому у меня есть два случая:

A) Удалить все следы пользователя (полное удаление), но сохранить содержание активным. Поэтому, если пользователь разместил фотографию, все, что я удаляю, - это мистер А., у которого есть удостоверение личности с фотографией 33445, но я сохраняю фотографию как сирота. (также г-н А будет удален из таблицы пользователя в случае жесткого удаления). Таким образом, в настоящее время существует около 16 таблиц, ссылающихся на следы пользователей, для которых необходимо установить значение NULL или значение по умолчанию user_Id 999, которое я ссылаюсь на несуществующего пользователя.

B) Удалите все отпечатки и весь контент. Таким образом, все (userID и object_iD) установлено в NULL или 999. И если я делаю жесткое удаление, тогда мне нужно физически удалить фотографию из моей файловой системы.

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

---

Платформа: MySQL, codeIgnitorPHP, выделенная среда хостинга.

Answer 1

Для истинного «жесткого удаления», когда удаляется вся вспомогательная пользовательская информация, вы можете использовать ON DELETE CASCADE для своих внешних ключей или вы можете просто удалить из вспомогательных таблиц перед удалением родительской записи.

Для «полужесткого удаления», когда вы удаляете запись пользователя, но сохраняете вспомогательную информацию (кстати, дизайн, с которым я никогда не сталкивался), вы можете использовать ON DELETE SET NULL.Однако идея разрешения пустых значений в столбце внешнего ключа дает мне хитрость (как вы можете быть уверены, что это должна быть удаленная запись, а не «потерянная» запись существующего пользователя?) Так что если вам нужно сохранитьКак бы вы ни предлагали, я бы хотел создать специальную запись пользователя, которая будет содержать эту потерянную информацию.

Answer 2

1. Правильно: ON UPDATE CASCADE не имеет значения, если User_ID не разрешено изменять. Это хорошо.

2. Это призыв к суду с вашей стороны. Я бы сказал «Нет», использование RESTRICT является хорошим значением по умолчанию. Однако, если вы хотите удалить данные при удалении User_ID, тогда ON DELETE CASCADE может иметь смысл - но, вероятно, нет. ON DELETE SET NULL не подходит.

3. Вопрос в двух частях - ответьте аналогично.

   (A) Хорошо удалить материал; мне кажется нехорошим не удалять весь материал, как вы указываете, что будете делать. Материал вряд ли будет полностью анонимным (неопознаваемым) - некоторые будут, некоторые будут содержать ссылки, позволяющие идентифицировать его. Итак, вы должны (конечно, IMNSHO) удалить полностью - поэтому я рекомендую вариант (B) ниже. Если вы не можете или не хотите, то повторная привязка данных с помощью общего «идентификатора удаленного пользователя» умеренно хороша - по крайней мере, после удаления нескольких десятков пользователей будет достаточно мусора, чтобы ввести в заблуждение содержание. Конечно, вам нужно сделать больше, чем это, чтобы анонимизировать данные; вам нужно будет удалить или сбросить отметки времени и т. д. Сиротские данные не будут доступны; это должно быть удалено.

   (B) Это лучший вариант - удаление всего означает удаление всего. Конечно, у вас, вероятно, есть проблемы с архивами базы данных; информация извлекается из них. Возможно, это выиграет от правил ON DELETE CASCADE. Вы, вероятно, сделаете первоначальное удаление, пометив User_ID как удаленный («мягкое удаление»). После ограниченного периода (от 24 часов до 7 дней, я полагаю), вы сделаете жесткое физическое удаление. На этом этапе данные пользователя будут формально удалены, возможно, автоматически с помощью каскадных правил удаления, возможно, путем «ручной очистки» таблиц (то есть автоматизированного процесса, который принимает идентификатор_пользователя и выполняет удаление всех свидетельств своего существования как владелец чего угодно). Обратите внимание, однако, что другие люди могут по-прежнему иметь контент, который ссылается на уже не существующего пользователя; на самом деле чрезвычайно трудно удалить всю запись.