hi patrick, > Not a reason, but an idea: To physically divide the projects. One project > belongs to one client. So a person who works on "project1" has nothing to do > with "project2". Sure, I could use ACLs, but with different databases it is > more separated. > Also client #1 may >want< to use his own database. And > client #2's project might be very large and generate a lot of traffic, so he > >should< use his own database. Well, was it understandable? yes. however a content repository's persistence layer could be configured to for example separate the different workspaces into different persistence layers (like different databases) [possibly even different sections of the tree]
> It's just an idea after all. So if you tell me that this would produce too > much overhead or simply would not work in a way, I'm fine with it and will > use the (all-in-one) tree based approach. i would start with the all in one tree solution (using access control) just for simplicity reasons and possibly extend it from there, once you have the customer requirement to actually have the projects in different repositories... does that make sense? regards, david
