July 21, 2006 at 8:24 am
I do have a contructive thought, build a routine in your application that will check the structural integrity of the tables. Run it when the application is started and don't let the application continue if the test fails.
Spell it out to the clients that they can look at the data and structure but don't touch and let them know what will happen if they do. (If you want to get by on the cheap, tell the clients this is what will happen and don't take the time to implement it.)
Is the desire to not let the clients look at the data and structure really a strategy to provide for a cash flow? Are you afraid that they might pull the data out (for whatever reason) and not come to you to provide some custom programming for them?
July 21, 2006 at 9:16 am
It's both. We're trying to protect the data of course because it's very sensitive. Sys Admin should not know what those data are even in the clients end. Second is to protect intellectual properties of the application. Having clients not look at the data and structure so that hopefully they can't reverse engineer and find out the workflow of the application is our main strategy to provide cash flow. I have solved the data part by encrypting sensitive fields but i'm looking a way in SQL somehow to restrict our clients to look at the data structure. After reading a lot in this post, and I really appreciate of giving you thoughts, it seems like we can't really do anything to protect the data structure of our database when the clients has Sys Admin rights to the database.
July 21, 2006 at 9:51 am
I'm curious, what kind of industry are you in where the data does not belong to the client? I've done a lot of application development in my day and all of them provided file layouts in the documentation.
July 21, 2006 at 9:51 am
1. Sysadmin will always have the ability to know everything in the database. Data & Schema. That is what makes it SysAdmin.
2. I suggest that you get some legal aid before you decide to try to keep people from seeing data that they own. You're just asking for trouble there.
3. Start doing some searches for people trying to hide database schemas (like yourself). What you'll find is that at the end of the day, your schema doesn't really do anything that special. Really. Honest.
All you are going to do by "Having clients not look at the data and structure..." is turn a ton of people off to buying and using your product.
"...reverse engineer and find out the workflow of the application..."
There is another one. The rules that should be in the database are data rules. Not business rules.
The history of software development is littered with applications that attempt to do what you are saying you want to do. Lock people in.
The reality is that the thing that makes software successful is that it does something useful for the consumer. Period.
Instead of spending your time trying to lock people out of the database (which honestly isn't going to happen), I would advise you dedicate your resources to making your software the best it can be.
Sorry if that sounded harsh, but I'd rather tell you what I think and maybe help you out than BS you about it.
Best o' luck.
-Don
July 21, 2006 at 10:36 am
I totally agree on all your response. Trust me, I've done a lot of development also in my days and I told them that this is not doable even in SQL 2005. Since I'm new to the company and don't know the politics around here, I told them that I would look more deeper on the issue. That's why I ask you, SQL gurus, to help on this issue just in case there's something that I overlook with functionalities in SQL 2005.
We're in the tax/compliance software business and I think there's a new mandate, SAS 7..., that states we have to protect the data and/or clients from themselves. They interpreted this as clients should not be able to look into the data and also the structure.
I guess there will be a lot more battles with management in convincing them that this feature is not available. Also, is there any functionality in Oracle that can solve this problem or are all RDMS will have this issue? I'm asking because management is threating to maybe go with oracle if I won't be able to provide this functionality to them? Can you please put your .02 cents on this topic since I don't know much about Oracle?
Thanks!
Dex
July 21, 2006 at 11:31 am
I whole heartedly agree with Don. Maybe some of those reasons can be presented to the powers that be. I have no clue what you are talking about when you mention SAS 7 but I think encryption of strategic data fields should be sufficient.
Steve
July 21, 2006 at 11:33 am
Who interpreted it?
IMHO, someone needs to talk to specialists for this one.
It doesn't make any sense to me at all.
Viewing 7 posts - 16 through 21 (of 21 total)
You must be logged in to reply to this topic. Login to reply