I had a similar situation years ago. We had software that helped automate online promotions for music releases. Everyone insisted on keeping their data separate; forcing different databases was required by contract and we were strong-armed into it. Today, things would be different.
I ended up having everything in a different client-specific database for each promotion. The "company" stuff , like our global email/user directory, was handled in a "company" database. Originally, I used SQL users and permissions that would give read/write to the "company" and a single client. Eventually, I moved all of the "company" stuff into a centralized service -- multiple applications would talk to that service instead of the database. The reason for all this trickery was a mix of permissions/security, DB administration ( being able to distribute different clients onto different machines ), and reporting/analysis usage that was much simpler with a per-database option. there were a few other things I can't remember. it was still f*** pain, and we ran into performance issues as we couldn't recycle database connections as aggressively as i wanted. we sometimes had legacy projects that could tie up db connections for newer projects that were more popular. Given the chance, I would never touch something like that again. I just want to bring this up, because database connections do end up being an issue. if you've got a single db connection string, you can really be aggressive with your connections. If you have multiple db connection strings, you have to think about planning for database connectivity. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
