|
|
Posted by MC on 01/05/07 20:59
Well, first off, I really dont see the need to divide data in different
databases just for security issues. Permissions granularity shoudl give you
all you need.
As far as the referencing stuff goes, you cant add foreign keys across
databases. You can only programatically maintain data consistency. You can
select data from diff databases, but you cant declaratively maintain
consistency.
MC
"Ted" <r.ted.byers@rogers.com> wrote in message
news:1168028487.999025.302010@38g2000cwa.googlegroups.com...
>I am construvcting a number of databases, some of which contain
> sensitive data and most of which do not. I am attempting to handle the
> security issues involved in protecting sensitive data in part by
> putting it in its own database. If the sensitive data is in a database
> called d_SensitiveData, and in that database there is a table called
> 't_A' (I know, not very informative, but this is only a trivially
> simple example :-), and I have a script running in a database
> 'NotSensitiveData' (i.e. there is a statement at the beginning of the
> script "USE NotSensitiveData"), how do I referenece the primary key in
> table 'A'?
>
> I tried a variety of things like:
>
> ALTER TABLE t_nsX
> ADD CONSTRAINT FK_PersonID FOREIGN KEY (p_idPerson)
> REFERENCES SensitiveData.t_A (p_idPerson);
>
> The above is, in fact, my latest attempt. Everything I tried has
> failed precisely at the point where I specify a table in a different
> database. So what is the trick to refering to a table in one database
> when using another database?
>
> This will be used in a ASP.NET v3 application where one of the things I
> want to do is have the authentication provider be a different database
> from the one used for the main application data.
>
> Does anyone know of an example I can download from the web that does
> the same sort of thing I want to try, with some discussion of security
> issues involved (i.e. what I can do to harden the application and data
> server)?
>
> NB: I am an application developer, not a DBA nor a system
> administrator.
>
> Thanks
>
> Ted
>
[Back to original message]
|