Nesse post eu quero dividir com vocês a minha (pouca) experiência que eu tenho em relação a nomenclatura de banco de dados.

Não pretendo comparar padrões, e sim mostrar o que EU acho ser interessante. Talvez você já use esse padrão, se não, ou se usa algum outro, vale a pena dar uma conferida mesmo assim, numa dessas você se adapta e programa mais feliz

Tabelas: Todas as tabelas começam com a letra T (maiúsculo). Essa foi fácil, é “T” de tabela mesmo.
Após a letra T temos uma sequência numérica 000. Eu prefiro usar três dígitos, em projetos com mais de 999 tabelas, obviamente serão necessários 4 dígitos (ou mais!).
Mas pra que servem os dígitos? Os dígitos servem para identificarmos “o tipo” da tabela. Por exemplo, podemos definir que da tabela T001 à T099, sejam tabelas de cadastro, e que da tabela T100 a T150, sejam de relacionamentos e assim por diante, dependendo das necessidades do projeto.
Após a numeração, teremos um “_” seguido do nome da tabela que começará com a primeira letra maiúscula, por exemplo “T001_Cliente”. Nomes compostos não serão separados por “_”, e todas as primeiras letras serão maiúsculas, por exemplo “T005_UnidadeRemota”.

Analizemos: Em uma outra situação, como identificar se “dependentes” é uma tabela ou um atributo? Teríamos que recorrer a modelagem, ou então abrir nosso gerenciador e conferir, enquanto “T009_Dependentes” por exemplo, fica claro que se trata de uma tabela (pela inicial “T”), que se trata de uma tabela de cadastro (pela convenção supostamente adotada que tabelas de cadastro vão de 001 a 099), e que contém por sua vez o cadastro de dependentes de acordo com o sufixo. Indolor não?

Atributos: Todos os atributos começam com a letra A (maiúscula). “A” de atributo.
Também teremos a sequência numérica 000, mas ela será de acordo com a tabela de origem. Por exemplo: em uma tabela “T001_Clientes”, os atributos seriam: “A001_nome”, “A001_idade”, etc…
Como foi visto no exemplo anterior, os atributos também contém nomes para os identificar, e todos esses nomes serão em minúsculo. Vale a pena usar de bom senso na hora de criarmos os nomes dos atributos, pois o ideal é que sejam nomes curtos (eu gosto de usar nomes com 4 a 8 caracteres), desde que o programador que vá usar entenda o que significa

Olha aí a grande sacada!

E quando usamos chave estrangeira, como fica?

Essa é a parte mais legal, olha só.

Vamos imaginar uma tabela de endereço – T010_Enderecos. E que nessa tabela contém uma chave primária (!) – A010_codend. Agora vamos voltar a nossa T001_Clientes. Ela contém os atributos:
A001_codcli
A001_nome
A001_idade
A010_codend
Êpa! O que que esse A010_codend está fazendo na minha tabela de clientes???
Essa é a minha chave estrangeira da tabela T010_Enderecos, e é facilmente identificada através do prefixo A010!

Com essa pequena sugestão, a vida do programador se tornará muito mais fácil!
Não vou entrar no mérito de índices, triggers, procedures (a não ser que peçam né), mas é só adotarem a mesma “idéia”, que tudo ficará mais simples.

Os programadores que entrarem “no meio” do projeto, iram te agradecer.

Então é isso, meu nome é Julio Cesar, mas vocês podem me chamar de Jota, como o Pedro disse em minha apresentação. Não pretendo postar com tanta frequência, e também não quero causar tanto “rebuliço” aqui no blog.
Comentem sobre padrões vocês também!

Abraço a todos!

Post original do blog E-tinet pode ser acessar pelo link direto Não Chame de Qualquer Coisa. O Blog E-tinet - Simplesmente Tecnologia tem autoria de Pedro Delfino dos Santos Neto. Para entrar em contato com o autor acesse /contato. E visite o meu twitter em @pedrodelfino para saber o que eu estou fazendo.

