Em Sáb, 2015-04-18 às 23:43 -0300, Danilo Silva escreveu: > Entendo... Criar as tabelas e suas restrições e > relacionamentos é até > tranquilo, mas acho que na hora de se criar outros "elementos" > ficaria > meio complicado. Tipo, geralmente na hora de criar uma função, > uma view, > ou qualquer coisa que você criar após as tabelas estarem > prontas, fica > complicado se você precisar de algumas informações da qual > você não > lembra de pronto, tipo, qual o tipo de dado você definiu para > um campo X > na tabela Y. > Procurar essa informação em um arquivo de..... sei la..... 700 > linhas de > código é osso. No diagrama você teria uma representação > gráfica de tudo, > ficando muito mais fácil encontrar. Por mais que o editor > tenha recursos > para localizar palavras através de regex, acho que ainda não > seria tão > prático quanto. > > Ao invés de procurar em um arquivo, não seria mais fácil ir direto na > tabela em questão e saber qual o tipo do campo? > > > Ai é que entra a pergunta que fiz sobre qual o roteiro que geralmente se utiliza para modelar na unha. Baseado na sua resposta creio que você então codifica por partes, tipo, em um primeiro script você codifica as tabelas e seus relacionamentos, depois você roda esse script e gera as tabelas no banco, depois, num segundo script você codifica as outras partes, função, view, etc. Seria isso? Penso que talvez essa seja a maneira mais prática do que tentar escrever tudo em um único script, e rodar tudo de uma vez. Pois dessa forma você teria que ficar procurando por informações dentre do próprio script.
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
