Boa arquitetura para informações do usuário em bancos de dados separados?

Unificando os dados

Como a autenticação foi independente entre os cinco projetos, você pode encontrar várias inconsistências:

• Identificadores diferentes. Por exemplo, se os identificadores de usuários forem endereços de e-mail, a mesma pessoa poderá se registrar com [email protected] para um projeto, [email protected] para outro e [email protected] para um terceiro. É praticamente impossível resolver esse problema: você pode ter uma ideia através da agregação de informações¹, mas não é suficientemente preciso e pode ser insuficiente em alguns casos².

• Inconsistência de padrões de dados. E se ambos os projetos precisarem saber onde o usuário está, mas o projeto 1 usa duas convenções de letras, como CA , enquanto o segundo usa o nome completo, como Canada ?

• Diferentes implementações de autenticação. Por exemplo, o projeto 1 usa SHA256 , enquanto o projeto 2 usa sal e SHA512 e o projeto 3 usa PBKDF2 ? Para resolver esse problema, você precisará armazenar todos os hash usados, o que significa ter uma tabela como esta:

  create table [People].[User]
  (
      ...
      [Mail] nvarchar(500) not null,
      [Salt] char(16) null, -- Salt used by project 1.
      [Hash] char(128) null, -- Hash used by project 1.
      [AlternateSalt] varchar(12) null, -- Salt used by project 4 and 5.
      [AlternateHash] char(64) null, -- Hash used by project 4 and 5.
      [ThirdHash] char(20) null, -- Hash (no salt) used by project 2.
      ... -- etc.
  )
  

  e faça verificações consecutivas até encontrar uma boa.

  O bom é que você pode progressivamente consolidar as senhas para os usuários, uma vez que eles se autentiquem. Por exemplo, se o usuário autenticar com êxito o SHA1 usado pelo quinto projeto, você poderá calcular e armazenar o PBKDF2 hash e salt e remover o hash SHA1 do banco de dados.

  Após um ano ou dois, se ainda houver usuários que não fizeram logon por um tempo, você poderá enviar um e-mail para informar que eles devem fazer o login se quiserem manter a conta.

• Senhas diferentes. A consolidação pode funcionar somente se o usuário estiver registrado em um projeto ou se ela usar a mesma senha para cada projeto. E se as senhas que ela usa para diferentes projetos não forem iguais? Você ainda precisa manter a capacidade de fazer logon com várias senhas.

• Dados diferentes. Se Vanessa Kelley disse que vive em Toronto para o projeto 1, e em Montreal para o projeto 2, qual é obsoleto?

Se as inconsistências forem muito importantes, há o risco de você nunca conseguir criar o logon unificado. Se houver poucas ou nenhuma inconsistência, a tarefa será bem fácil.

Unificando o processo

Depois de unificar os dados, você pode fornecer um processo comum para os cinco projetos. Você pode criar um serviço da Web que será acessado pelos cinco projetos ou modificar esses projetos para acessar diretamente o banco de dados comum. Provavelmente seria muito melhor usar um serviço da Web, em vez de permitir que aplicativos diferentes acessem o banco de dados.

Se você não pode modificar os projetos originais, muito ruim. Você pode sincronizar os dados entre os bancos de dados, mas não é fácil nem propenso a erros.

Ainda assim, você não quer que seu processo de logon comum use todos os cinco bancos de dados. Não apenas custa muito em termos de recursos, mas também torna todo o processo dependente de cinco bancos de dados. Se um deles estiver inativo, o processo de logon falhará.

^{¹ Exemplo: de acordo com os logs, os dois logons foram feitos a partir da mesma máquina, um às 15:00, o segundo às 03:15. Além disso, os cabeçalhos do navegador eram os mesmos, e o primeiro nome, sobrenome e data de nascimento são os mesmos.}

^{² Exemplo: se dois logons compartilham o mesmo nome e sobrenome, isso não significa nada. Duas pessoas podem compartilhar a mesma máquina ou usar o mesmo navegador também.}

Veja: link

Se você vai ter usuários em um banco de dados separado, tudo bem, mas você deve entender que a integridade referencial não pode ser garantida. Portanto, você deve fazer o melhor para mantê-lo (por meio da lógica do aplicativo, transação distribuída, disparador etc.) e deve manter as referências remotas minimizadas.

Em outras palavras, se você pretende ter uma chave estrangeira que se refere a um banco de dados remoto, é melhor criar uma tabela no banco de dados local que associe a chave remota a uma local, para que as tabelas locais possam se referir para a chave local em vez de diretamente para a remota.

Por exemplo, suponha que você tenha uma chave remota chamada "facebook_id" (e é um GUID). Em vez de fazer com que todas as suas tabelas locais façam referência direta, crie uma tabela chamada local_facebook_id, que armazena um ID localmente único juntamente com o facebook_id, e então faça com que todas as tabelas locais se refiram ao seu id local e não diretamente ao facebook_id. O benefício é que você obtém integridade referencial local em um único ponto de referência.

Além disso, você também pode expandir essa tabela local_facebook_id para armazenar em cache as credenciais e outras informações de perfil, para que, se o banco de dados remoto desaparecer ou a conta do usuário for excluída, os usuários do aplicativo ainda possam efetuar login com relação à tabela local_facebook_id credenciais. Além disso, ele conteria informações significativas sobre eles que, se a conta remota for permanentemente eliminada, seus dados locais permanecerão vinculados a uma fonte local de informações pessoais significativas (em vez de apenas um GUID sem sentido), que pode ser usada até mais tarde - vincule a conta local a um novo facebook_id (por exemplo, por endereço de e-mail ou alguma outra informação de identificação exclusiva).