Jump to content
Zeux

Acesso a informação

Recommended Posts

Zeux

Boas pessoal

Estava aqui a projectar um novo projecto quando me deparei com um dilema (só o coloquei porque vi a bd de outro projecto)

Por exemplo, tenho uma tabela 'clientes' e uma tabela 'acessos' para registar os logins realizados, tabela esta que contem os campos 'cliente_id' e 'data_hora'.

Ora a minha duvida está, se a informação numero de acessos por cliente for importante e for preciso aceder constantemente a ela, é preferível criar um campo 'nr_acessos' na tabela 'clientes' e sempre que o cliente faz login incrementar o valor contido no campo, ou seja, ao fazer login tem de ser introduzido mais um valor, mas depois é mais fácil aceder a essa informação. A outra alternativa é não criar esse campo, deixando de haver informação redundante e quando se pretende ver o nº de acessos de um determinado cliente fazer uma busca na tabela 'acessos' por esse cliente e executar um count.

Qual das 2 implementações será a melhor ?  :(

Share this post


Link to post
Share on other sites
fnds

Eu fazia a primeira, por vários motivos, mas para mim o mais importante é que a tabela de acessos tem tendência para aumentar, e um dia vais ter de a reiniciar.

Share this post


Link to post
Share on other sites
pedrotuga

Lá está um caso que os académicos pura e simplesmente ignoram. Isto é um tabu, se tiveres alguma cadeira chamada bases de dados não perguntes isto ao professor, ele provavelmente estará demasiado agarrado à teoria.

Tu próprio já respondeste à tua pergunta.

Se acederes a esse tipo de informação regularmente e se o seu calculo for dispendioso, então que se lixe a redundancia.

Se for uma dado so para aceder muito raramente então calcula-se esse dado.

Outra coisa a não esquecer... o trabalho e tempo que cada solução demora a implementar. Se uma te poupar muitas horas de trabalho, só isso às vezes é mais importante que pequenas diferenças de performance.

Share this post


Link to post
Share on other sites
Knitter

Lá está um caso que os académicos pura e simplesmente ignoram. Isto é um tabu, se tiveres alguma cadeira chamada bases de dados não perguntes isto ao professor, ele provavelmente estará demasiado agarrado à teoria.

Não sei que professores tiveste mas os meus primeiro iriam perguntar qual o objectivo e depois mandar-me-iam ler regras de desnormalização que iriam bater, provavelmente, na solução te ter tudo numa só tabela. Aliás, se eu na cadeira de base de dados implementasse a solução de ter as duas tabelas, provavelmente iria ser descontado, e bem.

Outra coisa a não esquecer... o trabalho e tempo que cada solução demora a implementar. Se uma te poupar muitas horas de trabalho, só isso às vezes é mais importante que pequenas diferenças de performance.

A performance depende de muita coisa e, a não ser que se tenha muita experiência em bases de dados e no motor usado, é que se pode, antes de ter a base de dados implementada, saber o que ajuda ou não ajuda.

Neste caso o que é importante é saber o que realmente precisas guardar. A solução de duas tabelas permite guardar mais dados e obter mais informações que a solução de uma tabela. Se essas informações forem importantes, por exemplo, saber quais os dias com mais acessos, saber a que horas um utilizador tem por hábito aceder ao sistema, então uma só tabela não chega e precisas de, pelo menos, duas tabelas. Se a única coisa que te interessa saber é o número de acessos, e eventualmente, a data do último acesso, uma só tabela serve.

Share this post


Link to post
Share on other sites
Rui Carlos

Lá está um caso que os académicos pura e simplesmente ignoram. Isto é um tabu, se tiveres alguma cadeira chamada bases de dados não perguntes isto ao professor, ele provavelmente estará demasiado agarrado à teoria.

Posso-te garantir que o meu professor não só não ignorava isso, como, se num trabalho tivesse de fazer essa escolha, iria-me certamente pedir para justificar a opção que tomei.


Ainda não percebi muito bem quais as alternativas em discussão...

Nas duas alternativas tens as duas tabelas, sendo a única diferença o facto de adicionares um campo, que não é mais do que um count, na primeira alternativa?

Se é isso, e se precisares regularmente de consultar esse valor, provavelmente a melhor solução será a que tinha o valor já calculado. Sobretudo quando começares a ter a tabela de acessos com uma dimensão considerável. Aliás, este parece-me o pormenor mais importante na escolha, o facto da tabela de acessos estar sempre a crescer, o que em principio tornará o count uma operação cada vez mais dispendiosa.

Share this post


Link to post
Share on other sites
fnds

Se é isso, e se precisares regularmente de consultar esse valor, provavelmente a melhor solução será a que tinha o valor já calculado. Sobretudo quando começares a ter a tabela de acessos com uma dimensão considerável. Aliás, este parece-me o pormenor mais importante na escolha, o facto da tabela de acessos estar sempre a crescer, o que em principio tornará o count uma operação cada vez mais dispendiosa.

Exactamente.

Share this post


Link to post
Share on other sites
Zeux

Se é isso, e se precisares regularmente de consultar esse valor, provavelmente a melhor solução será a que tinha o valor já calculado. Sobretudo quando começares a ter a tabela de acessos com uma dimensão considerável. Aliás, este parece-me o pormenor mais importante na escolha, o facto da tabela de acessos estar sempre a crescer, o que em principio tornará o count uma operação cada vez mais dispendiosa.

Sim, era a isto que me referia.

Este caso foi só um exemplo, mas o caso para o que quero mesmo a situação é a mesma, a tabela vai crescer muito rapidamente, dai é preferível então ter um campo a mais na tabela e ir actualizando.

Ou apenas tive base de dados no 12º e apenas me lembro que não convem haver redundância, mas nunca falámos a nivel de performance. Este ano já vou ter uma cadeira de base de dados na universidade :(

Share this post


Link to post
Share on other sites
Knitter

Quando se fala em redundância estamos a falar de uma fase inicial, referente à normalização e é referente a dados duplicados. Há muito para fazer depois de ser obter um modelo normalizado dos dados :(

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...

Important Information

By using this site you accept our Terms of Use and Privacy Policy. We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.