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.
