Why is there an emphasis to log reporting information through an application to a separate database? I have seen designs where a logging manager is available to every business layer class whether it needs it or not. This in itself can create overhead? I was thinking that reporting information logging should be done as a separate service if it needs (at all) to consumed within another application. Nonetheless, much of the data (especially where data is stored as schemaless xml) just wastes database space. Why are there so many bad designs such that it becomes difficult to respond to reporting requirements without changing, say three, different software layers? What design would you proposed to log reporting data so that a change in reporting requirements can be done with ease? Typically, a change in report requiremnets would involve a request to the capture of an addition field on a form.

Why is there an emphasis to log reporting information through an application to a separate database? 

I have seen designs where a logging manager is available to every business layer class whether it needs it or not. This in itself can create overhead? 

I was thinking that reporting information logging should be done as a separate service if it needs (at all) to consumed within another application. Nonetheless, much of the data (especially where data is stored as schemaless xml) just wastes database space. 

Why are there so many bad designs such that it becomes difficult to respond to reporting requirements without changing, say three, different software layers? 

What design would you proposed to log reporting data so that a change in reporting requirements can be done with ease? Typically, a change in report requiremnets would involve a request to the capture of an addition field on a form.

Why is there an emphasis to log reporting information through an application to a separate database? I have seen designs where a logging manager is available to every business layer class whether it needs it or not. This in itself can create overhead? I was thinking that reporting information logging should be done as a separate service if it needs (at all) to consumed within another application. Nonetheless, much of the data (especially where data is stored as schemaless xml) just wastes database space. Why are there so many bad designs such that it becomes difficult to respond to reporting requirements without changing, say three, different software layers? What design would you proposed to log reporting data so that a change in reporting requirements can be done with ease?

Why is there an emphasis to log reporting information through an application to a separate database? I have seen designs where a logging manager is available to every business layer class whether it needs it or not. This in itself can create overhead? I was thinking that reporting information logging should be done as a separate service if it needs (at all) to consumed within another application. Nonetheless, much of the data (especially where data is stored as schemaless xml) just wastes database space. Why are there so many bad designs such that it becomes difficult to respond to reporting requirements without changing, say three, different software layers? What design would you proposed to log reporting data so that a change in reporting requirements can be done with ease? Typically, a change in report requiremnets would involve a request to the capture of an addition field on a form.

Why is there an emphasis to log reporting information through an application to a separate database? I have seen designs where a logging manager is available to every business layer class whether it needs it or not. This in itself can create overhead? I was thinking that reporting information logging should be done as a separate service if it needs (at all) to consumed within another application. Nonetheless, much of the data (especially where data is stored as schemaless xml) just wastes database space. Why are there so many bad designs such that it becomes difficult to respond to reporting requirements without changing, say three, different software layers? What design would you proposed to log reporting data so that any change in reporting requirements can be done with ease?

Why is there an emphasis to log reporting information through an application to a separate database? I have seen designs where a logging manager is available to every business layer class whether it needs it or not. This in itself can create overhead? I was thinking that reporting information logging should be done as a separate service if it needs (at all) to consumed within another application. Nonetheless, much of the data (especially where data is stored as schemaless xml) just wastes database space. Why are there so many bad designs such that it becomes difficult to respond to reporting requirements without changing, say three, different software layers? What design would you proposed to log reporting data so that a change in reporting requirements can be done with ease?