Um pequeno MFC se conecta ao banco de dados MySQL para fazer login na instância via ODBC
Arquivo: n459.com/file/25127180-479633004 Senha de acesso: 551685
O seguinte é irrelevante:
-------------------------------------------Linha divisória----- ----------------------------------------
Na verdade, eu queria escrever artigos relacionados a bancos de dados distribuídos desde muito cedo, é o que estou estudando agora e também é algo que me interessa muito. Mas quando se trata de bancos de dados distribuídos, muitos detalhes técnicos relevantes estão envolvidos.Quando os detalhes relevantes são escritos de forma clara, mais de uma dúzia de artigos foram aprovados no XD. Portanto, se você quiser entender os detalhes técnicos da árvore B / B +, LSMT, CAP, etc., pode ler o artigo anterior. Hoje vamos falar sobre o conceito de NoSQL.
O significado geral de
noSQL NoSQL é muito popular agora. Nove em cada dez dos currículos que li estão familiarizados com noSQL, mas poucas pessoas podem explicar os detalhes por trás do noSQL, até mesmo o que significa não em noSQL Muitas pessoas cometem um erro. Este não não significa não, mas uma abreviatura de não apenas. Devo dizer que esta sigla é realmente trapaça, ninguém deveria ser capaz de adivinhar o que significa literalmente. E mesmo que seja interpretado não apenas como SQL, ainda está um pouco confuso e não é muito preciso para entender o que quer dizer.
Porque a palavra em inglês para SQL é linguagem de consulta estruturada, o que significa linguagem de consulta estruturada. Pode ser considerada uma linguagem de programação especial, mas o que significa "não apenas SQL"? É realmente intrigante, então não podemos entendê-lo literalmente, precisamos entendê-lo a partir de cenários reais de aplicativos.
Os cenários de aplicativos SQL são bancos de dados relacionais, como os comumente usados Oracle e MySQL, que são bancos de dados relacionais. Quando entendemos o banco de dados, geralmente começamos com a estrutura da tabela para entender. O que é armazenado no banco de dados é uma folha de tabelas, uma tabela é composta por linhas de dados e cada linha de dados possui um campo fixo. Acho que todos devem estar bem familiarizados com este ponto, mesmo que você não tenha aprendido o banco de dados ou tenha retornado ao professor como eu, você deve ter mais ou menos impressão.
Mas por que é chamado de banco de dados relacional em vez de banco de dados de estrutura de tabela?
Porque no banco de dados, o relacionamento é mais importante do que a estrutura da tabela. A estrutura da tabela é apenas um formulário e o conceito central de design no banco de dados é, na verdade, um relacionamento. É por isso que todos nós precisamos começar pelo diagrama ER quando aprendemos o banco de dados, ao invés de falar sobre o método de uso do banco de dados ou os detalhes da linguagem SQL. Se você não entende o significado desta frase, não importa, vamos primeiro colocá-la de lado e, finalmente, voltar a este tópico.
A questão é: sabemos que o banco de dados SQL comumente usado é um banco de dados relacional, então qual é o banco de dados representado pelo noSQL?
Eu vi pelo menos duas declarações sobre o conceito de noSQL, uma é banco de dados não relacional e a outra é banco de dados de documentos. Quando eu pessoalmente entendo, eu sinto que essas duas afirmações não são perfeitas, mas em comparação, a segunda afirmação é obviamente melhor, porque a primeira afirmação não nos fornece nenhuma informação. O documento no banco de dados de documentos não é o significado de um documento que geralmente entendemos, mas se refere à estrutura e à lógica central do armazenamento de dados.
Um exemplo vívido
Como a maioria dos conceitos técnicos, noSQL é relativamente obscuro e é difícil descrevê-lo claramente em linguagem. Portanto, decidi citar um exemplo animado com o qual todos estão familiarizados - o onipotente tesouro X.
A seguir está uma foto da página de detalhes do produto no tesouro X (selecione-a à vontade, não um anúncio, se houver uma coincidência, pague a taxa de promoção):
Todos devem estar familiarizados com esta imagem, e devemos tê-la visto muitas vezes em nossas atividades habituais de compras online. Parece um pouco deslumbrante. Nós abstraímos e condensamos o conteúdo acima e o desenhamos em um esboço. Ele se parece com isto (é um pouco desleixado):
Ou seja, dividimos aproximadamente o conteúdo exibido em uma página de detalhes do produto em três partes, uma parte é a imagem do produto, a outra parte é a descrição do produto e a outra parte é o comentário do usuário. O design das páginas de detalhes do produto das principais empresas de comércio eletrônico são semelhantes e alguns detalhes podem ser diferentes, mas os módulos gerais não são muito diferentes.
Para simplificar o problema, presumimos que a página de detalhes do produto precisa associar três tabelas de informações de imagem, descrição de texto e comentários do usuário. Na verdade, esta divisão não é científica. Por exemplo, a descrição do texto e o mapa do produto podem ser armazenados na tabela da página de detalhes do produto. Por exemplo, além dessas informações, também existem informações de vendas do produto, como estoque, preços, ofertas atuais, atividades, etc. Mas isso tem pouco a ver com nossas conclusões finais e pode ser simplesmente entendido como tal.
De acordo com o método de divisão acima, devemos procurar a imagem, o texto e as informações de comentário do produto de acordo com o itemId, o que obviamente não é problema na superfície. Mas, na verdade, isso é problemático.O problema é que esses dados não são um relacionamento um para um, mas um relacionamento um para muitos.
Por exemplo, geralmente há mais de uma imagem exibida na cabeça, o texto pode ter mais de um parágrafo e o mesmo usuário pode ter mais de um comentário. Como resolver este problema?
Você pode descobrir uma maneira. Não é difícil. Adicionamos o campo itemId às tabelas img, text e comment, e o associamos ao itemId quando fazemos a consulta, não é?
Claro que é possível fazê-lo. Supondo que você seja o programador responsável por este projeto, você fez essa atualização e, após o lançamento com sucesso, o produto trouxe um novo requisito. Ela disse que eu quero exibir imagens tanto na introdução do texto quanto nos comentários do usuário. Embora o sistema não tenha sido projetado assim no início, eu não me importo. Eu só preciso dele.
Você revirou os olhos por um tempo, se acalmou por um longo tempo e, depois de pensar sobre isso, finalmente pensou em duas opções. A primeira opção é adicionar um campo à tabela de imagens atual para determinar se a imagem é usada para exibição de página de detalhes ou comentários. A exibição da página, a introdução do texto a ser adicionada posteriormente e a imagem na página de comentários ainda existem nesta tabela. O segundo plano é reconstruir uma nova tabela, dedicada à tabela especial, responsável por armazenar as fotos da página de comentários e da página de descrição.
A vantagem da primeira solução é que não precisamos construir uma nova tabela, o que evita a redundância de tabelas.Se cada requisito precisa construir uma nova tabela, é obviamente um grande fardo para a manutenção subsequente. Mas sua desvantagem é que precisamos modificar todos os dados anteriores em lotes, porque não há campo de origem nos dados anteriores. Claro, você também pode usar id para distinguir sem este campo, mas isso não está em conformidade com a especificação e, inevitavelmente, deixará riscos de segurança.
A vantagem da segunda solução é a operação simples, sem necessidade de alterar os dados anteriores e menos risco de segurança, mas o problema é que ela precisa ocupar novos recursos e a taxa de utilização é baixa, pois algumas fotos da página de detalhes e fotos do topo podem ser compartilhadas. Se você os armazenar separadamente, precisará armazenar várias cópias.
Esses dois esquemas têm suas próprias vantagens e desvantagens, e ambos parecem bons, mas a armadilha é que todos eles têm uma desvantagem comum, ou seja, vão aumentar a complexidade do sistema e da consulta atuais. Uma é aumentar os campos passados durante a consulta e a outra é iniciar consultas adicionais. Qualquer que seja a seleção, o sistema ficará cada vez mais complicado. Mais tarde, quando chega uma solicitação do usuário, dezenas de solicitações de ligação serão direcionadas para reunir dados completos. Agora, a parte de introdução do produto da última versão da página de detalhes do X tesouro é sempre exibida com imagens, sem texto, talvez seja motivado por esse problema por trás disso.
Vamos revisar este exemplo. Por que nossa consulta é tão complicada está na verdade relacionado ao conceito central do banco de dados. Os dados armazenados no banco de dados relacional são o relacionamento. Neste problema, precisamos consultar a relação entre o produto e a imagem, a relação entre o produto e a descrição, a relação entre o produto e a análise, a relação entre a análise e a imagem, e assim por diante. Em outras palavras, a página que finalmente vemos é na verdade o resultado dessa série de relacionamentos. Atrás de cada consulta há um processo de decomposição de relacionamento e, em seguida, mesclagem, então será muito complicado.
Banco de dados de documentos
Acabamos de examinar os problemas de banco de dados relacional no cenário de e-commerce, vamos examinar o desempenho do banco de dados de documentos no mesmo cenário.
Ao contrário dos bancos de dados relacionais, o núcleo do armazenamento de banco de dados de documentos são os documentos. Claro, o documento aqui não se refere ao documento em nosso sentido usual, mas aos dados no formato json ou xml. Entre os bancos de dados noSQL atuais, os dados json são mais comumente usados. Também usamos o exemplo da página de detalhes agora mesmo para ver como esses dados são armazenados no banco de dados noSQL:
{ "ItemID": 123, "itemName": "iPad Pro", "topImgs": ["imgs1.path", "imgs2.path"], "desc": [{"text": "iPad Pro", " img ":“ ”}, {“ text ”:“ 2020 new version ”,“ img ”:“ imgs1.path ”}], “ comments ”: [{“ userName ”:“ chengzhi ”,“ comment ”:“ good product "," imgs ": [" imgs3.path "," img4.path "]}] } Você vê, no banco de dados de documentos, o complexo agora requer várias consultas e uma série de processamento antes de poder ser encaixado Os dados podem ser obtidos por meio de uma consulta por meio do itemID.
Simplesmente falando, é muito mais conveniente do que bancos de dados relacionais, mas tem suas deficiências. Um dos grandes problemas é que armazenamos todos os dados diretamente no documento, o que por um lado causa redundância de dados, por outro, também limita a escalabilidade. Por exemplo, produtos semelhantes no mesmo comerciante não podem compartilhar fotos, mas devem armazenar várias cópias, o que causa perda de espaço. Para outro exemplo, suponha que queremos oferecer suporte aos usuários para modificar os comentários anteriores antes que seja muito problemático, porque temos que encontrar todos os documentos que armazenam comentários do usuário para modificar (assumindo que os comentários do usuário também são usados em outros cenários), que muitas vezes é entre sistemas e Muito inconveniente.
Este problema não tem solução. Por exemplo, podemos substituir os dados específicos armazenados no documento por um id. Por exemplo, a imagem específica e as informações do comentário não são mais armazenadas no comentário, mas o id de um comentário é armazenado e, em seguida, associado ao usá-lo. . Devido à estrutura do banco de dados de documentos, o suporte para associação não é bom, e muitas vezes precisamos consultar manualmente com base no ID para simular a conexão, o que também trará sobrecarga adicional.
Outra pequena falha é que o caminho para acessarmos os dados no banco de dados de documentos ficou mais longo. Por exemplo, adicione que queremos a primeira foto no segundo artigo da análise do produto. Precisamos escrever item ['comentários'] [1] ['imgs'] [0], e em bancos de dados relacionais, uma vez que as imagens são consultadas diretamente por meio de relações, é mais conveniente.
Além disso, os anos de desenvolvimento de bancos de dados noSQL são muito mais curtos do que aqueles de bancos de dados relacionais mais maduros, como o MySQL, portanto, os recursos suportados são relativamente pequenos.
Resumo
Por meio de um exemplo, comparamos vividamente a diferença entre bancos de dados relacionais e bancos de dados noSQL. Vamos voltar à questão do início do artigo: Por que precisamos começar com o diagrama ER ao aprender o banco de dados, em vez de aprender diretamente o princípio do banco de dados e seu uso?
Acho que depois de entender o exemplo acima, deve ser muito mais fácil olhar para este problema. Como a lógica central de um banco de dados relacional é armazenar relacionamentos, especificações de uso, várias técnicas e recursos são essencialmente desenvolvidos em torno desse núcleo. Se usarmos o banco de dados sem chegar a essa camada, é fácil nos perdermos. É dessa origem de muitas operações impensáveis. Por exemplo, alguém armazena o código da página de front-end no banco de dados, como concatenar o id em uma string para armazenar vários Valor e assim por diante. Isso também mostra que o conteúdo do livro clássico não é um absurdo, e cada capítulo tem sua função pretendida.Portanto, quando sentimos que algum conteúdo é inútil, pode não ser que o livro esteja errado, mas não o entendemos bem.