Qual banco de dados?
A resposta certa e direta para essa pergunta é: qualquer um!
Mas tenho que escolher um para começar... então vejamos...
O objetivo é que eu possa trocar de banco de dados quando bem entender. Suponhamos que a Oracle compre todos os outros bancos de dados do mundo (incluse o SQL Server, rs). Vamos ter que usar Oracle de qualquer jeito. Mas por enquanto, temos escolhas.
Para poder trocar de banco, não podemos ir a fundo usando recursos específicos de cada fornecedor. Assim, triggers e stored procedures já estão descartadas desde agora. Faremos o controle das regras de negócio da camada do servidor de aplicações.
Mas precisamos de um conjunto mínino de funcionalidades, preferencialmente que existam em todos ou a maioria dos bancos de dados disponíveis. Precisamos de chave única, índices e chaves estrangeiras. A maioria tem. Também não vamos usar views. Muito radical? Quando fazemos uma view existe uma tentação grande de usar alguma função ou recurso específico do fornecedor, e depois vai complicar pra mudar de banco. Se usarmos somente arroz com feijão na view (para ser portável), então não precisamos de view.
Digo isso pois não quero usar SQL dentro da programação. Depois vou até fundar um movimento contra o SQL, se é que alguém já não fez isso. Vamos usar um esquema de ORM (Mapeamento Objeto-Relacional) e essa camada vai gerar os comandos SQL para nós. Assim, não nos importaremos com SQL e recursos sofisticados de banco de dados. Nem precisamos ficar presos a um fornecedor.
Mas... e a performance? Triggers e Stored procedures não otimizam a velocidade dos processos? E aqueles comandos SQL tunados e customizados ao último cabelésimo da velocidade? O mundo não é perfeito. Vamos ter que abrir mão do controle explícito sobre a performance, e nos contentar com uma "boa performance média" das nossas operações com banco de dados. Isso não é ruim. O que você prefere: aguardar 1 ou 2 milisegundos a mais por uma pesquisa no banco ou passar horas e horas otimizando cada consulta, escrevendo procedures - e escrevendo tudo de novo quando precisar mudar de fornecedor? As escolhas não são para os fracos. Eu já fiz a minha.
Por isso, não vamos começar com um banco high end. Não precisamos. Vamos começar com o MySQL mesmo. Por que? Todo provedor de hospedagem tem, suporte abundante na internet e possuí o conjunto de requisitos mínimos que precisamos para nossa camada de acesso. Tem até um Workbench que permite desenhar o modelo relacional e rodar consultas e rotinas no banco, de graça.
Depois, se precisarmos trocar por capricho de cliente ou por obrigação, estamos livres.
Mas tenho que escolher um para começar... então vejamos...
O objetivo é que eu possa trocar de banco de dados quando bem entender. Suponhamos que a Oracle compre todos os outros bancos de dados do mundo (incluse o SQL Server, rs). Vamos ter que usar Oracle de qualquer jeito. Mas por enquanto, temos escolhas.
Para poder trocar de banco, não podemos ir a fundo usando recursos específicos de cada fornecedor. Assim, triggers e stored procedures já estão descartadas desde agora. Faremos o controle das regras de negócio da camada do servidor de aplicações.
Mas precisamos de um conjunto mínino de funcionalidades, preferencialmente que existam em todos ou a maioria dos bancos de dados disponíveis. Precisamos de chave única, índices e chaves estrangeiras. A maioria tem. Também não vamos usar views. Muito radical? Quando fazemos uma view existe uma tentação grande de usar alguma função ou recurso específico do fornecedor, e depois vai complicar pra mudar de banco. Se usarmos somente arroz com feijão na view (para ser portável), então não precisamos de view.
Digo isso pois não quero usar SQL dentro da programação. Depois vou até fundar um movimento contra o SQL, se é que alguém já não fez isso. Vamos usar um esquema de ORM (Mapeamento Objeto-Relacional) e essa camada vai gerar os comandos SQL para nós. Assim, não nos importaremos com SQL e recursos sofisticados de banco de dados. Nem precisamos ficar presos a um fornecedor.
Mas... e a performance? Triggers e Stored procedures não otimizam a velocidade dos processos? E aqueles comandos SQL tunados e customizados ao último cabelésimo da velocidade? O mundo não é perfeito. Vamos ter que abrir mão do controle explícito sobre a performance, e nos contentar com uma "boa performance média" das nossas operações com banco de dados. Isso não é ruim. O que você prefere: aguardar 1 ou 2 milisegundos a mais por uma pesquisa no banco ou passar horas e horas otimizando cada consulta, escrevendo procedures - e escrevendo tudo de novo quando precisar mudar de fornecedor? As escolhas não são para os fracos. Eu já fiz a minha.
Por isso, não vamos começar com um banco high end. Não precisamos. Vamos começar com o MySQL mesmo. Por que? Todo provedor de hospedagem tem, suporte abundante na internet e possuí o conjunto de requisitos mínimos que precisamos para nossa camada de acesso. Tem até um Workbench que permite desenhar o modelo relacional e rodar consultas e rotinas no banco, de graça.
Depois, se precisarmos trocar por capricho de cliente ou por obrigação, estamos livres.
DecisãoEntão já está resolvido: MySQL (pelo menos por enquanto).
Comentários
Postar um comentário