RE: Hiding data model

From: Mark W. Farnham <mwf_at_rsiz.com>
Date: Wed, 28 Jan 2015 14:11:13 -0500
Message-ID: <4dd401d03b2e$2f99fe20$8ecdfa60$_at_rsiz.com>



Tim and others have covered this pretty well. I don’t have any quibble with what they have written.  

Essentially the only way to hide your data model is to host the database server (as Mladen put it tongue in cheek “cut the network cable”) and provide the application functionality presented as a set of remote services.  

Even then you’re going to design an appropriate call and response interface for your application services that prevents “let’s take a peek at your database” attacks such as sql injection. I mention that one as an example that is commonly known.  

I think it is theoretically possible that there is proprietary value in the definition of a data model, but I have not yet observed a situation where the value of keeping the data model secret to preserve that proprietary value matched the value of sharing the data model with both customers and competitors. So even if your application functionality is amenable to be served as remote services, I would still recommend publishing your data model. Publishing, especially with a commentary regarding the purpose of the pieces of the model, will tend to improve your data model and your customer experience.  

Regards,  

mwf  

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Harmandeep Singh Sent: Wednesday, January 28, 2015 6:40 AM To: oracle-l-freelists
Subject: Hiding data model  

Hi Experts,  

We are having data model for our product, which we do not want to expose to our customers. That is we want even the DBA of customer with sys privileges should not understand /access the data model( like table definitions, columns ).  

I am aware of options like VPD, which is data level security feature as per my understanding.  

Please let me know your thoughts  

Thanks,

Harmandeep Singh  

--
http://www.freelists.org/webpage/oracle-l
Received on Wed Jan 28 2015 - 20:11:13 CET

Original text of this message