On Aug 23, 2013, at 11:58 PM, Patrick Doran <[email protected]> wrote:
> -(Assuming the silos look the same) Create views in one database, which pulls > data from the silos and merges it with UNION ALL, including its identity in > one column. If necessary, use this identity as part of the key. Handle data > manipulation using INSTEAD OF triggers, redirecting inserts etc to the > corresponding database. Such views and triggers should be possible to create > with a bit of "scripting" > I really don't like triggers, they move business rules to the database and > become a bitch to maintain with installations. > Moving business rules to the database is bad, using triggers to solve a persistence problem is a very different thing. Maintaining it wouldn't necessarily be so hard. > -If possible use different setups (mapping, session factories, maybe even > separate code domains) for single vs. multi silo scenarios. > This is sort of what we are doing now with our standard dbs having their own > mappings to their fully qualified schema, but the whole system share a single > session factory I would strive to not use a single factory (except for with the trigger solution), unless there is a single underlying database. Also, it's perfectly possible to have different tables in one database stored in separated file groups, so you could have all the tables in one database, and separate them by schema. Not a big difference, but worth considering. Hacking the actual lazy loading sounds like a….world of hurt. /G -- You received this message because you are subscribed to the Google Groups "nhusers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/nhusers. For more options, visit https://groups.google.com/groups/opt_out.
