Как обрабатывать заблокированные учетные записи в MySQL

Question

Как обрабатывать заблокированные учетные записи в MySQL

0

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

Я очень хорошо знаком с написанием запросов sql/ddl в существующей базе данных (строго mysql-консоль, Spring MVC, Boot, Java и т.д.). Но не с тех пор, как в колледже мне пришлось рассмотреть нормализацию, 2nf, 3nf, 1:1, 1: many и т.д. Это был скромный опыт, если не сказать больше, пытаясь обновить мою память с изученными годами теории баз данных прежде чем пытаться применять эти понятия.

Я создал модель, которая, по крайней мере, мне кажется, соответствует потребностям пользователей

Мой конкретный вопрос касается заблокированных учетных записей. Я прочитал несколько сообщений об этом, что только смутило меня больше о том, как подойти к этой концепции с моей данной моделью данных? Я действительно был бы признателен за любые другие предложения и/или критику; Я определенно понимаю концепцию и силу обучения неудачей.... Спасибо.

Вариант использования:

1. Users holding office in a particular year can sign into the web 
   application, and view their information *(Name, Account Status, 
   Ordained, Team number, Calendar of their assigned duty days)*. 
   They can only update their personal info (name, address, 
   phone). Note: The account will be created for users.

2. Director, Asst. Director and System admin can log into the web 
   application (admin dashboard) and see a data table of all users, 
   w/ all relevant fields(view). This group has full read-write 
   privileges.

У меня есть заблокированная таблица в модели, но не уверен, что это правильный способ справиться с обновлением статуса пользователя от активного до неактивного. Если он неактивен, он не может войти в веб-приложение. Я также использовал бы это, если пользователь попытается входить в систему больше x раз подряд неудачно. Кроме того, было бы полезно (отчетность и статистика) сохранить предыдущих пользователей в базе данных за х лет, конечно же, с неактивным статусом.

suffa 15 май 2018, в 20:26

Источник

0

Не уверен, почему вы чувствуете необходимость в выделенном locked столе. Столбец users.is_disabled может быть достаточно. Кроме того, может существовать user_actions аудита user_actions которой вы можете хранить изменения для users (или аналогичная таблица для любого объекта, который вам нужен аудит).
Victor Sorokin 15 май 2018, в 18:01
0

Спасибо @VictorSorokin за ответ. Не обязательно нужно больше, чем мне, быть новичком в моделировании БД и не быть уверенным в лучших практиках ... Сначала я думал, что столбца is_diabled будет достаточно, но он показался слишком простым. Не могли бы вы привести элементарный пример таблицы аудита users_actions вместе с таблицей users в форме автоответчика, просто чтобы я мог визуализировать? Мой стиль обучения = визуальный ученик. Спасибо!
suffa 15 май 2018, в 18:13

Теги:

mysql

java

spring-boot

mysql-workbench

1 ответ

Ещё вопросы

Не уверен, почему вы чувствуете необходимость в выделенном locked столе. Столбец users.is_disabled может быть достаточно. Кроме того, может существовать user_actions аудита user_actions которой вы можете хранить изменения для users (или аналогичная таблица для любого объекта, который вам нужен аудит).
Спасибо @VictorSorokin за ответ. Не обязательно нужно больше, чем мне, быть новичком в моделировании БД и не быть уверенным в лучших практиках ... Сначала я думал, что столбца is_diabled будет достаточно, но он показался слишком простым. Не могли бы вы привести элементарный пример таблицы аудита users_actions вместе с таблицей users в форме автоответчика, просто чтобы я мог визуализировать? Мой стиль обучения = визуальный ученик. Спасибо!

Victor Sorokin · Accepted Answer · 2018-05-15T16-37-00.000Z

Извините за использование диаграммы (я не использую инструменты диаграммы). Здесь чрезвычайно базовая выборка с соответствующими битами для таблицы аудита:

CREATE TABLE users (
  user_id SERIAL,
  -- ...
);
-- ...
CREATE TABLE user_updates_audit (
  audit_id SERIAL,
  user_id INT NOT NULL,
  audit_timestamp TIMESTAMP NOT NULL default now(),
  -- just free form text describing applied update (maybe old value, new value, etc)
  audit_text VARCHAR(1024) NOT NULL
);

ALTER TABLE user_updates_audit ADD CONSTRAINT user_updates_audit_pk PRIMARY KEY (audit_id);
ALTER TABLE user_updates_audit ADD CONSTRAINT user_updates_audit_user_id_fk FOREIGN KEY (user_id) REFERENCES users;

Разумеется, вы можете перейти отсюда, например, изменив произвольную форму audit_text на более строгую схему, например, внешний ключ для словаря возможных действий по обновлению (ENABLED, DISABLED, whatever) и фактические значения, которые изменяются. Или еще одна более сложная схема, более подходящая для вашего дела.

Но аудит свободной формы является отправной точкой.

Основное значение здесь заключается в том, что вы можете просмотреть историю изменений важных объектов в вашей системе, а не только текущее состояние.