Relação entre tabelas Provedor ASPNET Sócios e Tabelas personalizadas de Sócios

Question

Eu passei por um perfil personalizado exemplo provedor há um tempo atrás e estou agora revisitar-lo.

Meu banco de dados tem todos os dbo.aspnet_ * tabelas criadas quando eu corri o registro aspnet Mago. Nessas tabelas Eu tenho aspnet_Profile que tem uma restrição que aponta FK para aspnet_Users.

Eu também tenho duas tabelas em MyDB: A primeira, dbo.ProfileData, tem uma restrição de chave estrangeira apontando para dbo.Profile.

O que eu quero fazer é compreender como as tabelas em MyDB relacionar com aqueles em dbo.aspnet_ *. Não deveria haver uma restrição de chave estrangeira (ou algum tipo de relacionamento) entre as tabelas em seu perfil em MyDB e as tabelas ASPNET? alguma discussão de como minhas tabelas personalizadas se relacionar com aqueles fornecidos pelo aspnet seria maravilhoso.

Obrigado antecipadamente.

Answer 1

Existem duas opções que eu posso ver, os quais renderão basicamente o mesmo resultado:

• FK de dbo.aspnet_User.UserID para dbo.Profile.UserID, em seguida, definir uma chave única em dbo.Profile.UserID (a menos que você usá-lo como a coluna PK para dbo.Profile)

• FK de dbo.aspnet_Profile.ProfileID para dbo.Profile.ProfileID

dbo.aspnet_User é logicamente 1-1 com dbo.aspnet_Profile, por isso realmente não importa o que se aproximar de você usar como você ainda vai ter a mesma integridade relacional.

Se você estiver substituindo a tabela de perfis de dados padrão com sua própria implementação, em seguida, faz mais sentido usar a primeira sugestão, caso contrário, se você está estendendo o esquema do perfil, em seguida, usar a segunda sugestão.

Editar

aspnet_Profile é a tabela padrão - as lojas SqlProfileProvider padrão dados do perfil do usuário como um saco de propriedade serializada em aspnet_Profile, daí porque não existe uma tabela aspnet_ProfileData separado também.

Esta abordagem permite que o esquema de perfil para ser facilmente personalizados para diferentes aplicações sem a necessidade de qualquer alteração no banco de dados subjacente, e é a solução mais ideal para um quadro, como .NET. A desvantagem é que o SQL Server não têm fácil acesso a esses dados em tudo, por isso é muito mais difícil de índice, atualização e consulta os dados do perfil do usuário usando T-SQL e lógica baseada em conjunto.

A abordagem mais comum que tenho visto para remover esta limitação é estender o SqlProfileProvider padrão para escrever a uma tabela de dados de perfil personalizado que tem colunas específicas para propriedades de perfil de aplicação específica. Esta tabela, naturalmente, tem uma relação de 01/01 com o quadro de aspnet_Profile, por isso, tem uma chave estrangeira, conforme indicado acima.

O papel do provedor estendida é promover propriedades do perfil específicas para colunas durante as gravações em seu perfil, e ler nas colunas quando o perfil é recuperado.

Isso permite que você misturar e combinar soluções de armazenamento em base de necessidades como, contanto que seu provedor estendida sabe como cair de volta para a implementação padrão onde não 'saber' sobre uma determinada propriedade.

Eu sempre acho que é melhor deixar as tabelas de associação padrão como está, e se estendem quando necessário, utilizando as novas tabelas com chaves estrangeiras apropriadas, então subclasse o provedor apropriado e substituir os métodos provedor com sua própria implementação (chamando para a base implementação sempre que possível).