Comments on: Banco de dados mais eficiente com Store Procedures http://christiano.me/2007/11/07/banco-de-dados-mais-eficiente-com-store-procedures/ Desenvolvimento, Padrões Web, NoSQL, MongoDB, Software Livre Wed, 08 Feb 2012 19:42:10 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Fábio Telles http://christiano.me/2007/11/07/banco-de-dados-mais-eficiente-com-store-procedures/#comment-436 Fábio Telles Wed, 14 Nov 2007 11:43:17 +0000 http://christiano.blog.br/2007/11/07/banco-de-dados-mais-eficiente-com-store-procedures/#comment-436 O TaQ tem razão... mas isto está mudando. O PostgreSQL tem o PL/pgSQL que é muito parecido com o PL/SQL do Oracle. O PSM do MySQL é parecido com o do DB2 e já tem uma implementação no PostgreSQL também. Aliás... para coisas simples e dedicadas, o PostgreSQL é uma mãe neste sentido. Use a sua linguagem predileta direto nele: C, Perl, Python, PHP, TCL, Java, etc... O cuidado que se deve tomar é até onde concentrar a inteligência da aplicação no banco. Você pode sentar o servidor se não dimensionar isso direito. E um defeito dos SGDBs é que é muito mais fácil distribuir carga num servidor de aplicação que no banco de dados. Ok, eu sei que no seu caso o MySQL foi uma opção melhor e entendo o seu caso. Realmente é um caso muito específico mesmo. Sempre acho que a escolha do seu SGDB tem que passar pelas fazes que você passou. Existem muitas opções, do TXT puro ou XML ao SQLite, BDB e até o Oracle e DB2. Cada projeto é um projeto. []s O TaQ tem razão… mas isto está mudando. O PostgreSQL tem o PL/pgSQL que é muito parecido com o PL/SQL do Oracle. O PSM do MySQL é parecido com o do DB2 e já tem uma implementação no PostgreSQL também. Aliás… para coisas simples e dedicadas, o PostgreSQL é uma mãe neste sentido. Use a sua linguagem predileta direto nele: C, Perl, Python, PHP, TCL, Java, etc… O cuidado que se deve tomar é até onde concentrar a inteligência da aplicação no banco. Você pode sentar o servidor se não dimensionar isso direito. E um defeito dos SGDBs é que é muito mais fácil distribuir carga num servidor de aplicação que no banco de dados.

Ok, eu sei que no seu caso o MySQL foi uma opção melhor e entendo o seu caso. Realmente é um caso muito específico mesmo. Sempre acho que a escolha do seu SGDB tem que passar pelas fazes que você passou. Existem muitas opções, do TXT puro ou XML ao SQLite, BDB e até o Oracle e DB2. Cada projeto é um projeto.

[]s

]]> By: Fábio Telles http://christiano.me/2007/11/07/banco-de-dados-mais-eficiente-com-store-procedures/#comment-438 Fábio Telles Wed, 14 Nov 2007 11:43:00 +0000 http://christiano.blog.br/2007/11/07/banco-de-dados-mais-eficiente-com-store-procedures/#comment-438 O TaQ tem razão... mas isto está mudando. O PostgreSQL tem o PL/pgSQL que é muito parecido com o PL/SQL do Oracle. O PSM do MySQL é parecido com o do DB2 e já tem uma implementação no PostgreSQL também. Aliás... para coisas simples e dedicadas, o PostgreSQL é uma mãe neste sentido. Use a sua linguagem predileta direto nele: C, Perl, Python, PHP, TCL, Java, etc... O cuidado que se deve tomar é até onde concentrar a inteligência da aplicação no banco. Você pode sentar o servidor se não dimensionar isso direito. E um defeito dos SGDBs é que é muito mais fácil distribuir carga num servidor de aplicação que no banco de dados. Ok, eu sei que no seu caso o MySQL foi uma opção melhor e entendo o seu caso. Realmente é um caso muito específico mesmo. Sempre acho que a escolha do seu SGDB tem que passar pelas fazes que você passou. Existem muitas opções, do TXT puro ou XML ao SQLite, BDB e até o Oracle e DB2. Cada projeto é um projeto. []s O TaQ tem razão… mas isto está mudando. O PostgreSQL tem o PL/pgSQL que é muito parecido com o PL/SQL do Oracle. O PSM do MySQL é parecido com o do DB2 e já tem uma implementação no PostgreSQL também. Aliás… para coisas simples e dedicadas, o PostgreSQL é uma mãe neste sentido. Use a sua linguagem predileta direto nele: C, Perl, Python, PHP, TCL, Java, etc… O cuidado que se deve tomar é até onde concentrar a inteligência da aplicação no banco. Você pode sentar o servidor se não dimensionar isso direito. E um defeito dos SGDBs é que é muito mais fácil distribuir carga num servidor de aplicação que no banco de dados.

Ok, eu sei que no seu caso o MySQL foi uma opção melhor e entendo o seu caso. Realmente é um caso muito específico mesmo. Sempre acho que a escolha do seu SGDB tem que passar pelas fazes que você passou. Existem muitas opções, do TXT puro ou XML ao SQLite, BDB e até o Oracle e DB2. Cada projeto é um projeto.

[]s

]]> By: TaQ http://christiano.me/2007/11/07/banco-de-dados-mais-eficiente-com-store-procedures/#comment-435 TaQ Thu, 08 Nov 2007 11:08:49 +0000 http://christiano.blog.br/2007/11/07/banco-de-dados-mais-eficiente-com-store-procedures/#comment-435 O problema é que em muitos casos a portabilidade do seu programa vai para o saco. É só ver sistemas inteiros hoje escritos exclusivamente para o Oracle ou para o SQL Server. :-( O problema é que em muitos casos a portabilidade do seu programa vai para o saco. É só ver sistemas inteiros hoje escritos exclusivamente para o Oracle ou para o SQL Server. :-(

]]> By: TaQ http://christiano.me/2007/11/07/banco-de-dados-mais-eficiente-com-store-procedures/#comment-437 TaQ Thu, 08 Nov 2007 11:08:00 +0000 http://christiano.blog.br/2007/11/07/banco-de-dados-mais-eficiente-com-store-procedures/#comment-437 O problema é que em muitos casos a portabilidade do seu programa vai para o saco. É só ver sistemas inteiros hoje escritos exclusivamente para o Oracle ou para o SQL Server. :-( O problema é que em muitos casos a portabilidade do seu programa vai para o saco. É só ver sistemas inteiros hoje escritos exclusivamente para o Oracle ou para o SQL Server. :-(

]]>