Curso Linux Ubuntu

Vamos analisar alguns fatos. Primeiro sobre o MySQL. Porque usar MySQL? Velocidade. E hoje sabemos que web precisa ser veloz, fecha um casamento perfeito. Mas será que vale a pena usar um sistema que é falho? Se até poucas versões anteriores era possível repetir valores em atributos PK, vai saber o que mais pode acontecer de errado?
Agora que o MySQL é da Oracle, vamos acompanhar como será o desenvolvimento do Banco. E já temos boas notícias, MySQL Enterprise vem com recursos alá Oracle Database, com ferramentas de monitoramento e replicação em poucos cliques. Então, porque usar MySQL? Por causa da sua velocidade, e com isso perdemos vários recursos, segurança, entre outros.

Falando sobre Oracle, não podemos deixar de mencionar o Oracle Database. O que seria do mundo sem ele? Tem toda a consistência que o um software pago deve ter. Com alguns critérios que é necessário obedecer. Suporte é pago, documentação escassa, configuração complexa. Mas, lembrando, é Oracle. A Oracle divide seu produto em pacotes, cada pacote custa em torno de 40% a 60% a mais que o anterior. O custo das licenças é altíssimo, sem falar no suporte (caso a empresa não tenha condições de contratar um DBA Oracle).

Quero comparilhar uma história com vocês. Foi necessário efetuar a compra de um software, o qual usava Oracle como banco de dados. A mesma empresa que vende o software vende as licenças do Oracle e também o suporte. Fica tudo a cargo deles, instalação, configuração e manutenção. No linux, em dado momento, alguns valores do sistema operacional são modificados, questionou o técnico em base de que situações ele tirou aqueles valores. A resposta foi: “Não sei. Na realidade a própria Oracle, no site, recomenda que seja feito assim”. E sim, senhores, os mesmos valores que ele configurou na instalação estão no site da Oracle. Mas a questão final é como que ele não sabe porque fazer aquelas alterações? Da onde surgiram aqueles valores? Cada sistema/configuração/servidor é um caso diferente, não seria interessante validar esses valores encima dessa situação?

Tentei procurar o porque daqueles valores, mas não existe documentação. Assim como não existe benchmarking de Oracle. Você já viu alguma comparação de Oracle com outros bancos de dados? Eu procurei, não achei. Mas descobri que as pessoas que fazem benchmarking do banco e publicam são processadas pela Oracle (que tipo de empresa faz isso?). Dizem que está em contrato, não procurei. Claro que assim fica fácil vender um sistema, não tem como comparar com outros.

Será que vale a pena pagar por um software sendo que você pode ter outro fazendo o mesmo (ou até mais), de graça?

Muitos irão dizer que sim. Afinal, 47% do mercado usa Oracle Database.
Eu digo que não. O Postgres, que surgiu como projeto de Faculdade, agora preparando para lançamento da versão 9, é um software que está em grande crescimento, sendo usado por grandes empresas (Podemos citar a Apple, Skype, Caixa, Detran entre outros vários orgãos do governo) e também como ferramenta de ensino de Banco de Dados e modelagem.

Quanto ao Postgres só tenho uma reclamação: Multi-master. Sabemos que não é fácil, ainda mais quando elucidado a questão por inteiro no post “A lenda da replicação Multimaster“.

Talvez você ache que o Postgres não seja tudo isso. Uma coisa eu tenho certeza: o Postgres pode suprir todas as suas necessidades.

Post original do blog E-tinet pode ser acessar pelo link direto O Melhor Banco de Dados: Postgres?. O Blog E-tinet - Simplesmente Tecnologia tem autoria de Pedro Delfino dos Santos Neto. Para entrar em contato com o autor acesse /contato. E visite o meu twitter em @pedrodelfino para saber o que eu estou fazendo.

Curso Linux Ubuntu