Última vez Ficamos com uma importação muito simples e direta de tabelas SQL no Couchbase, com um documento por linha da tabela. Mas ainda há trabalho a fazer. As chaves primárias foram alteradas no processo, portanto, precisamos corrigir isso. E um banco de dados SQL não contém apenas tabelas. Há outras estruturas e funções que carregam a lógica comercial e que teremos de mover para a camada de aplicativos.
JUNTAR
A primeira coisa que quero fazer após a importação é executar o JOIN nos documentos, o que pode ser feito da mesma forma com um banco de dados SQL, pois é essencialmente um mapeamento exato. Não é tão simples quanto executar a consulta N1QL diretamente. O JOIN no N1QL só funciona na chave de um documento, e nós as alteramos na importação para evitar colisões. Portanto, precisamos alterar as diferentes chaves estrangeiras. A boa notícia é que isso é muito fácil de fazer com a Linguagem de Manipulação de Dados N1QL. Há suporte para ATUALIZAÇÃO, MERGE, INSERIR ou UPSERT.
|
1 |
cbq> ATUALIZAÇÃO padrão d CONJUNTO ID do idioma = "language::" || TOSTRING(d.ID do idioma) ONDE _tableName = "filme"; |
Essa consulta alterará o campo language_id de cada documento no bucket padrão que contém um campo _tableName definido como "film". O language_id deixará de ser um campo do tipo Number e passará a ser um String. Se você tinha 1, agora terá "language::1". Isso corresponderá à chave real do documento, pois foi isso que foi adicionado pelo RowMapper.
O operador '||' é usado para concatenação de strings. E como language_id era um número, você precisa usar o método toString para convertê-lo. Você precisará executar essa consulta para cada chave estrangeira em seu banco de dados. Depois disso, você deverá ser capaz de executar consultas N1QL com JOIN, NEST e UNNEST.
|
1 2 3 4 |
cbq> SELECIONAR * DE `padrão` AS a JUNTAR `padrão` AS b ON CHAVES a.ID do idioma; cbq> SELECT * DE `padrão` AS a NEST `padrão` AS b ON CHAVES a.ID do idioma; |
Sequência, visualização, acionador, domínio e função
Há algumas coisas que não podem ser migradas diretamente de um banco de dados SQL para o Couchbase. Mais especificamente, toda a lógica de negócios que você tinha no banco de dados SQL terá de ser transferida para a camada de aplicativos. Algumas são mais simples de transferir do que outras. Você pode decidir se ter a lógica de negócios na camada de dados é bom ou não. Embora eu não goste disso, entendo que muitos aplicativos diferentes podem usar o mesmo banco de dados e, portanto, a restrição expressa no nível do banco de dados pode ser uma coisa boa. Prefiro pensar que esses aplicativos devem depender de um serviço em vez de ir direto para o banco de dados.
Sequência
Uma sequência pode ser vista como uma Contador atômicoe é algo simples de criar:
|
1 2 3 4 5 6 |
JsonLongDocument rv = balde.contador(chave, 20, 100); LOGGER.informações("Delta=20, Initial=100. O valor atual é: " + rv.conteúdo()); rv = balde.contador(chave, 1); LOGGER.informações("Delta=1. O valor atual é: " + rv.conteúdo()); |
Visualizações
Uma visualização SQL pode ser vista como uma tabela dinâmica resultante de uma consulta SQL. No Couchbase, uma Ver é um índice (pense em um índice como uma tabela de duas colunas) criado dinamicamente usando uma função de mapa/redução incremental e depende principalmente da complexidade de sua visualização. Uma visualização é usada para apresentar dados em um contexto diferente. No NoSQL, quando você quer fazer isso, começa a desnormalizar os dados, o que os duplica. Portanto, tenha cuidado com o que está fazendo. Se esses dados precisarem ser modificados com frequência, desnormalizá-los pode não ser uma boa ideia (embora as coisas possam mudar com a API SubDocument em que estamos trabalhando). Aqui está um exemplo de View para lhe dar uma ideia:
Domínio
Um domínio SQL é um novo tipo (baseado em um tipo existente) com restrições integradas. No meu exemplo de SQL, um novo domínio chamado type é definido assim:
|
1 2 3 4 5 6 7 |
CRIAR DOMÍNIO público.ano AS inteiro CONSTRAINT year_check VERIFICAR (VALOR >= 1901 E VALOR <= 2155); ALTER DOMÍNIO público.ano PROPRIETÁRIO PARA postgres; |
Ele define um novo tipo chamado year a partir do tipo integer existente. Ele adiciona uma restrição dizendo que o valor de year deve estar entre 1901 e 2155. Para expressar essa restrição em Java, você pode usar uma estrutura de validação como Validador do Hibernate. Seu tipo de ano seria semelhante a este:
|
1 2 3 4 |
@Mínimo(1901) @Máximo(2155) privado int ano; |
Gatilho
Os acionadores são funções SQL executadas quando algo específico acontece no banco de dados, como um INSERT, DELETE ou UPDATE específico. É uma ótima maneira de reforçar a integridade de seus dados ou de automatizar operações. Não há equivalente no Couchbase Server, portanto, isso terá de ser transferido para a camada do aplicativo. Por exemplo, você pode reproduzir isso usando um barramento de eventos de aplicativos. Isso provavelmente poderia ser feito usando o DCP
Função
A maioria dos bancos de dados SQL permite que você defina suas próprias funções. No momento, isso não é possível com o N1QL. Toda a lógica que você coloca nessa função deve ser colocada na sua camada de aplicativo.
Conclusão
Agora você deve ter uma boa ideia de como migrar simplesmente de bancos de dados SQL para o Couchbase. Não posso deixar de enfatizar que esse é o caminho mais simples para a migração. Não há modelagem de dados envolvida aqui. Uma migração completa envolveria dar uma boa olhada no seu modelo de dados e ver o que pode ser desnormalizado.
Diga-nos o que você acha nos comentários abaixo. Ficaria feliz em saber se, por exemplo, você já fez uma migração de SQL e como fez isso :)
