[Cascavel-pm] [OT] Postgres SQL, racionalmente... [Was: Duvida com bando de...]

[Luis Motta Campos]

On Wednesday 08 August 2007 19:49, Nilson Santos Figueiredo Junior wrote:
> On 8/8/07, Luis Motta Campos <luismottacampos em yahoo.co.uk> wrote:
> >    Você está gentilmente sugerindo que eu não sei por que eu digo às
> > pessoas que utilizem RDBMSs sérios?
>
> MySQL é um RDBMS sério. Contudo, os objetivos primários são diferentes.
> Eu apenas enviei aquele link porque você simplesmente mandou aquela
> frase sem dar nenhuma argumentação e eu gostaria de ouvir bons
> motivos.
>
> >    1. Tudo o que eu preciso no MySQL será implementado na próxima
> > versão. Eu tive contato com a base de dados nas versões 3.X, 4.X, e
> > agora na 5.X, sempre com necessidades diferentes e promessas de que
> > os "essenciais" de uma base de dados séria vão ser implementados na
> > próxima versão. Já tive problemas mais sérios, com a falta de STORED
> > PROCEDUREs, TRIGGERs, FOREIGN KEYs, e transações.
>
> Todos esses recursos existem no MySQL 5.

  Sim, claro... sempre na próxima versão... agora, eu preciso de Database 
Links com criptografia, e schemas, ao invés de "databases". E seria ótimo ter 
uma arquitetura baseada em arquivos de dados, não em diretórios (meu sysadmin 
agradece - o consumo de inodes é menor).

> >    2. Tenho problemas muito sérios com o esquema de replicação do
> > MySQL: ele não escalou bem em nenhuma das implementações que eu tive
> > contato - eu tenho problemas de sicronia entre os servidores, mesmo
> > com uma rede Gigabit Ethernet dedicada (o que indica claramente que a
> > competição para sicronização dos dados se dá no nível das tabelas,
> > IMHO).
>
> Existem formas de scaling linear (junto com HA) para MySQL . Contrate
> o MySQL Enterprise e eles te contam como faz isso tudo. Bem vindo à
> máfia do MySQL. ;-)

  Bom, é EXATAMENTE disto que eu estou fugindo. Se eu não posso fazer eu 
mesmo, esquece.

> >    3. BACKUPs e RESTOREs consistentes e eficientes s ão complicados
> > de construir e restaurar. Eu acho que ser capaz de copiar a minha
> > base de dados num estado consistente é importante.
>
> Eu não sei falar nada sobre isso.

  Bom, meu caro... todas as vezes que eu precisei fazer backups, a parte mais 
complicada era garantir que o que eu tinha depois de um restore era 
uma "imagem" consistente do sistema. E isso não tem nada a ver com 
qualificações, lamentavelmente. ;-)

> >    4. A parte de administração e tunning do MySQL é pobre em
> > recursos. As diretrizes mais importantes não podem ser alteradas sem
> > pararlização do serviço, e é complicado saber o que está acontecendo
> > com o Query Cache.
>
> Contrate o MySQL Enterprise e eles te explicam como tudo funciona e
> otimizam pra você. Mais boas vindas à magia do MySQL.

  É EXATAMENTE isso que eu não quero fazer - se eu tenho de depender de uma 
empresa externa para fazer este tipo de coisa, não estou interessado em 
manter responsabilidade nenhuma sobre a base de dados, e vou contratar Oracle 
ou IBM DB2 sobre qualquer coisa que eles queiram rodar - mas a 
responsabilidade é deles.

> >    Claro, me rotular "fanático" e fugir ao diálogo racional é sempre
> > uma opção. Mas eu tenho certeza de que falar é mais interessante. ;-)
>
> As duas opções são interessantes! ;-)

  HUA HUA HUA !!
  De qualquer forma, o teu senso de humor é irrepreensível... ;-)
  Espero que as minhas razões agora estejam claras - óbvio, isso não vale para 
todo mundo... cada caso é um caso, cada cabeça um conjunto diferente de 
experiências.

  Putamplexos!
-- 
Luis Motta Campos (a.k.a. Monsieur Champs) is a software engineer,
Perl fanatic evangelist, and amateur {cook, photographer}