Ramsey is right. There are lots of pitfalls.
Losing FK constraints is a pain and I miss it, but it's something I can deal
with … not ideal, but not a killer.
Reassigning IDs and merging data is the biggest problem and we are helped by
the fact that most of our data comes to us and is loaded from a serialized
form… so we just do that on the rare occasions we have to migrate some data.
That bit of gymnastics has the side benefit of being able to move small chunks
of data through the serialization instead of doing an entire db.
So far we haven't run into the situation of relating DB1 to DB2 primarily
because the client databases are separate by policy and necessity. The scope of
the data should never be seen between databases. That's a policy thing that
helps us avoid that problem.
So with all the problems in focus, here is the way I aim the bullets at my feet:
public void setEMRDatabaseConnection(Center c) throws MalformedURLException {
if (getEc().userInfo().containsKey("db")
&& getEc().userInfoForKey("db").equals(c.db()))
{
logger.info("keeping connection to " + c.db() + " for
center "
+ c.name());
} else {
ec.dispose();
ec = null;
ec = ERXEC.newEditingContext();
logger.info("connecting to " + c.db() + " for center "
+ c.name());
Object[] args = { c.host(), c.db() };
String url = String.format(VASession.URL_FORMAT, args);
NSMutableDictionary<String, String> cdict = new
NSMutableDictionary<String, String>();
cdict.takeValueForKey(url, "URL");
ERXEOAccessUtilities
.closeDatabaseConnections((EOObjectStoreCoordinator) this.getEc()
.rootObjectStore());
EOUtilities.connectWithModelNamed(this.getEc(),
GenerateManagmentReports.EMR_MODEL_NAME, cdict);
getEc().setUserInfoForKey(c.db(), "db");
getEc().setUserInfoForKey(c.host(), "host");
getEc().setFetchTimestamp(System.currentTimeMillis());
ec.invalidateAllObjects();
getEc().refreshAllObjects();
}
}
I get a bit draconian in trying to make sure the editing context is fresh and
clean, but this is the general idea for connecting to the database that is
specific to the "Center"
Larry Mills-Gahl
On Dec 20, 2012, at 7:40 PM, Ramsey Gurley <rgur...@smarthealth.com> wrote:
> You lose FK constraints that way too. I would not break up the database if
> you need relationships between the models. That includes in the future.
>
> Even if you don't have relationships, think about what happens when a client
> with more than one enterprise wants to move data between the two databases or
> possibly merge them? PK collisions, fk collisions. Nightmare code trying to
> follow relationships and reassign IDs.
>
> Worst of all, I can imagine a day when the client will dream up some reason
> why they need to relate data between DB1 and DB2. Then you are truly pooched.
> No siree, I'd simply add a column to the model indicating which enterprise
> the data belongs to and put everything in one database. Otherwise, I think
> you're setting yourself up for a world of hurt.
>
> Ramsey
>
> On Dec 20, 2012, at 5:01 PM, Michael Gargano wrote:
>
>> yes, I'm doing that now. just be aware that cross db joins are a b*tch.
>> if there are to many relations to join across you will quickly hit
>> limitations with IN clauses (which will be your best friend). unless
>> someone else has come up with something more clever than what I'm doing
>>
>> -Mike
>>
>> On Dec 20, 2012, at 6:45 PM, Miguel Torres <w...@toracom.net> wrote:
>>
>>> Hi list,
>>>
>>> We are developing an ERP application.
>>> We want to use the following approach:
>>>
>>> One database to storage users, access control rules, application
>>> configuration and an enterprises catalog.
>>>
>>> For each enterprise we want to set up a different database.
>>>
>>> For example: One ERP controlling information of two enterprises would need
>>> three databases:
>>> ApplicationDatabase
>>> EnterpriseOneDatabase
>>> EnterpriseTwoDatabase
>>>
>>> We are doing this because we believe this is more efficient in the long
>>> term with clients that have more than one enterprise.
>>>
>>> We have two Data base Models in the application
>>>
>>> ErpApplicatioEOModel
>>> ErpEnterpriseEOModel
>>>
>>> The main page is a Login form where the user selects the Enterprise she
>>> wants to work with. After the user logins successfully we want to set the
>>> database connection information in the ErpEnterpriseEOModel.
>>>
>>> Is that possible?
>>>
>>>
>>> Thanks in advanced.
>>>
>>> Saludos, Miguel Torres.
>>>
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
>>> Help/Unsubscribe/Update your Subscription:
>>> https://lists.apple.com/mailman/options/webobjects-dev/mgargano%40me.com
>>>
>>> This email sent to mgarg...@me.com
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/webobjects-dev/rgurley%40smarthealth.com
>>
>> This email sent to rgur...@smarthealth.com
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/webobjects-dev/elemgee%40gmail.com
>
> This email sent to elem...@gmail.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
