I set it up, so that all the security stuff was sequestered into its own "silo." This allows things like using monitoring and logging, or a hardened host, without affecting the main datastore.
The deal is, is that I expect the tech to get swapped out, down the line, for something more modern, and it might not even use SQL. But security is quite important (especially with the target user base of the initial release). I went kind of overboard with some structural support for security. I am quite aware that I could get better performance from a single, related DB, but I wanted to start off with an infrastructure-level support for security, with the anticipation of future tech making up for any performance issues.
In my experience, security is often spackled on, after the fact, and I think that it's important to start from scratch, with security.
Also, note the ridiculous simplicity of the DB schemas. That was because I used...yecchhh object-oriented design as the Model, and the datastore actually represents a generic base class state. This allowed me to write a whole bunch of code, early on, and test it, then never have to look at it again. The implementation was done in layers, over a period of seven months. Each layer was treated as a standalone project, with its own lifecycle and testing. The idea was to develop a robust structure that I could consider reliable, then build on top of that.
It worked fairly well.
