10-11-2012 03:21 PM
I've got a best-practices/business requirements question. For background, we are running SalesLogix 7.5 (SP2) in a LAN only environment currently. Backend is running SQL 2008 64-bit. We do not have any remotes nor are we running the Web or Mobile clients at this time. Although ideally we'd like to implement web/mobile clients after 8 is released and we upgrade.
We have several interal web services that are built that interact with the SLX back end database. A new service that we will be deploying soon is to track evals for some of our products. Because a subset of our users may want to have visibility of that data we want to store it in the SLX database. Idealy we would store it in SLX managed tables (added via DB Manager). However, the question has been raised as to why store those tables in SLX managed tables vs direct SQL tables and then enable them via SLX admin?
One of the major concerns is that we would need to generate the IDs for the table via the web service. While we can certainly do this, it's going to take some time to get the stored procedure or other method built. We've already seen the recommended reading from RJ Samp here:
It's not an issue that we can't do it, it's an issue of doing it in the short timeframe that we have vs managing the tables outside of SLX and simply letting SQL handle the ID generation.
So my question is, what benefit are we gaining (or losing) here?
So far, what I've come up with are:
- No support for remote databases since SLX doesn't manage the tables. (Not an issue for us since we don't have remotes)
- No field level security since SLX doesn't manage the tables. (I'm torn on if this is an issue or not. Only if we want field level security would it be an issue)
Is there anything else that this would cause a problem for?
10-11-2012 04:20 PM