Re: Hiding data model

From: MARK BRINSMEAD <mark.brinsmead_at_gmail.com>
Date: Wed, 28 Jan 2015 17:26:00 -0500
Message-ID: <CAAaXtLAVNHLKuhRZ6wBeyYQ_zu+R3uoz+FOC9PKxpp41v0By9g_at_mail.gmail.com>



Indeed.

  There have been many times where I have contacted software vendors to report errors in their application code, or even their design. And to supply the fixes.

   Why would you choose to cut yourself off from thousands of free troubleshooters, some of whom are probably better than any you can afford to keep on your own payroll?

   That aside, a common side-activity for DBAs is to *evaluate* potential software purchases. When faced with competing products, one with a well-documented data model and the other with a "closed" or "obfuscated" data model, I will always favour the open one. The better I am able to understand a product, the better I am able to support it.

   You can be certain that an obfuscated data dictionary will shut you out of at least some sales opportunities.

On Wed, Jan 28, 2015 at 3:15 PM, Hans Forbrich <fuzzy.graybeard_at_gmail.com> wrote:

> On 28/01/2015 4:39 AM, Harmandeep Singh wrote:
>
>> 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
>>
>>
> One solution - put the protection into the contract. Model leaks out, you
> get to sue the customer.
>
> Otherwise, realize that the data dictionary (which is different from,
> albeit related to, the data model) is the primary tool the DBA has to
> ensuring your product can be secured and tuned.
>
> The DBAs are actually on your side. Why tick them off?
> /Hans
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>

--
http://www.freelists.org/webpage/oracle-l
Received on Wed Jan 28 2015 - 23:26:00 CET

Original text of this message