Update 20230321-maldicaoTabelas.md

This commit is contained in:
Eduardo Dalcin 2023-04-18 08:49:55 -03:00 committed by GitHub
parent 06638539aa
commit f0c7b00281
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

View File

@ -20,8 +20,8 @@ Alguns conjuntos e dados sobre biodiversidade podem ser melhor representados sob
![](http://dalcinweb.s3-website-us-east-1.amazonaws.com/github/BiodivDadosMeta/maldicaoTabelas3.png)<br>
[https://jsoncrack.com/editor?json=6416148abbe4fd1e772fdc13](https://jsoncrack.com/editor?json=643968298251297a85d87841)
É claro que modelar e organizar conjuntos de dados tem que considerar a “implementação”. Ou seja, um “sistema gerenciador de banco de dados” (SGBD) capaz de lidar com a estrutura de dados específica. Lá no [artigo sobre grafos](https://eduardo.dalc.in/discutindo-a-relacao/) comentei que experimente o [Neo4J](https://neo4j.com/). Para lidar com documentos, tenho brincado bastante com o MongoDB, e estou trabalhando em um projeto para desenvolver uma ferramenta para converter arquivos Darwin Core para o formato JSON, que podem ser gerenciados pelo MongoDB, por exemplo.
É claro que modelar e organizar conjuntos de dados tem que considerar a “implementação”. Ou seja, um “sistema gerenciador de banco de dados” (SGBD) capaz de lidar com a estrutura de dados específica. Lá no [artigo sobre grafos](https://eduardo.dalc.in/discutindo-a-relacao/) comentei que experimente o [Neo4J](https://neo4j.com/). Para lidar com documentos, tenho brincado bastante com o [MongoDB](https://www.mongodb.com/), e estou trabalhando em um projeto para desenvolver uma ferramenta para converter arquivos Darwin Core para o formato JSON, que podem ser gerenciados pelo MongoDB, por exemplo.
Porém, o mais fascinante hoje é que estão surgindo soluções de bancos de dados “multi-modelos”, ou seja, que podem lidar com diferentes estruturas de dados (p.ex. grafos, documentos e tabelas) em uma mesma plataforma. Até poucos anos atrás, tínhamos sistemas de “persistência poliglota” (mais de um SDBG), de grande complexidade de implementação e manutenção. Hoje temos alternativas interessantíssimas de SGBDs, capazes de lidar com diferentes modelos de dados, como o ArangoDB, que lida com documentos, grafos e chave/valor; o Fauna (!), que combina o modelo relacional com documentos; e até o “queridinho” dos adeptos do modelo relacional, o PostgreSQL, já admite JSON como um tipo de dados válido em suas tabelas. Ou seja, não é por falta de “implementação” que não estamos avançando em novas, e mais apropriadas, formas de representar dados sobre biodiversidade.
Porém, o mais fascinante hoje é que estão surgindo soluções de [bancos de dados “multi-modelos”](https://dl.acm.org/doi/abs/10.1145/3323214), ou seja, que podem lidar com diferentes estruturas de dados (p.ex. grafos, documentos e tabelas) em uma mesma plataforma. Até poucos anos atrás, tínhamos sistemas de “persistência poliglota” (mais de um SDBG), de grande complexidade de implementação e manutenção. Hoje temos alternativas interessantíssimas de SGBDs, capazes de lidar com diferentes modelos de dados, como o [ArangoDB](https://www.arangodb.com/community-server/native-multi-model-database-advantages/), que lida com documentos, grafos e chave/valor; o [Fauna](https://fauna.com/features#document-relational) (!), que combina o modelo relacional com documentos; e até o “queridinho” dos adeptos do modelo relacional, o [PostgreSQL](https://www.postgresql.org/about/), já admite JSON como um tipo de dados válido em suas tabelas. Ou seja, não é por falta de “implementação” que não estamos avançando em novas, e mais apropriadas, formas de representar dados sobre biodiversidade.
Creio que estamos tão condicionados a pensar sob a forma de linhas e colunas, que chega a ser mais que uma “zona de conforto”. É quase que uma “maldição”! É claro que é preciso {capacitação, competência, etc.} para enxergar o mundo com outros olhos, e passar a utilizar modelos baseados, por exemplo, em documentos ou em grafos. Não necessariamente excludentes aos modelos relacionais clássicos. Porém, precisamos primeiro questionar os modelos existentes, demandar e propor novos modelos baseados em novas abordagens e tecnologias. Talvez, estejamos sofrendo para representar uma esfera, cegos pelas peças de LEGO®, sem olhos para a argila!
Creio que estamos tão condicionados a pensar sob a forma de linhas e colunas, que chega a ser mais que uma “zona de conforto”. É quase que uma “maldição”! É claro que é preciso {capacitação, competência, etc.} para enxergar o mundo com outros olhos, e passar a utilizar modelos baseados, por exemplo, em [documentos](https://www.mongodb.com/docs/manual/core/data-modeling-introduction/) ou em [grafos](https://neo4j.com/developer/data-modeling/). Não necessariamente excludentes aos modelos relacionais clássicos. Porém, precisamos primeiro questionar os modelos existentes, demandar e propor novos modelos baseados em novas abordagens e tecnologias. Talvez, estejamos sofrendo para representar uma esfera, cegos pelas peças de LEGO®, sem olhos para a argila!