Duas siglas: KISS <http://en.wikipedia.org/wiki/KISS_principle> (sem o stupid) e YAGNI <http://en.wikipedia.org/wiki/You_ain't_gonna_need_it>.
Pouquíssimos são os casos de migração de bancos de dados em uma aplicação real. A vantagem existe, mas não é muito relevante na maioria das aplicações. E, particularmente para o Kohana, somente dois bancos são suportados oficialmente pelo ORM, o MySQL e o PostgreSQL. "*Essa é a grande argumentação da orientação a objetos.*" Creio que essa seja uma outra idéia, não lembro exatamente qual o nome, mas ela propõe usar menos e menos recursos como triggers, procedures e outras coisas específicas de banco de dados. "*Quando mais "burro" o seu banco de dados for, mais performance e escalabilidade ele terá*" Pensando no banco em si, provavelmente ele terá atualizações mais rápidas se você não tem triggers complicadas sendo disparadas. Mas, mesmo assim, recursos como views materializadas podem ser essenciais para desempenho de algumas consultas no seu banco. Mas já pensando na aplicação que lida com o banco, IMHO, meio certo e meio errado. Escalabilidade, sim. Se você evita usar recursos específicos de banco, limitando-se a comandos SQL simples (e se preocupando com a sintaxe deles), é muito provável que isso vá pesar a favor de se usar mais de um banco. Já performance, não necessariamente. Para o caso ilustrado, minha sugestão provavelmente será irrelevante ou pior. Mas, se você tá tendo problemas de desempenho de banco de dados na sua aplicação, a recomendação geral é de mover alguma inteligência da aplicação para o banco de dados (como uma consulta mais complicada ou uma série específica de consultas sendo transformadas em uma procedure) para melhorar sua performance. Segue um trecho com alguns comentários: *For all database management systems (DBMSes), "round-trip" time is > significant. This is the amount of time which it takes a query to get > through the the language parser, the driver, across the network interface, > the database parser, the planner, the executor, the parser again, back > across the network interface, through the driver data handler, and to the > client application. DBMSes vary in the amount of time and CPU they take to > process this cycle, and for a variety of reasons PostgreSQL is a the high > end of time and system resources per round-trip.* Daqui: http://it.toolbox.com/blogs/database-soup/postgresql-application-performance-tips-part-1-13172 Eu sou um cara fortemente inclinado a banco de dados, então minha opinião nesse caso pode parecer duvidosa. Mas, na minha concepção, independente de performance (que, nesse caso, pode até ser pior, já que um update disparará mais um evento no banco), eu entendo que atualizar este campo específico deve estar no banco - não me parece apropriado deixar isso na aplicação, já que seria possível a ela alterar esse valor, quando na prática seria incoerente. Conheço muito pouco, mas nunca tive a impressão de que um banco NoSQL é um banco burro pra atingir um bom desempenho - pelo contrário, implementa algumas coisas muito interessantes pra isso. Em 12 de julho de 2011 16:53, Daniel Ribeiro Gomes <[email protected]>escreveu: > A vantagem disso é trabalhar com diferentes drivers, deixando a > responsabilidade de tudo para a aplicação. Essa é a grande argumentação da > orientação a objetos. Quando mais "burro" o seu banco de dados for, mais > performance e escalabilidade ele terá. O exemplo mais clássico é o NoSQL. > > Portanto, vale mais a pena deixar isso sob a responsabilidade da aplicação! > > Abraços! > > Daniel Ribeiro Gomes Pereira > Twitter <https://twitter.com/#!/drgomesp> | > Facebook<https://www.facebook.com/profile.php?id=100000407054469> > | LinkedIn <http://www.linkedin.com/pub/daniel-ribeiro-gomes/21/414/39> > E-mail: [email protected] > iPhone: +55 (48) 9111-0931 > > > > 2011/7/12 Anderson Marques Ferraz <[email protected]> > >> A referência tem um exemplo: >> http://dev.mysql.com/doc/refman/5.0/en/create-trigger.html >> >> >> >> delimiter | >> >> CREATE TRIGGER testref BEFORE INSERT ON test1 >> FOR EACH ROW BEGIN >> INSERT INTO test2 SET a2 = NEW.a1; >> DELETE FROM test3 WHERE a3 = NEW.a1; >> UPDATE test4 SET b4 = b4 + 1 WHERE a4 = NEW.a1; >> END; >> | >> >> delimiter ; >> >> -- >> Anderson Marques Ferraz >> UEFS - Engenharia de Computação - 2006.1 >> Linux user #500881 - http://counter.li.org/ >> >> Money demands that you sell, not your weakness to men's stupidity, but >> your talent for their reason. >> (Francisco d'Anconia) >> >> -- >> Você está recebendo esta mensagem porque se inscreveu no grupo "Kohana >> Php" dos Grupos do Google. >> Para postar neste grupo, envie um e-mail para [email protected] >> . >> Para cancelar a inscrição nesse grupo, envie um e-mail para >> [email protected]. >> Para obter mais opções, visite esse grupo em >> http://groups.google.com/group/kohana-php?hl=pt-BR. >> > > -- > Você está recebendo esta mensagem porque se inscreveu no grupo "Kohana Php" > dos Grupos do Google. > Para postar neste grupo, envie um e-mail para [email protected]. > Para cancelar a inscrição nesse grupo, envie um e-mail para > [email protected]. > Para obter mais opções, visite esse grupo em > http://groups.google.com/group/kohana-php?hl=pt-BR. > -- Anderson Marques Ferraz UEFS - Engenharia de Computação - 2006.1 Linux user #500881 - http://counter.li.org/ Money demands that you sell, not your weakness to men's stupidity, but your talent for their reason. (Francisco d'Anconia) -- Você está recebendo esta mensagem porque se inscreveu no grupo "Kohana Php" dos Grupos do Google. Para postar neste grupo, envie um e-mail para [email protected]. Para cancelar a inscrição nesse grupo, envie um e-mail para [email protected]. Para obter mais opções, visite esse grupo em http://groups.google.com/group/kohana-php?hl=pt-BR.
