Olá Pessoal,
Passando por algumas experiências profissionais, venho até vocês através deste tópico expor uma nova forma de desenvolvimento como no título "Banco de Dados Relacional Distribuído MS Access". Esta nova forma de desenvolvimento foi desenvolvida ao me deparar com um problema muito grande. Há algum tempo atrás fiz uma consultoria para um empresa de porte médio que possuía todo o seu sistema em Access. E como todos sabem, o desempenho do Access fica muito baixo do normal quando seu arquivo excede 2GB de tamanho físico. Minha sugestão aos Superiores da empresa foi para passarem para uma plataforma de dados maior desempenho - o Microsoft SQL Server, mas como não quiseram então tive que dar meus pulos!
Existe uma forma conhecida no SQL Server como Schema (Esquema). Os Schemas foram criados pela Microsoft para que o DBA possa separar e organizar as tabelas do seu banco de dados em grupos. Como exemplo imagine um pequeno CRM: nele você teria que cadastrar dados de clientes, então obviamente criaríamos um Schema chamado "Clientes", e a partir deste Schema então começaríamos a criar as tabelas como "Dados Pessoais"; "Contatos Telefônicos"; "Endereços Eletrônicos"; "Endereços" e etc. Dentro da Base de Dados do SQL Server ficaria assim:
Tabelas
Clientes.DadosPessoais
Clientes.ContatosTelefonicos
Clientes.EnderecosEletronicos
Clientes.Enderecos
Como no Access a possibilidade do ponto (.) na nomeação das tabelas foi retirada pela Microsoft, então tive que desenvolver uma forma que aproximasse do Schema do SQL Server. Criei uma solução prática que é a distribuição de dados. Funciona da seguinte forma: ao invés de criarmos uma única base de dados no Access para controlar Tabelas, Consultas, Formulários, Relatórios e Macros, criamos várias base de dados como se fosse nosso Schema, exemplo:
CRM
BDAuxiliar - (As Tabelas desta base começariam com as 3 letras a sua escolha do nome da base de dados "sem contar o BD" retirando a sigla "TBL")
AUXEstadosCivis
AUXTiposDeContatos
AUXTiposDePessoas
...
BDGeografico - (As Tabelas desta base começariam com as 3 letras a sua escolha do nome da base de dados "sem contar o BD" retirando a sigla "TBL")
GEOContinentes
GEOPaises
GEOUnidadesDaFederacao
GEOEstados
GEOMunicipios
GEOCoordenadas
...
BDClientes - (As Tabelas desta base começariam com as 3 letras a sua escolha do nome da base de dados "sem contar o BD" retirando a sigla "TBL")
CLTDadosPessoais
CLTContatosTelefonicos
CLTEnderecosEletronicos
CLTEnderecos
...
Quando fossemos fazer a parte gráfica, ou seja, o desenvolvimento das regras, formulários, relatórios e consultas, então vincularíamos todas as tabelas das outras base de dados dando mais segurança para os dados e deixando a base de dados menos carregada, pois assim estaríamos separando entre Banco de Dados e Manipulação de Dados. E o motivo de trocar a sigla "tbl" já conhecida e muito usado das Tabelas do Access é pelo seguinte, quando você for vincular as tabelas das outras base de dados saberá de qual base de dados a tabela está vinculada, por exemplo:
Você criou um formulário de dados de clientes, mas o código é atribuído pela empresa (como foi no meu caso). Dessa forma, você teria que criar uma regra no formulário para que o sistema alertasse o usuário de que o código inserido no formulário já existe e está sendo usado por outro cliente. Neste caso uma das formas mais simples é o DLookup() e funcionaria da seguinte forma:
Outra coisa muito importante também são as Imagens, pois na maioria dos desenvolvimentos que já via até hoje são incorporadas no próprio formulário do banco de dados. Particularmente eu acho que isso deixa o Access mais pesado em relação ao seu tamanho físico, o que deixa ainda mais conforme o crescimento dos dados na base de dados, mais lento e difícil o desempenho do banco de dados.
A estrutura de pastas também é muito importante, pois a mesma ajuda-o a organizar o projeto de sua aplicação neste caso. Ela é formada por diversas pastas com uma estrutura padronizada. Eis o exemplo abaixo:
PastaPaiDoSistema
Aplicação
Nesta pasta estariam as base de dados destinadas à regra de negócio, ou seja, Formulários, Relatórios...
Banco de Dados
Aqui estariam todas as base de dados destinadas ao armazenamento de dados.
Imagens
Esta pasta é responsável pelas imagens do sistema (não usar imagens incorporadas no formulário e sim vinculadas).
Ícones
Aqui estariam todos os ícones de sua aplicação.
Documentações
Pasta destinada a documentações de seu sistema.
...
O exemplo acima foi usada por mais de 3 empresas de Porte Médio, funcionou muito bem com um aumento na capacidade de mais de 80% do que o modelo tradicional do Access. Por favor, aos grandes mestres e todos deste fórum gostaria de ter um feedback com suas críticas ou elogios sobre o assunto!
E breve estarei postando um exemplo, aguardem!
Cumprimentos!
Este tópico o ajudou? Agradecer não custa nada e ainda nos motiva a continuar lhe ajudando. Então que tal dar um joinha ?
Passando por algumas experiências profissionais, venho até vocês através deste tópico expor uma nova forma de desenvolvimento como no título "Banco de Dados Relacional Distribuído MS Access". Esta nova forma de desenvolvimento foi desenvolvida ao me deparar com um problema muito grande. Há algum tempo atrás fiz uma consultoria para um empresa de porte médio que possuía todo o seu sistema em Access. E como todos sabem, o desempenho do Access fica muito baixo do normal quando seu arquivo excede 2GB de tamanho físico. Minha sugestão aos Superiores da empresa foi para passarem para uma plataforma de dados maior desempenho - o Microsoft SQL Server, mas como não quiseram então tive que dar meus pulos!
Existe uma forma conhecida no SQL Server como Schema (Esquema). Os Schemas foram criados pela Microsoft para que o DBA possa separar e organizar as tabelas do seu banco de dados em grupos. Como exemplo imagine um pequeno CRM: nele você teria que cadastrar dados de clientes, então obviamente criaríamos um Schema chamado "Clientes", e a partir deste Schema então começaríamos a criar as tabelas como "Dados Pessoais"; "Contatos Telefônicos"; "Endereços Eletrônicos"; "Endereços" e etc. Dentro da Base de Dados do SQL Server ficaria assim:
Tabelas
Clientes.DadosPessoais
Clientes.ContatosTelefonicos
Clientes.EnderecosEletronicos
Clientes.Enderecos
Como no Access a possibilidade do ponto (.) na nomeação das tabelas foi retirada pela Microsoft, então tive que desenvolver uma forma que aproximasse do Schema do SQL Server. Criei uma solução prática que é a distribuição de dados. Funciona da seguinte forma: ao invés de criarmos uma única base de dados no Access para controlar Tabelas, Consultas, Formulários, Relatórios e Macros, criamos várias base de dados como se fosse nosso Schema, exemplo:
CRM
BDAuxiliar - (As Tabelas desta base começariam com as 3 letras a sua escolha do nome da base de dados "sem contar o BD" retirando a sigla "TBL")
AUXEstadosCivis
AUXTiposDeContatos
AUXTiposDePessoas
...
BDGeografico - (As Tabelas desta base começariam com as 3 letras a sua escolha do nome da base de dados "sem contar o BD" retirando a sigla "TBL")
GEOContinentes
GEOPaises
GEOUnidadesDaFederacao
GEOEstados
GEOMunicipios
GEOCoordenadas
...
BDClientes - (As Tabelas desta base começariam com as 3 letras a sua escolha do nome da base de dados "sem contar o BD" retirando a sigla "TBL")
CLTDadosPessoais
CLTContatosTelefonicos
CLTEnderecosEletronicos
CLTEnderecos
...
Quando fossemos fazer a parte gráfica, ou seja, o desenvolvimento das regras, formulários, relatórios e consultas, então vincularíamos todas as tabelas das outras base de dados dando mais segurança para os dados e deixando a base de dados menos carregada, pois assim estaríamos separando entre Banco de Dados e Manipulação de Dados. E o motivo de trocar a sigla "tbl" já conhecida e muito usado das Tabelas do Access é pelo seguinte, quando você for vincular as tabelas das outras base de dados saberá de qual base de dados a tabela está vinculada, por exemplo:
Você criou um formulário de dados de clientes, mas o código é atribuído pela empresa (como foi no meu caso). Dessa forma, você teria que criar uma regra no formulário para que o sistema alertasse o usuário de que o código inserido no formulário já existe e está sendo usado por outro cliente. Neste caso uma das formas mais simples é o DLookup() e funcionaria da seguinte forma:
- Código:
Private Sub SEUCAMPO_AfterUpdate()
Dim VerificarCodigo
VerificarCodigo = DLookup("CodigoDoCliente", "CLTDadosPessoais", "CodigoCliente = '" & Me.SEUCAMPO & "'")
'Então sua condição por aqui
End Sub
Outra coisa muito importante também são as Imagens, pois na maioria dos desenvolvimentos que já via até hoje são incorporadas no próprio formulário do banco de dados. Particularmente eu acho que isso deixa o Access mais pesado em relação ao seu tamanho físico, o que deixa ainda mais conforme o crescimento dos dados na base de dados, mais lento e difícil o desempenho do banco de dados.
A estrutura de pastas também é muito importante, pois a mesma ajuda-o a organizar o projeto de sua aplicação neste caso. Ela é formada por diversas pastas com uma estrutura padronizada. Eis o exemplo abaixo:
PastaPaiDoSistema
Aplicação
Nesta pasta estariam as base de dados destinadas à regra de negócio, ou seja, Formulários, Relatórios...
Banco de Dados
Aqui estariam todas as base de dados destinadas ao armazenamento de dados.
Imagens
Esta pasta é responsável pelas imagens do sistema (não usar imagens incorporadas no formulário e sim vinculadas).
Ícones
Aqui estariam todos os ícones de sua aplicação.
Documentações
Pasta destinada a documentações de seu sistema.
...
O exemplo acima foi usada por mais de 3 empresas de Porte Médio, funcionou muito bem com um aumento na capacidade de mais de 80% do que o modelo tradicional do Access. Por favor, aos grandes mestres e todos deste fórum gostaria de ter um feedback com suas críticas ou elogios sobre o assunto!
E breve estarei postando um exemplo, aguardem!
Cumprimentos!
Este tópico o ajudou? Agradecer não custa nada e ainda nos motiva a continuar lhe ajudando. Então que tal dar um joinha ?