Em 17/03/08, ivan viana<[EMAIL PROTECTED]> escreveu: > Estou migrando um cadastro com diversas escolas que acessam um mesmo banco > de dados para postgresql, ele usa um sistema de "placas de carro" > interessante e curto > VEJAM ABAIXO (*=CHAVE) > forma alfanumerica > CADASTRO*|ALUNO > AB075801 |MARIA DO SOCORRO AMEM > AB075800 |ROBERVAL SILVA MASCARENHAS > | > | > v > TRADUZINDO > ESCOLA|ANO|MATRICULA > EK |08 |5801 > NA FORMA CONVENCIONAL FICARIA ASSIM > ESCOLA|ANO|CADASTRO* |NOME > 001 |07 | 801 |MARIA DO SOCORRO AMEM > 001 |07 | 800 |ROBERVAL SILVA MASCARENHA
A resposta aqui é clara. Você precisa desmembrar a sua chave em 3 campos distintos. No PostgreSQL 8.3, você pode utilizar um campo do tipo ENUM para o código da escola, ficará mais rápido, pois o PostgreSQL saberá quais são os valores possíveis. Se forem muitas escolas isto começa a atrapalhar. Se não estiver utilizando o PostgreSQL 8.3, considere a hipótese de migrar logo (eu migraria, pois esta versão está muuuito mais rápida para quem tem muitos acessos concorrentes). Se não der, bom, aí a melhor coisa é ter uma tabela que traduza os códigos das escolas em números mesmo. Colocar campos alfanuméricos na PK nunca é bom, pois os índices em campos numéricos são mais rápidos. Colocar 'ano' e 'matricula' em campos separados é obrigatório, não é opcional. Você sempre vai ter uma penalidade de performance grande na consulta (pois tem que utilizar uma cláusula WHERE complexa) e na atualização (pois tem que utilizar vários índices complexos, uma vez que o índice da PK será inútil para você). Ouça a voz da razão, quebre esta PK. Atenciosamente, Fábio Telles. > > Pra eu saber qual escola, ano e matricula do primeiro eu preciso apenas de 7 > dígitos e já utilizo-a como chave poupando espaço > pra saber na forma convencional eu preciso de 8 dígitos e tenho uma chave > de 3 digito, muito pouco preciso de no mínimo 6 (999.999). Você está pensando de forma equivocada. Os índices também ocupam espaço... você mediu isso? Os índices em campos alfanuméricos ocupam mais espaço que os índices em campos numéricos. De toda forma, trocar espaço em disco por performance só é algo pensável em casos muuuuito extremos, você não acha? Ou você ainda usa servidores mainframe da década de 70 com discos caríssimos? > PROBLEMAS DO SISTEMA ATUAL: > 1)toda vez que linko uma tabela tenho que usa um separador de string no sql > (ex pra linkar com a tabela escola uso > tab_escola.cod*=substring(tb_aluno.cadastro from 1 for 2)) Isto é algo abominável. Você teria que criar um índice específico para esta função. Não é algo bonito de se fazer. Não mesmo. > 2)varios links apontam para o mesmo campo da tabela > VANTAGEM: > 1)tamanho no armazenamento armazeno tudo em apenas um campo. Esquece isso e seja feliz. > 2)padrão de fácil memorização humana Hum... isto é bem relativo... as pessoas se acostumam rápido com números que são sempre fixos. Você lembra o andar do escritório em que trabalha, é sempre o mesmo... De toda forma, se você utilizar um campo ENUM, não terá este problema. Se não utilizar, que tal fazer a sua consulta de forma a mostrar para o seu usuário o código alfanumérico armazenado numa tabela auxiliar? Com SQL este tipo de coisa é simples... mas rezolver o problema de uma PK mal modelada é bem diícil. > > O PROBLEMA: > No sistema atual as consultas ficam muito lenta??? Espero ter demonstrado porque está lento... > Ou posso dá continuidade ao sistema alfanumérico?? > > > EU PRECISO APENAS DE Ç QUAL CODIFICAÇÃO USO? o unicode é FUTURO mas é Esse negócio de precisar apenas do 'Ç" é no mínimo bizarro. Use latin1 ou UTF8. Espero ter ajudado. Atenciosamente, Fábio Telles -- blog: http://www.midstorm.org/~telles/ e-mail / jabber: [EMAIL PROTECTED] _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
