yeah, that's the pain i'm trying to avoid :) i'll probably end up managing multiple connections, but that's a particular design of my app (plugin based, multiple subprocesses, and so on) ... :)

On 04/08/2014 06:48 PM, Jonathan Vanasco wrote:
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.

Reply via email to