Реализация журнала аудита - AOP Spring по сравнению с в спящем режиме перехватчик по сравнению с триггером DB
сразу после этого ....
require 'dbHandler.inc.php';
положить, поставить или поставить сразу после вызова mysqli_real_connect () или mysqli_connect () ...
@mysqli_query ( $conn, "SET NAMES 'utf8mb4' COLLATE 'utf8mb4_unicode_ci';");
4 ответа
I only can talk about Triggers and NHibernate, because I don't know enought abou tSpring AOP.
It depends on, as always, what is most important for you.
DB triggers
- are fast
- are always called, even from native SQL, Scripts, external apps.
- write data in the DB of which NH doesn't know about. It will be missing in the current session. (Which could lead to unexpected results)
- do usually not know anything about your session (say: login name).
NHibernate interceptors / events
- are not DBMS specific.
- allow you easy access to you business information, like the user session, client machine name, certain calculations or interpretations, localization, etc.
- allow you declarative configuration, like attributes on the entity, which define if the entity needs to be logged and how.
- allow you turning off logging, this could be important for upgrades, imports, special actions that are not triggered by the user.
- allow you an entity view to the business model. You are probably closer to the users point of view.
I can't think of any good reason for not using database triggers to audit changes to the database. Inserts, updates and deletes can potentially hit the database from various sources - triggers will catch all these; Hibernate etc. will not.
Я думаю, когда вы думаете об одитинге, вам нужно подумать, для чего он нужен. Во-первых, необходимо иметь информацию о том, кто изменил что и что изменилось, чтобы вы могли откатывать плохие изменения, вы могли идентифицировать проблемы с системой (мы можем видеть, какое из нескольких различных приложений вызвало изменение, что помогает быстро определить, какое из них повреждено) и так вы можете определить, кто сделал изменение. Последнее может быть действительно критическим, когда дело доходит до обнаружения мошенничества. Если вы делаете все из пользовательского интерфейса, вы никогда не увидите пользователя, совершающего мошенничество, который изменяет данные в бэкэнде, чтобы выписать себе чек. Если вы делаете все из интерфейса, скорее всего, вам нужно установить права доступа на уровне таблиц, что открывает возможности для мошенничества. Если вы все сделаете из интерфейса, вы не будете знать, какой недовольный сотрудник удалил всю пользовательскую таблицу за чистое значение раздражения. Если вы сделаете все из внешнего интерфейса, вы не узнаете, какой некомпетентный dba случайно обновил все заказы одного и того же клиента. Я не могу поддерживать использование чего-либо, кроме триггеров для одитинга, так как вы теряете значительную часть того, зачем вам в первую очередь нужен одитинг.
Скорее всего, вам нужно установить права доступа на уровне таблиц, что открывает возможности для мошенничества. Если вы все сделаете из интерфейса, вы не будете знать, какой недовольный сотрудник удалил всю пользовательскую таблицу за чистое значение раздражения. Если вы сделаете все из внешнего интерфейса, вы не узнаете, какой некомпетентный dba случайно обновил все заказы одного и того же клиента. Я не могу поддерживать использование чего-либо, кроме триггеров для одитинга, так как вы теряете значительную часть того, зачем вам в первую очередь нужен одитинг. Скорее всего, вам нужно установить права доступа на уровне таблиц, что открывает возможности для мошенничества. Если вы все сделаете из интерфейса, вы не будете знать, какой недовольный сотрудник удалил всю пользовательскую таблицу за чистое значение раздражения. Если вы сделаете все из внешнего интерфейса, вы не узнаете, какой некомпетентный dba случайно обновил все заказы одного и того же клиента. Я не могу поддерживать использование чего-либо, кроме триггеров для одитинга, так как вы теряете значительную часть того, зачем вам в первую очередь нужен одитинг. Не знаю, какой некомпетентный DBA случайно обновил все заказы одного и того же клиента. Я не могу поддерживать использование чего-либо, кроме триггеров для одитинга, так как вы теряете значительную часть того, зачем вам в первую очередь нужен одитинг. Не знаю, какой некомпетентный DBA случайно обновил все заказы одного и того же клиента. Я не могу поддерживать использование чего-либо, кроме триггеров для одитинга, так как вы теряете значительную часть того, зачем вам в первую очередь нужен одитинг.Использование перехватчиков Hibernate для ведения журналов аудита глубоко ошибочно. Я ошеломлен количеством блогов, которые рекомендуют этот метод, не указывая на его наиболее очевидный недостаток - перехватчик ДОЛЖЕН использовать новую транзакцию для записи аудита. Это означает, что вы можете успешно сохранить основную транзакцию и получить сбой системы, при котором не удается записать транзакцию аудита!