Хранение логов

@h6784rfg6 · Регистрация: 12.09.2013

Студворк — интернет-сервис помощи студентам

Здравствуйте форумчане,

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

Допустим есть реляция пользователь и реляция объявление. Между ними состоит отношение 1:m. До сих пор я создаю отдельные реляции "добавляет", "удаляет", "меняет". В них как мне представляется будут храниться дата действия, соответсвутющие foreign keys ну и еще пару значений.

Допустим пользователь меняет данные объявления. В БД создается запись в реляции "меняет", которая содержит новое и старое значение измененного поля. Администратор открывает свой инструментарий и видит, что поменял пользователь.

Данный подход правильный? Если нет, то какой был бы предпочтительнее?

И где стоит хранить такого рода данные? В той же БД или создать отдельную?

@Tatikoma · 25.10.2014, 01:25

Сообщение от h6784rfg6

И где стоит хранить такого рода данные? В той же БД или создать отдельную?

Зависит от количества данных. Если размер вашей базы менее 1ГБ, то вам вообще без разницы что и где.

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

Выносить архивные данные можно в какой-нибудь распределенный noSQL, или можно использовать MySQL (или MariaDB), - там есть прекрасная опция которая позволяет хранить эти данные в сжатом виде.

Новые блоги и статьи Все статьи Все блоги /
Отправка уведомления на почту при изменении наименования справочника Maks 24.03.2026 Программная отправка письма электронной почты на примере изменения наименования типового справочника "Склады" в конфигурации БП3. Перед реализацией необходимо выполнить настройку системной учетной. . .	модель ЗдравоСохранения 5. Меньше увольнений- больше дохода! anaschu 24.03.2026 Теперь система здравосохранения уменьшает количество увольнений. 9TO2GP2bpX4 a42b81fb172ffc12ca589c7898261ccb/ https:/ / rutube. ru/ video/ a42b81fb172ffc12ca589c7898261ccb/ Слева синяя линия -. . .	Midnight Chicago Blues kumehtar 24.03.2026 Такой Midnight Chicago Blues, знаешь?. . Когда вечерние улицы становятся ночными, а ты не можешь уснуть. Ты идёшь в любимый старый бар, и бармен наливает тебе виски. Ты смотришь на пролетающие. . .	Контроль уникальности заводского номера - вариант №2 Maks 24.03.2026 В отличие от предыдущего варианта добавлено прерывание циклов, также добавлены новые переменные для сохранения контекста ошибки перед прерыванием цикла: Процедура ПередЗаписью(Отказ, РежимЗаписи,. . .
SDL3 для Desktop (MinGW): Вывод текста со шрифтом TTF с помощью библиотеки SDL3_ttf на Си и C++ 8Observer8 24.03.2026 Содержание блога Финальные проекты на Си и на C++: finish-text-sdl3-c. zip finish-text-sdl3-cpp. zip	Жизнь в неопределённости kumehtar 23.03.2026 Жизнь — это постоянное существование в неопределённости. Например, даже если у тебя есть список дел, невозможно дойти до точки, где всё окончательно завершено и больше ничего не осталось. В принципе,. . .	Модель здравоСохранения: работники работают быстрее после её введения. anaschu 23.03.2026 geJalZw1fLo Корпорация до введения программа здравоохранения имела много невыполненных работниками заданий, после введения программы количество заданий выросло. Но на выплатах по больничным это. . .	Контроль уникальности заводского номера - вариант №1 Maks 23.03.2026 Алгоритм контроля уникальности заводского (или серийного) номера на примере нетипового документа выдачи шин для спецтехники с табличной частью, разработанного в конфигурации КА2. Данные берутся из. . .

@h6784rfg6 0 / 0 / 0 Регистрация: 12.09.2013 Сообщений: 25

	Хранение логов 24.10.2014, 10:27. Показов 1297. Ответов 1 Метки нет (Все метки) Здравствуйте форумчане, Для бэкенда приложения необходимо иметь инструментарий для того, чтобы видеть, что добавил, удалил или изменил данный пользователь. Допустим есть реляция пользователь и реляция объявление. Между ними состоит отношение 1:m. До сих пор я создаю отдельные реляции "добавляет", "удаляет", "меняет". В них как мне представляется будут храниться дата действия, соответсвутющие foreign keys ну и еще пару значений. Допустим пользователь меняет данные объявления. В БД создается запись в реляции "меняет", которая содержит новое и старое значение измененного поля. Администратор открывает свой инструментарий и видит, что поменял пользователь. Данный подход правильный? Если нет, то какой был бы предпочтительнее? И где стоит хранить такого рода данные? В той же БД или создать отдельную? 0