EXISTE LIMITES DE CAMPOS EM UM BD ACCESS?
Estou desenvolvendo um programa de controle de estoque com representantes.
a loja possui +ou- 100 representantes. e 2000 produtos
Então estou pensando em colocar o saldo no mesmo cadastro de produtos, tipo:
Código
Descricao
Valor
Saldo1
Saldo2
Saldo3
até Saldo 100
Será q posso fazer isso?
tem limites?
a loja possui +ou- 100 representantes. e 2000 produtos
Então estou pensando em colocar o saldo no mesmo cadastro de produtos, tipo:
Código
Descricao
Valor
Saldo1
Saldo2
Saldo3
até Saldo 100
Será q posso fazer isso?
tem limites?
Tem sim, 254 campos
é uma opinião, mas eu não faria isso.
Eu construiria uma tabela, onde registasse, por representante:
1. Código do representante
2. Código do produto
3. Saldo
Para outras utilizações, você pode ir buscar as descrições à  s outra
Eu construiria uma tabela, onde registasse, por representante:
1. Código do representante
2. Código do produto
3. Saldo
Para outras utilizações, você pode ir buscar as descrições à  s outra
Não sei porquê mas a minha resposta saiu truncada.
Aqui
Para outras utilizações, você pode ir buscar as descrições à  s outra
eu escrevi:
Para outras utilizações, você pode ir buscar as descrições à  s outras tabelas.
E ainda:
Esta é a forma correcta de trabalhar em access, trabalhar com pequenas tabelas relacionadas entre si.
Aqui
Para outras utilizações, você pode ir buscar as descrições à  s outra
eu escrevi:
Para outras utilizações, você pode ir buscar as descrições à  s outras tabelas.
E ainda:
Esta é a forma correcta de trabalhar em access, trabalhar com pequenas tabelas relacionadas entre si.
Mas Joao, eu pensei em fazer no que vc disse mas imagine só 2000 produtos
e 100 representantes.
se os 100 representantes tivessem esses 2000 produtos eu teria uma tabela com
200.000 registros então eu iria duplicar um cadastro? isso seria certo?
gostaria de ter opiniões de vc's, como vc's usam para controlar saldo de um programa de estoque onde tem vários representantes.
Imagine uma empresa de cosmético onde ela tem uns 1000 representantes, e isso pode aumentar, e esta empresa tem 2000 produtos q tb podem aumentar. agora quero controlar o estoque q tem com meus representantes, como posso fazer isso?
Mais uma vez Obrigado.
e 100 representantes.
se os 100 representantes tivessem esses 2000 produtos eu teria uma tabela com
200.000 registros então eu iria duplicar um cadastro? isso seria certo?
gostaria de ter opiniões de vc's, como vc's usam para controlar saldo de um programa de estoque onde tem vários representantes.
Imagine uma empresa de cosmético onde ela tem uns 1000 representantes, e isso pode aumentar, e esta empresa tem 2000 produtos q tb podem aumentar. agora quero controlar o estoque q tem com meus representantes, como posso fazer isso?
Mais uma vez Obrigado.
Número de caracteres em um nome de tabela
64
Número de caracteres em um nome de campo
64
Número de campos em uma tabela
255
Número de tabelas abertas
2048. O número real pode ser menor devido a tabelas abertas internamente pelo Microsoft Access.
Tamanho da tabela
1 gigabyte
Número de caracteres em um campo Texto
255
Número de caracteres em um campo Memorando
65.535 ao inserir dados através da interface do usuário,
1 gigabyte ao inserir dados programaticamente.
Tamanho de um campo Objeto OLE
1 gigabyte
Número de Ãndices em uma tabela
32
Número de campos em um Ãndice
10
Número de caracteres em uma mensagem de validação
255
Número de caracteres em uma regra de validação
2.048
Número de caracteres em uma descrição de tabela ou de campo
255
Número de caracteres em um registro (excluindo campos Memorando e Objeto OLE)
2.000
Número de caracteres em uma definição de propriedade de campo
255
Abs
64
Número de caracteres em um nome de campo
64
Número de campos em uma tabela
255
Número de tabelas abertas
2048. O número real pode ser menor devido a tabelas abertas internamente pelo Microsoft Access.
Tamanho da tabela
1 gigabyte
Número de caracteres em um campo Texto
255
Número de caracteres em um campo Memorando
65.535 ao inserir dados através da interface do usuário,
1 gigabyte ao inserir dados programaticamente.
Tamanho de um campo Objeto OLE
1 gigabyte
Número de Ãndices em uma tabela
32
Número de campos em um Ãndice
10
Número de caracteres em uma mensagem de validação
255
Número de caracteres em uma regra de validação
2.048
Número de caracteres em uma descrição de tabela ou de campo
255
Número de caracteres em um registro (excluindo campos Memorando e Objeto OLE)
2.000
Número de caracteres em uma definição de propriedade de campo
255
Abs
exite sim cara, o numero de campos em cada tabela é de 255
Deixe-me só acrescentar algo ao que já tinha dito:
1. 200.000 registos ao contrário do que se possa pensar, não é um exagero para o access tenho tabelas com mais de 500.000 e muitos mais campos dos que os que referi a trabalhar perfeitamente e sem qualquer problema;
2. Quanto á questão de uma empresa com 1.000 representantes e 2.000 produtos, então eu aconselharia a utilizar SQL Server ou Oracle.
Aliás mesmo com apenas 100 representantes se for para todos poderem acessar a base de dados directamente aconselho vivamente a não utilizar access.
1. 200.000 registos ao contrário do que se possa pensar, não é um exagero para o access tenho tabelas com mais de 500.000 e muitos mais campos dos que os que referi a trabalhar perfeitamente e sem qualquer problema;
2. Quanto á questão de uma empresa com 1.000 representantes e 2.000 produtos, então eu aconselharia a utilizar SQL Server ou Oracle.
Aliás mesmo com apenas 100 representantes se for para todos poderem acessar a base de dados directamente aconselho vivamente a não utilizar access.
Uma outra coisa pra pensar...
vc quer colocar 100 campos certo?
E se por algum motivo, aumento mais campos?
Será que não vai mais trabalhoso?
boa sorte
vc quer colocar 100 campos certo?
E se por algum motivo, aumento mais campos?
Será que não vai mais trabalhoso?
boa sorte
João, o acesso ao sistema vai ser somente na empresa, ou seja os representantes não vão ter acesso, eles vão somente emitir um pedido (escrito) onde este será enviado ao dpto. de Vendas e um usuário ira controlar tudo da máquina dele.
A empresa não tem verba nem extrutura para um Servidor e um SQL. a empresa é pequena e está começando agora, seus produtos são baratinhos, (o mais caro deve ser uns 20,00) mas o volume de movimentação é grande.
Agora estou preocupado em relação de como vai ser consultado o saldo do produto. passei o fim de semana inteiro pensando.
Gostaria de mais opiniões de vc's,
Quem tem um controle de estoque?
Quando uma empresa tem filial, como vc's controlam o saldo do produto
ex. Filial 1 tem 10pcs, Filial 2 tem 5 pcs. assim por diante.
Como vocês usam no programa de vc's? Qual a lógica?
Obriagdo
A empresa não tem verba nem extrutura para um Servidor e um SQL. a empresa é pequena e está começando agora, seus produtos são baratinhos, (o mais caro deve ser uns 20,00) mas o volume de movimentação é grande.
Agora estou preocupado em relação de como vai ser consultado o saldo do produto. passei o fim de semana inteiro pensando.
Gostaria de mais opiniões de vc's,
Quem tem um controle de estoque?
Quando uma empresa tem filial, como vc's controlam o saldo do produto
ex. Filial 1 tem 10pcs, Filial 2 tem 5 pcs. assim por diante.
Como vocês usam no programa de vc's? Qual a lógica?
Obriagdo
Vou dar-lhe uma opinião mais técnica agora:
- Não é de forma nenhuma aconselhável (embora muita gente o faça) gravar campos calculados em bases de dados, o correcto é gravar os campos que lhe dão origem.
Tomemos como exemplo o caso do "Saldo" que, no caso da Gestão de Stocks, resulta da diferença entre entradas e saidas, portanto se gravar as entradas e saidas na sua base de dados, logo você chega ao total de entradas e saÃdas e, pela diferença destas ao saldo.
Como motivo adicional para que este tipo de campos não seja gravados nas bases de dados é que, pela sua volatilidade exigem um grande tratamento ao nÃvel da programação.
Ainda tomando como exemplo o saldo sabemos que qualquer movimento de entrada ou saÃda, qualquer alteração de entradas ou saÃdas, ou ainda qualquer anulação de entradas ou saidas, tem implicação no saldo, podemos imaginar quantas linhas de programação ao longo de todo o programa não poderiam ser evitadas ainda por cima para tratarmos de um campo do qual não precisamos para nada.
- Não é de forma nenhuma aconselhável (embora muita gente o faça) gravar campos calculados em bases de dados, o correcto é gravar os campos que lhe dão origem.
Tomemos como exemplo o caso do "Saldo" que, no caso da Gestão de Stocks, resulta da diferença entre entradas e saidas, portanto se gravar as entradas e saidas na sua base de dados, logo você chega ao total de entradas e saÃdas e, pela diferença destas ao saldo.
Como motivo adicional para que este tipo de campos não seja gravados nas bases de dados é que, pela sua volatilidade exigem um grande tratamento ao nÃvel da programação.
Ainda tomando como exemplo o saldo sabemos que qualquer movimento de entrada ou saÃda, qualquer alteração de entradas ou saÃdas, ou ainda qualquer anulação de entradas ou saidas, tem implicação no saldo, podemos imaginar quantas linhas de programação ao longo de todo o programa não poderiam ser evitadas ainda por cima para tratarmos de um campo do qual não precisamos para nada.
Tópico encerrado , respostas não são mais permitidas