Cita:
Iniciado por Libras 
y porque mejor no haces una tabla para auditoria? donde tengas todos esos datos mas el nombre de la tabla ;) y listo te evitas el tener los mismos campos en cada tabla :P
Libras! Me gusta esa idea, nunca lo hice porque en las veces que vi ejemplos o estudié algún concepto lo vi hecho de esta manera, porque en realidad si te pones a pensar, el campo xlj_status_id es una FK de la tabla status que pueden ser varios, esto no se puede cambiar, luego, conceptualmente los campos created_by, created_at, updated_by y updated_at son de auditoria, no son atributos que pertenezcan a una tabla específica, desde la parte conceptual obvio. Pero técnicamente se repiten y hacen como bien decís las tablas no estén ni en le 3 forma normal...
Los campos id_user_bloqueo también es una FK así que no molesta, y el campo version, me lo obliga a poner el framework Yii2 para los bloqueos optimistas, ya que trae un método para poder controlar la versión de los registros.
Ahora mi consulta en base a lo que sugerís que me interesa mucho, es la siguiente:
Actualmente con la estructura como la tengo, con eventos del mismo framework que actúan como triggers de base de datos, pero son de aplicación, guarda automáticamente el usuario y la fecha con una expresión NOW, esos campos por cada INSERT o UPDATE.
Si lo hago como lo dices, deberé en cada uno de los métodos de INSERT o UPDATE insertar un registro en la tabla_auditoria, luego para recuperarlos en las vistas de la aplicación, deberé o unir los datos de las tablas o realizar joins no es así? este es óptimo para resultados de más de 500 o 1000 registros por página? Mi cliente necesita ver por cada persona quién la crea a qué hora y quién modifica un registro.
Bueno espero no haber abusado de tu tiempo.
Saludos y gracias nuevamente!