Duvida sobre modelagem de dados?

Question

Ola pessoal.

Estou com uma duvida sobre modelagem de dados, no meu caso, eu estou querendo armazenar valores que recebo de um equipamento e existe 1(um) byte no qual cada bit representa uma configuraçao do equipamento, seria melhor eu criar apenas um campo binary(8) para armazenar os valores (Ex: 01001101) e assim tratar os valores na aplicaçao? Ou crio 8 campos bit?

Answer 1

Boa Tarde Marcelo,

 

Eu recomendaria que você gravasse oito campos do tipo bit.

 

Gravar a seqüência de bits em um campo binário terá o mesmo efeito, mas poderá lhe trazer mais problemas nas consultas quando você quiser olhar o valor do bits individualmente.

 

Se você colocar um bit para cada campo e quiser perguntar o status de um bit em particular, bastará colocar na cláusula WHERE o campo para esse bit e fazer a comparação. Se guardar todos os bits em um único campo, terá que converter esse campo constantemente.

 

[ ]s,

 

Gustavo

Answer 2

Marcelo,

 

Também acredito que seja melhor dividir em diversas colunas, para que seja possível uma análise individual de forma mais simples, se necessário.
Você evitará a utilização de certas cláusulas para sub-dividir, o que aumentaria o tempo de resposta, além de facilitar a forma como desenvolverá a sua query.

 

Qualquer dúvida, estamos à disposição.

 

[ ]s.

Answer 3

Obrigado pelas respostas pessoal.

Só que no meu caso, essas informações vão ser sempre alteradas, pois são valores de configuração do equipamento que eu preciso sempre mostrar a configuração atual. Não há necessidade de ter que mostrar configurações passadas, até porque o equipamento não armazena configurações passadas e o usuário pode demorar alguns dias para receber os dados dos equipamento.

Então acredito que no meu caso, seria melhor eu armazenar em um campo, correto?

Além disso, não sei ao certo se isso interfere, mas se eu tiver 8 campos a mais, eu terei 37 campos na tabela, apesar que 90% dos campos são númericos, ficaria mais lento para trazer todas essas informações, estou certo?

Answer 4

Olá Marcelo,

 

A proposta que o Thiago e eu defendemos não tem a capacidade de gravar históricos e configurações passadas, elas sempre irá gravar a configuração atual (só que partida em vários campos). Talvez com um exemplo fique mais fácil.

 

Code Snippet

-- Cria a tabela

-- C1, C2, C3 e C4 são características próprias

CREATE TABLE tbl (C1 CHAR(1), C2 CHAR(1), C3 CHAR(1), C4 CHAR(1))

 

-- Grava alguns registros

INSERT INTO tbl (C1, C2, C3, C4) VALUES ('S','N','S','N')

INSERT INTO tbl (C1, C2, C3, C4) VALUES ('N','N','S','N')

INSERT INTO tbl (C1, C2, C3, C4) VALUES ('S','S','S','S')

INSERT INTO tbl (C1, C2, C3, C4) VALUES ('N','S','N','S')

INSERT INTO tbl (C1, C2, C3, C4) VALUES ('S','S','N','N')

 

-- Recuperar todos os registros que tenham a característica 1

SELECT C1, C2, C3, C4 FROM tbl

WHERE C1 = 'S'

 

-- Recuperar todos os registros que tenha a característica 1 mas não a 4

SELECT C1, C2, C3, C4 FROM tbl

WHERE C1 = 'S' AND C4 = 'N'

 

Agora vamos supor que estivesse tudo em um campo só:

 

Code Snippet

-- Cria a tabela

-- C1, C2, C3 e C4 são características próprias

CREATE TABLE tb (C CHAR(4))

 

-- Grava alguns registros

INSERT INTO tb (C) VALUES ('SNSN')

INSERT INTO tb (C) VALUES ('NNSN')

INSERT INTO tb (C) VALUES ('SSSS')

INSERT INTO tb (C) VALUES ('NSNS')

INSERT INTO tb (C) VALUES ('SSNN')

 

-- Recuperar todos os registros que tenham a característica 1

SELECT C FROM tb WHERE C LIKE 'S%'

-- Essa foi fácil

 

-- Recuperar todos os registros que tenha a característica 2 mas não a 4

SELECT C FROM tb

WHERE SUBSTRING(C,2,1) = 'S' AND SUBSTRING(C,4,1) = 'N'

 

Observe que nesse caso, suas consultas ficaram mais difíceis de se elaborar e que caso haja algum índice, ele será automaticamente ignorado quando você utilizar funções como substring. Vale a pena lembrar que ter todos os campos separados e juntá-los é mais fácil que ter todos juntos e separá-los.

 

Ter os campos separados talvez gaste alguns bytes a mais na página (afinal são mais colunas para gerenciar), mas não sacrifique o desempenho do seu banco e a clareza do seu código por conta de uma economia mínima. Sugiro deixar os campos separados.

 

[ ]s,

 

Gustavo

Answer 5

Gostei da sua resposta, foi bem esclarecedora.

Realmente nesse ponto voce esta certo.

Mas eu sempre vou trabalhar com consultas que me trazem todas as informaçoes da configuraçao do equipamento, nao ira existir a possibilidade de me trazer apenas duas ou tres informaçoes, pois esses valores sao apenas para responder como esta configurado o equipamento atualmente, exemplo:

Compensação da Temperatura: Automatico (0) ou Sem correçao (1)

Modo da bomba recircular: Recirculaçao (0) ou Continua (1)

Beep do teclado: On (0) ou Off (1)

e assim por diante.

 

Apesar disso, sempre devemos trabalhar com a possibilidade de futuramente o cliente querer algumas modificaçoes no aplicativo, como por exemplo filtrar as configuraçoes dos equipamentos e com isso, ficara mais simples essas consultas se todos os campos estiverem separados. Esta seria sua justificativa?

Answer 6

Olá Marcelo,

 

Vale a pena lembrar que retornar todas as informações é diferente de filtrar informações. Você pode retornar todas as colunas ou apenas parte delas, mas o que faz diferença mesmo é o que está na cláusula WHERE e não na clásula SELECT. Na cláusula SELECT não faz muita diferença se você exibe uma, duas ou todas as colunas. Em todo caso, como a cláusula WHERE está montada faz toda a diferença (essa é a principal diferença entre consultas eficientes e consultas não eficientes).

 

Você pode trazer todas as informações do equipamento sempre, mas se desejar filtrar apenas por algumas características, separar as colunas ainda é um bom negócio. Manter tudo em uma coluna única só é interessante se você sempre for pesquisar utilizando todas as colunas (o que não é realidade na maioria das situações).

 

[ ]s,

 

Gustavo