Glad it helped!

Hi Greg,

Thanks a lot for your advice.  It all makes sense, in my case this application is for a customer in which I have total control of their network since I builded for them and provide Network Administration and Support services.

I am leaning toward using a separate security database in order to have the DDT projects separate and I consider the most changes will happen on the project database than with the security database.

Edhy Rijo

An alternative point of view is to use a separate security database, which is what I've done. As always, the situation dictates the solution. I chose this route for a few reasons:



1. I didn't want to use the DDT with my app db because it couldn't import a bunch of stuff that was heavily used by the app (I think some or most of this has been added now). However, using the DDT to deploy the security tables is the way to go. So I used a separate security db to speed deployment. This was the biggest reason I used a separate security db.

2. I have lots of dbs, one for production and several for testing with users using more than one. Using a separate security db allows for single sign on (note in my case Windows security isn't a good option an most people are remote, and not logged into a domain/workgroup under our control). Of course there can be complications with this, when the security db is updated, breaking older versions of the app...but that happens infrequently (er...never so far). Usually the other way occurs where an older version of the db breaks a newer version of the app (i.e. I forget to update the security db).

3. My app is an internally used app within the company, so I'm the one supporting it. If the application was sold to customers, I'm sure I would have put the security tables in the app db, for all the reasons Trent mentioned.



This is a more complicated approach, but SF RBS handles it well. From the stand point of the framework, either approach works well using the SF RBS. Hope this provides some more information.

Hi Trent,

Thanks for the advice.  So far playing with both scenarios I see SF can handle them pretty well.

Edhy Rijo

This is really entirely up to you and how you plan to design your databases.  We generally include the security tables in the same database as our primary application.  We have learned that it is easier to support fewer databases in the field especially as it relates to backup, maintenance, etc.  Additionally our service staff has an easier time comprehending fewer databases when dealing with the customers in the field.  We have had good success with this approach.  Though, there are times that other databases are necessary, but the security tables can still reside in your default or primary database.  The security tables will not consume many database resources...even over the life of the application.

Hi All,

I am setting up the Security Features in one of my projects and would like to know what is the preference for the Security Database to be used:

1. Use the same database where all the project's table will be included or
2. Use a separate database just for the security tables?

Thanks!

Edhy Rijo