#php #mysql #sql
#php #mysql #sql
Вопрос:
Итак, чтобы сделать мой проект дружественным к GDPR, я должен удалить все данные клиента через 90 дней.
Вот как выглядит sales таблица (входные данные приведены только для примера) с использованием phpMyAdmin:
| ID | CUSTOMER | EMAIL | PRODUCT | DATE |
| 1 | Ken James | ken.jam@example.com | 4816419 | 2019-12-25 10:26:19 |
| 2 | Amy Wen | amywen@example.com | 6662341 | 2019-11-23 10:26:19 |
| 3 | Chris Pet | chripet@example.com | 4816419 | 2019-05-05 10:26:19 |
Могу ли я каким-то образом автоматически заменить CUSTOMER и EMAIL только на XXXXXX , если DATE значение старше 90 дней?
Комментарии:
1. ДА. Запустите какое-нибудь запланированное задание для запроса к базе данных, проверьте наличие дат старше 90 дней и измените другие поля. В некоторые ядра баз данных встроена эта возможность (например, задания агента SQL в MS SQL Server), в других случаях вам, возможно, придется запускать его с помощью запланированной задачи / задания cron в операционной системе
2. P.S. Я ни в коем случае не эксперт по GDPR, и я не юрист, но AFAIK, нет конкретного требования удалять данные через 90 дней. Как вам понадобилось это требование? GDPR требует, чтобы вы указали, как долго вы будете хранить информацию пользователя, это не требует конкретного расписания. Вы сами установили это ограничение по времени?
3. Вы должны хранить электронную почту в таблице customers, а не в таблице sales.
4. Удаление всех данных клиента через 90 дней может быть «приемлемым для GDPR», но это не является требованием в соответствии с GDPR.
Ответ №1:
Вы можете использовать встроенный планировщик.
Но это должно быть включено
CREATE EVENT event1
ON SCHEDULE EVERY '1' DAY
STARTS '2020-08-17 00:00:01' -- should be in the future
DO
UPDATE sales
SET EMAIL = 'xxxxxxxx', CUSTOMER = 'xxxxxxxx'
WHERE EMAIL <> 'xxxxxxxx' AND CUSTOMER <> 'xxxxxxxx' AND `DATE` < DATE_ADD(NOW(), INTERVAL -90 DAY);
Комментарии:
1. Таким образом, вы перемещаете свое приложение и его логику в базу данных. Худший сценарий за всю историю.
2. чтобы периодически запускать запросы, вам нужно использовать schelduler, и не имеет значения, где вы запускаете iot — из приложения-оболочки или сервера mysql
3. Но вы должны сохранить логику внутри кода вашего приложения, а не внутри какого-то волшебного события внутри базы данных. Меня бы уволили и посмеялись над моей работой, если бы я предложил такое решение.
4. приложение не открыто 24/7, поэтому периодическое удаление в течение 90 дней не может быть запущено в приложении, оно должно быть запущено на сервере. такие запросы на обслуживание всегда выполняются на сервере. и код работает независимо от того, где он выполняется
Ответ №2:
Вы можете сделать следующее:
UPDATE *table_name*
SET CUSTUMER = 'xxxxxxx', EMAIL = 'xxxxxxx'
WHERE CURRENT_DATE() - DATE > 90;
CURRENT_DATE() возвращает дату текущей даты
(Вы также можете использовать GETDATE() вместо CURRENT_DATE())
Ответ №3:
Возможно, это слишком длинно для комментария.
90 дней кажутся немного агрессивными, исходя из того, что я знаю о GDPR.
Тем не менее, то, что вы делаете, довольно опасно, по крайней мере, с аналитической и финансовой точки зрения. Знание того, что клиент совершил несколько покупок за прошедшее время, может быть весьма важным. И в GDPR довольно четко указано, что вы можете сохранять историческую информацию об активных (и недавно бывших) клиентах. (Конечно, я не юрист, и даже если бы я им был, вы должны с большим подозрением относиться к бесплатному advie через Интернет.)
Тем не менее, ваша sales таблица должна быть спроектирована так, чтобы соответствовать требованиям конфиденциальности. Как? Сохраните информацию о клиенте в другой таблице.
Итак, sales таблица должна выглядеть следующим образом:
| ID | CUSTOMERID | PRODUCT | DATE |
| 1 | 1 | 4816419 | 2019-12-25 10:26:19 |
| 2 | 2 | 6662341 | 2019-11-23 10:26:19 |
| 3 | 3 | 4816419 | 2019-05-05 10:26:19 |
Эта таблица идеально подходит с точки зрения конфиденциальности, предполагая, что CUSTOMERID используется строго внутри компании.
После этого у вас должна быть CUSTOMERS таблица:
| CUSTOMERID | CUSTOMER | EMAIL | LASTSALEDATE |
| 1 | Ken James | ken.jam@example.com | 2019-12-25 10:26:19 |
| 2 | Amy Wen | amywen@example.com | 2019-11-23 10:26:19 |
| 3 | Chris Pet | chripet@example.com | 2019-05-05 10:26:19 |
Это таблица, в которой вы можете заменить имя, адрес, электронную почту, номер телефона и так далее на NULL значения (или 'XXXX' , если вы предпочитаете).
Эта структура позволяет вам вести внутреннюю историю повторных покупок и дат покупок и так далее — даже когда данные были анонимизированы. Помещая все личные данные в одно место, их легче поддерживать, проверять и обеспечивать соответствие требованиям GDPR и других законов о конфиденциальности.