Questions About Relationships

[Jonathan Wood]

I'm using the ASP.NET membership routines but had to create some of my own
tables to store additional user information (profiles won't work for me).

So far, so good. But it seems like I should really create a relationship
between the membership table aspnet_Membership and my own table in order to
have the database enforce the relationship, and, ideally, to also implement
automatically cascading deletes to avoid orphaned records in my own tables.

So I created a foreign key in my own table, and set up a relationship with
the UserId field in aspnet_Membership. But I'm new to this and I notice that
this makes a change to the aspnet_Membership table (VS tells me both tables
need to be saved).

I'm a little uncomfortable making changes to the existing tables. I'm not
completely certain I've set up the relationship correctly and would hate to
disable the membership tables and also I wonder about what happens if the
membership tables must be recreated for some reasons.

Anyone have any tips for me?

Thanks!

 

[Cowboy \(Gregory A. Beamer\)]

This is a "Feature" of the management studio and a primary reason I consider
it verbotten for changes on production systems.

You can script out the changes instead and strip out the portions that dink
with the ASPNET_Membership table or you can write the foreign key yourself,
if you like typing SQL. It is unlikely the changes to ASPNET_Membership will
cause you any harm, but there is no reason to alter it.

--
Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA

*************************************************
| Think outside the box!
|
*************************************************

 

[Jonathan Wood]

Cowboy,

This is a "Feature" of the management studio and a primary reason I
consider it verbotten for changes on production systems.

Not 100% clear on what is the "Feature." The fact that the relationship
requires changing the original table?

You can script out the changes instead and strip out the portions that
dink with the ASPNET_Membership table or you can write the foreign key
yourself, if you like typing SQL. It is unlikely the changes to
ASPNET_Membership will cause you any harm, but there is no reason to alter
it.

Hmm... I think you've lost me completely there. What would these scripts do.
The only think that seems to be changing the membership table is
establishing the relationship. I don't see that as something that I can
eliminate with scripts. I could write scripts to perform cascading updates
and deletes--could that be what you mean?

Thanks.