gildot

Topo
Sobre
FAQ
Tópicos
Autores
Preferências
Artigos
Sondagens
Propor artigo


8/3
gildicas
9/30
jobs
10/9
perguntas
10/25
press

 
Novidades do MySQL 4 e buraco da MSFT
Contribuído por vd em 20-03-03 11:33
do departamento software
Rapidinhas jfig escreve "A MySQL AB lançou o MySQL 4.0.12. Bastantes novidades, record level locking, transacções, query caching(!), etc., etc... Mas parece que só na release 5 vamos ver as famosas Views."

Por sua vez, a MSFT alertou ontem para mais uma falha de segurança grave em todas as suas versões do windows, desta vez a nível do Windows Script Engine. Mais informação aqui.

Alianca entre a HP e RedHat | Cultured Perl: More one-line Perl scripts  >

 

gildot Login
Login:

Password:

Referências
  • jfig
  • MySQL AB
  • MySQL 4.0.12
  • aqui
  • Mais acerca Rapidinhas
  • Também por vd
  • Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário.
    Mysql vs PostgresSQL (Pontos:1)
    por igod em 20-03-03 13:39 GMT (#1)
    (Utilizador Info)
    People,

    Num projecto que vou fazer, vou ter que optar por mysql ou postgres ( ou outra base de dados open source, se alguém conhecer outra que avise; o projecto vai ser open-source ). A mysql pelo que me parece é muita utilizada e por isso "garante" alguma fiabilidade...mas a falta de store procedures desanima muito o seu uso.
    Alguém alguma vez fez esta comparação ( mysql vs postgres )? Gostaria de saber qual a vossa experiência em ambas as bases de dados.
    Gostaria de ter termos de comparação como: fiabilidade, disponibilidade, e rapidez ( para uma base de dados de centenas de megas de informação e pode chegar a poucos gigas );
    Links de sites com comparações também dava jeito.

    Re:Mysql vs PostgresSQL (Pontos:2)
    por vd em 20-03-03 13:48 GMT (#2)
    (Utilizador Info) http://paradigma.co.pt
    Existe um artigo no phpbuilder sobre o assunto

    http://www.phpbuilder.com/columns/tim20000705.php3

    vd
    Redhat Database (Pontos:2)
    por vd em 20-03-03 13:52 GMT (#3)
    (Utilizador Info) http://paradigma.co.pt
    http://www.redhat.com/software/database/technical/

    É uma ideia... :)

    Ah! Existe tambem um projecto interessante de benchmarks...

      The Open Source Database Benchmark
    http://osdb.sourceforge.net/

    vd
    Re:Redhat Database (Pontos:1)
    por floWS em 20-03-03 14:17 GMT (#5)
    (Utilizador Info)
    preguiçoso...

    http://www.phpbuilder.com/column s/tim20000705.php3
    http://www.redhat.com/software/d atabase/technical/
    http://osdb.sourceforge.net/

    ;)

    Cumps,
    floWS


    Re:Mysql vs PostgresSQL (Pontos:2, Esclarecedor)
    por leitao em 20-03-03 13:57 GMT (#4)
    (Utilizador Info) http://scaletrix.com/nuno/
    O PostgreSQL passa os testes ACID, o MySQL nao... o PostgreSQL ganha por defeito.


    "Arguing on the Internet is like running in the Special Olympics -- Even if you win you're still retarded."

    Re:Mysql vs PostgresSQL (Pontos:2)
    por vd em 20-03-03 14:18 GMT (#6)
    (Utilizador Info) http://paradigma.co.pt
    Sem querer parecer que estou a tentar passar o atestado de estupidez, andas muito mal informado.

    MySQL Database Now Provides Full Transaction Support
    http://www.mysql.com/press/release_2002_11.html

    MySQL now includes the ACID-compliant InnoDB transactional storage engine, which is designed for very high performance and scalability when processing large data volumes and under high concurrency.

    Mais ajuda ?
    Está bem!

    InnoDB Tables Overview
    http://www.mysql.com/doc/en/InnoDB_overview.html

    InnoDB
    http://www.innodb.com/
    Transactions, row level locking, hot backup, and foreign keys for MySQL - without compromising the speed of MySQL

    vd
    Re:Mysql vs PostgresSQL (Pontos:2)
    por MavicX em 20-03-03 15:40 GMT (#11)
    (Utilizador Info) http://www.startux.org
    Data integrity NO
    Views Support NO
    Schemas Support NO
    Subselect Support NO
    Stored Procedures NO
    Triggers Support NO

    Podes ter transações e foreign keys com o InnoDB mas o resto não tems.

    Pedro Esteves

    Re:Mysql vs PostgresSQL (Pontos:2)
    por vd em 20-03-03 16:05 GMT (#12)
    (Utilizador Info) http://paradigma.co.pt
    http://www.mysql.com/doc/en/Differences_from_ANSI.html

    Subqueries have been implemented in MySQL version 4.1.

    Data Integrity ?
    Lock Table

    Stored procedures and triggers are currently being implemented in our version 5.0 development tree.

    It is planned to implement views in MySQL Server around version 5.0.

    Escabilidade, remember?

    vd
    Re:Mysql vs PostgresSQL (Pontos:4, Esclarecedor)
    por DomusOnline em 20-03-03 16:33 GMT (#13)
    (Utilizador Info) http://bandalarga.domus.online.pt/
    Ai... Vocês desculpem-me ;)

    Da página mencionada passo a citar:

    2. More often than not, fatal transactional updates can be rewritten to be atomic. Generally speaking, all integrity problems that transactions solve can be done with LOCK TABLES or atomic updates, ensuring that you never will get an automatic abort from the database, which is a common problem with transactional databases.

    Claro que enquanto se "locka" a tabela ninguém trabalha. Isto é giro em coisas com muito poucos utilizadores... mas e quando são muitos? Simples... Não se usa mySQL ou usam-se os outros tipos de tabelas. Mas e se a manipulação destas tabelas estiver dependente de condições sobre outras tabelas? Ele aceita joins entre tabelas de tipos diferentes? Sinceramente não sei.

    Mas o delírio é o seguinte:
    3. Even a transactional system can lose data if the server goes down. The difference between

    PLONK! Isto é preciso ter muita lata para afirmar. Numa base de dados "séria" com transacções nunca há perda de integridade salvo por BUGs

    different systems lies in just how small the time-lap is where they could lose data. No system is 100% secure, only ``secure enough.'' Even Oracle, reputed to be the safest of transactional databases, is reported to sometimes lose data in such situations.

    Repito... Por BUG ou opção do DBA (ou falha de hardware e mau planeamento e nesse caso há os backups)

    A integridade é uma das principais razões de ser das bases de dados. Não há espaço para meios termos. Era bom que assumissem que neste momento não o podem fazer. Mas palpita-me que quando puderem isso vai ser anúnciado como uma excelente feature em vez da desvalorização mentirosa que fazem agora. Estes tipos realmente fazem-me lembrar a MS nas nos RDBMS open source. Quando não fazem não presta. Quando fizerem vai ser a melhor coisa do mundo. Yuck!

    Cumprimentos.
    Re:Mysql vs PostgresSQL (Pontos:2)
    por MavicX em 20-03-03 17:54 GMT (#16)
    (Utilizador Info) http://www.startux.org
    Epa os gajos do Mysql tem sempre a mania de que são mais espertos.

    Vê o exemplo dos index's. Todas as bases de dados metem os dados das colunas e os index's no mesmo ficheiro. O mysql para ser diferente mete em ficheiros diferentes.

    Ou seja tem de fazer dois acessos ao disco em vez de um e ainda dizem que é melhor, porque ocupa menos espaço e outras baboseiras, como é mais dificil fazer cache só dos index's.

    Apenas admitem que é melhor se o ficheiro tiver em cache. Mas que raio todas as bases de dados como deve ser usam Cache aos montes mesmo para isto. Só porque a cache do Mysql é uma bosta dizem que a maneira de eles fazerem as coisas é melhor.

    Pedro Esteves

    Re:Mysql vs PostgresSQL (Pontos:2)
    por leitao em 20-03-03 18:43 GMT (#20)
    (Utilizador Info) http://scaletrix.com/nuno/
    Vê o exemplo dos index's. Todas as bases de dados metem os dados das colunas e os index's no mesmo ficheiro. O mysql para ser diferente mete em ficheiros diferentes.

    Hummm... ha' situacoes (varias) em que podes e deves ter indexes e dados separados, particularmente em bases de dados transaccionais.


    "Arguing on the Internet is like running in the Special Olympics -- Even if you win you're still retarded."

    Re:Mysql vs PostgresSQL (Pontos:2)
    por DomusOnline em 21-03-03 11:20 GMT (#22)
    (Utilizador Info) http://bandalarga.domus.online.pt/
    Nope... Como já alguém disse, os índices podem ser criados em zonas diferentes dos dados.

    Há razões de performance e outras que justificam isto.

    Quanto às caches, baseiam-se na utilização de buffers (que representam blocos de disco). Quanto mais referenciados forem mais probabilidade têm de ficar na memória.

    Já agora (e isto é muito estranho vindo de mim ;) ) o mySQL não é necessariamente uma bosta. A postura deles é que é :P

    Haverá muitas situações onde o mySQL se dá bem. Aliás são conhecidas referências de sucesso.


    Re:Mysql vs PostgresSQL (Pontos:2)
    por MavicX em 21-03-03 11:36 GMT (#24)
    (Utilizador Info) http://www.startux.org
    Sim eu tambem não dispenso mysql para php-nukes siteseed, e outras pequenas aplicações.

    Nada se compara á sua facilidade de instalação, ocupa poucos recursos e é relativamente rápido.

    Tudo depende das aplicações. Mas que o mysql tem muitas limitações isso tem, mas tenho uma grande fé no mysql 4.x. Só é pena ele tar a desenvolver-se tão devagar...


    Pedro Esteves

    Re:Mysql vs PostgresSQL (Pontos:2)
    por vd em 20-03-03 18:24 GMT (#17)
    (Utilizador Info) http://paradigma.co.pt
    Claro que enquanto se "locka" a tabela ninguém trabalha. Isto é giro em coisas com muito poucos utilizadores... mas e quando são muitos?

    read lock, write lock.
    Com a possibilidade de inserts e updates.

    insert delayed para queue em elementos "locked".



    vd
    Re:Mysql vs PostgresSQL (Pontos:2)
    por leitao em 20-03-03 18:31 GMT (#18)
    (Utilizador Info) http://scaletrix.com/nuno/
    Ja' ouviste falar de "row-level locking" certamente ?


    "Arguing on the Internet is like running in the Special Olympics -- Even if you win you're still retarded."

    Re:Mysql vs PostgresSQL (Pontos:2)
    por raxx7 em 20-03-03 18:55 GMT (#21)
    (Utilizador Info)
    Da documentação do MySQL:
    INSERT DELAYED only works with ISAM and MyISAM tables.

    ...que não suportam transacções...
    Além de que INSERTS estão longe de ser a única operação que se faz num RDBMS.
    As ReadLocks e WritesLocks, só permitem ter múltiplas operações de leitura em simultâneo. As operações de leitura continuam a ser mutualmente exclusivas, tanto com operações de leitura como com outras operações de escrita.
    Já o PostgreSQL utiliza MVCC para lidar com o assunto.


    Remember to be the Killer, not the Victim! (Nuklear Girl)
    Re:Mysql vs PostgresSQL (Pontos:2)
    por leitao em 20-03-03 16:46 GMT (#14)
    (Utilizador Info) http://scaletrix.com/nuno/
    Referindo ao teu comentario acima, nao quero te fazer passar por estupido... mas andas muito mal informado.


    "Arguing on the Internet is like running in the Special Olympics -- Even if you win you're still retarded."

    Re:Mysql vs PostgresSQL (Pontos:2)
    por MavicX em 20-03-03 17:42 GMT (#15)
    (Utilizador Info) http://www.startux.org
    Lock table ? LOL

    Bem acrescentando algumas coisas ao bom post do Domus.

    Imagina que tens uma tabela lock porque algum user fez um select complexo e que demora muito tempo. Todos os outros users tem de estar á espera que esse select acabe para fazerem outros updates ou selects nessa tabela. Isso simplesmente não é possivel com muitos users.

    Agora imagina que um programa externo acede a um tabela lock do mysql e fica á espera que o user dê uma instrução qualquer para ele continuar (ou por exemplo o disco tá cheio). Enquanto o user não acabar de tomar o café o programa tem sempre a tabela locked e mais niguem pode aceder a ela.

     

    Pedro Esteves

    Re:Mysql vs PostgresSQL (Pontos:2)
    por vd em 20-03-03 18:31 GMT (#19)
    (Utilizador Info) http://paradigma.co.pt
    Imagina que tens uma tabela lock porque algum user fez um select complexo e que demora muito tempo. Todos os outros users tem de estar á espera que esse select acabe para fazerem outros updates ou selects nessa tabela. Isso simplesmente não é possivel com muitos users.

    Lê o meu outro post...

    http://www.mysql.com/doc/en/LOCK_TABLES.html

    vd
    Re:Mysql vs PostgresSQL (Pontos:2)
    por MavicX em 21-03-03 11:29 GMT (#23)
    (Utilizador Info) http://www.startux.org
    Tirado da tua marivilhosa page ...

    "The downside is, of course, that no other thread can update a READ-locked table and no other thread can read a WRITE-locked table."


    Pedro Esteves

    Re:Mysql vs PostgresSQL (Pontos:2)
    por Cyclops em 20-03-03 14:46 GMT (#9)
    (Utilizador Info) http://www.1407.org
    É um defeito passar os testes ACID? ]:->
    Re:Mysql vs PostgresSQL (Pontos:2, Interessante)
    por Ricardo Dias Marques em 20-03-03 14:18 GMT (#7)
    (Utilizador Info)

    Olá igod,

    Recomendo-te a leitura da seguinte discussão aqui na Gildot, em 19 Dezembro 2002:

    gildot | Artigos | Base de Dados (19 Dezembro 2002)
    http://www.gildot.org/articles /02/12/19/173224.shtml

    Relativamente ao artigo que o vd referiu aqui:

    MySQL and PostgreSQL Compared (Julho 2000)
    http://www.phpbuilder.com/column s/tim20000705.php3

    O mesmo autor (Tim Perdue) escreveu um outro artigo, em Novembro do mesmo ano, com algumas conclusões diferentes, nomeadamente no que diz respeito à velocidade (devido a melhorias da velocidade do PostgreSQL na sua versão 7):

    Open Source Databases: As The Tables Turn (Novembro 2000)
    http://www.phpbuilder.com/column s/tim20001112.php3


    Um abraço a todos, Ricardo
    PostgreSQL (Pontos:3, Interessante)
    por ^S^ em 20-03-03 14:18 GMT (#8)
    (Utilizador Info) http://www.zbit.pt/~luis
    Definitivamente. Esta versao mais recente, da serie 7.3 parece-me imbativel.

    Resta acrescentar que tambem uso MySQL, mas optei por PostgreSQL nas maior parte das aplicacoes. Como mencionado ha' pouco tempo -- picked the right tool for the job.

    Cheers.
    ^S^
    Re:PostgreSQL (Pontos:2)
    por ^S^ em 20-03-03 14:55 GMT (#10)
    (Utilizador Info) http://www.zbit.pt/~luis
    Ops... isto era mais um comentario que devia estar "abaixo" de "MySQL and PostgreSQL".

    mea culpa
    ^S^

     

     

    [ Topo | Sugerir artigo | Artigos anteriores | Sondagens passadas | FAQ | Editores | Preferências | Contacto ]