| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. | | | transacionalidade
Postgres
MySQL (com InnoDB)
Rapidez
MySQL (sem InnoDB)
fiabilidade
Postgres (MySQL corrompe mais facilmente, se bem que também é mais fácil recuperar de uma corrupção)
grande volume de dados
Ambas (mas MySQL dá-se particularmente bem com os reads de selects simples)
permitir guardar binários
MySQL
---------------------------------------------
Se queres uma base de dados de "serviço", rápida e com bastante suporte, vai pelo MySQL.
Se precisares de todas aquelas funcionalidades megalíticas (subqueries, triggers, Stored procedures, views, etc), que raramente são usadas, então vai pelo Postgres.
|
| | | | | | "Se precisares de todas aquelas funcionalidades megalíticas (subqueries, triggers, Stored procedures, views, etc), que raramente são usadas,"
Certamente estas a brincar? Ou então não tens grande noções de uma boa programação com acessos a Base de Dados.
Nuno Paulino aka Rollerball
|
| | | | Estás-te a esquecer que hoje em dia muita gente já não utiliza a base de dados para fazer a programação lógica (por causa das limitações) mas sim uma interface de programação como C, Perl, PHP, etc, etc.
|
| | | | Repara que em termos de performance não há comparação possivel. E que para programação Web os "Stored Procedures" aparecem em todos os "Best Pratices" que encontres.
No entanto, aceito que a maior parte dos programadores não domina essa tecnologia e assim limita-se a usar o que conhece. E que o facto do MySQl, que é a base de dados mais popular em WebSites, não suportar essas tecnologias faça com que não haja grande interresse em aprende-la.
O meu post deveu-se "apenas" a teres considerado funcionalidades megalíticas um conjunto de funcionalidades importantes e muito interessantes.
Nuno Paulino aka Rollerball
|
| | | por Anonimo Cobarde em 20-12-02 21:23 GMT (#49)
|
| Na performance pode-se ter uma penalização se não se usar Stored Procedures, mas para código que deve ser portável e funcional em várias bases de dados é preferível nem tocar nas SP. Por exemplo, tens um projecto que tem que funcionar em mySQL, Access, PostGres e MsSQL consoante a opção do cliente e não vai estar a escrever as stored procedures para todas as bases dados (e algumas nem as suportam). Neste contexto é muito mais simples que todo o código esteja em SQL standard do lado da aplicação.
|
| | | | | Portanto, views sao "features megaliticas", parte da "programacao logica"?.... the mind boggles. E a "programacao logica" (tipo um cascade delete em tabelas master/detail) deve estar numa "interface de programacao" tipo C, Perl, PHP ? Assim vais longe, vais... Cumprimentos Mario Valente
|
| | | | Fazendo quote a mim próprio.
Estás-te a esquecer que hoje em dia muita gente já não utiliza a base de dados para fazer a programação lógica (por causa das limitações) mas sim uma interface de programação como C, Perl, PHP.
Não encontrei a palavra deve. Nem misturei/confundi as features mais avançadas com a programação lógica da bd. Agora se vês isso... é contigo. É que tanto não deve que por exemplo o MySQL 4.1 já vai ter suporte completo para subqueries e o MySQL 5.x vai ter stored procedures, triggers e views.
|
| | | | | Estou para ver :) . Se bem me lembro os gajos ja falavam de incluir sub selects na versao 4. Que era uma das prioridades.
Gustavo Felisberto
72ef1d7183eb2ea89420b94c0cf3e1f1
apt-get install anarchism |
| | | | Sempre são uma empresa e funcionam como tal. Ou seja, primeiro viciam o pessoal na bd deles que é leve, rápida e simples de utilizar e depois vendem as features mais avançadas à parte. É assim que eles estão a fazer os dólares, por isso é natural que essas funcionalidades demorem um pouco a aparecer na versão "freeware".
|
| | | | Definitivamente pescas pouco sobre bases de dados.
Eu vou-te explicar porque é que toda a gente usa a Mysql embora seja uma porcaria. É porque é simples, pequena e faz o trabalho. E serve para quase todas os programas para websites que abundam ai (Phpnukes, slashcode etc...), Não porque é boa.
Nem toda a gente tem a paciencia de sacar os 1.5 Gigas que ocupa a Oracle 9i e ler manuais de 1000 pages só para ficar com uma ideia de como funciona. Por isso vão pela mysql.
Quanto as funções megaliticas elas existem por dois motivos a velocidade (como os stored procedures) e a segurança (como as views). Tens razão para uma base de dados dum Phpnuke com meia duzia de utilizadores a aceder de cada vez, esses conceitos não se aplicam. Mas quando passas esse patamar para bases de dados com milhares de acessos por segundo, existe toda a diferença do mundo.
Pedro Esteves |
| | | | "Eu vou-te explicar porque é que toda a gente usa a Mysql embora seja uma porcaria. É porque é simples, pequena e faz o trabalho."
Já viste a facturação da MySQL AB? Com suporte e formação chega aos vários milhões de $ ano. Se fosse assim tão má achas que alguém pagava?
"E serve para quase todas os programas para websites que abundam ai (Phpnukes, slashcode etc...), Não porque é boa."
err, pois o slashdot deve ter mesmo meia dúzia de utilizadores ...
provavelmente o que queres dizer é que o MySQL não serve para aplicações pesadas (ou seja tudo o que requeira forte integridade referencial, transações, etc) mas apenas para aplicações mais simples, com forte integração, p.ex. com o php!
pois não, nada é perfeito! concerteza terá pontos fracos que para o tipo de utilização do autor do artigo (pelo que me é dado a entender) serão fatais!
Mas o que faz, faz bem!
e daí a dizer que é uma porcaria ... acho um exagero!
Cumps
|
| | | | "Já viste a facturação da MySQL AB? Com suporte e formação chega aos vários milhões de $ ano. Se fosse assim tão má achas que alguém pagava?
"
Humm já viste as vendas do access da M$ e das licenças que eles cobram as empresas que usam programas deles. Só um exemplo até bem pouco tempo todas as aplicações de gestão/contabilidade em portugal usavam access e só agora é que estão a começar a usar SQL server.
Isso quer dizer que o access é bom ? Só porque faz muito dinheiro ? Nahhhh
err, pois o slashdot deve ter mesmo meia dúzia de utilizadores ...
Ui a base de dados do slashcode é muito complexa...e os selects, e inserts que aquilo parcticamente usa são muito pesados. Isso vê-se pela Box que eles usam para o SQL server. Um Quad Xeon 550 MHz, 1MB cache. E tem de usar uma box destas em vez de uma cluster como para o webserver pela razão abaixo exposta.
Posso te dizer que há muitas PME's que usam box's bastante melhores que essa para correr a base de dados deles.
Para finalizar deixo-te a frase do slashdot.
"Fault tolerance was a big issue. We've started by load balancing anything that could easily be balanced, but balancing MySQL is harder. We're funding development efforts with the MySQL team to add database replication and rollback capabilities to MySQL (these improvements will of course be rolled into the normal MySQL release as well). "
Para mim seria mais obvio migrar para Postgres ou sapDB e deixar de lado o mysql.
Pedro Esteves |
| | | | a comparação que fazes não é justa, já que o maior rendimento da MySQL AB não provêm da venda de licensas mas de formação, ao contrario da Microsoft! Ora pagar centanas de $ de formação por uma "porcaria" ...
e o que é que me interessa a complexidade da bd do slashdot?
eu não disse que o MySQL serve para tudo! Eu disse que para o que se propõe fazer faz bem, é simples, é rápido! Resumindo não é uma "porcaria"!
e não disse que não devia usar PG ou outra coisa qq! apenas discordei da classificação!
Cumps e Bom Natal
|
| | | | Definitivamente pescas pouco sobre bases de dados.
Sim, a pesca anda má. É do petroleo e do fertilizante.
Eu vou-te explicar porque é que toda a gente usa a Mysql embora seja uma porcaria.
Ena, tanta hostilidade. Deixa-me adivinhar, não ter 1.5G de tamanho incomoda-te? Um caso de Size Matters?
Mas quando passas esse patamar para bases de dados com milhares de acessos por segundo, existe toda a diferença do mundo.
Pois... o Slashdot tem de facto poucos acessos por segundo... Enfim...
E compara lá então com o "teu" Oracle.
|
| | | | Acho que se falou em aplicações livres, Oracle 9i não é livre em nenhum sentido, apenas existe versão livre para testes/desenvolvimento.
|
| | | | Essa das funcionalidades megalíticas fez-me lembrar o comentário apressado de Francisco Louça referindo-se às portagens da CREL como o regresso do Feudalismo às Cidades. Quer num caso, quer noutro, não entendi tão subliminar conceito. O Franscisco Louça ainda compreendo que na pressa de chegar aos microfones e despachar qualquer coisa antes de todos os outros vá dizendo também uns disparates, mas agora aqui e sobre as Base de Dados, podes explicar melhor essa coisa do Megalítico ?
|
| | | | Possa. Tantos gatos assanhados por causa da palavra 'megalíticas'. Aqui fica a resposta para todos.
O nosso amigo pede: open source ou freeware, transacionalidade, rapidez, fiabilidade, grande volume de dados, permitir guardar binários, certo? Para o caso dele subqueries, triggers, Stored procedures, views, etc, são megalitos = pedras grandes = coisas grandes = coisas que não precisa = coisas que vão atrapalhar a performance e até a sua decisão na escolha de um SGBD. Por isso, guardem lá os sabres e as baionetas, seu animais! Chiça, parece que andam sempre à procura de sangue.
E isto agora tá na moda o ataque geekish ao que é popular? Só porque o MySQL se tornou a "bd do povo" de repente saem à rua com as tochas prontos a queimar na fogueira o líder que ajudaram lá a pôr? É que de repente, um incauto pode começar a duvidar se dizemos mal dos produtos na M$ porque são mesmo maus ou porque são apenas populares...
|
| | | | "E isto agora tá na moda o ataque geekish ao que é popular?"
Eu sempre disse mal da mysql :-)
Até podes fazer um search dos meus comentários no gildot. Penso que a mysql 4.1 é capaz de trazer algo novo, á minha opinião. Mas tambem já tou à espera á mais de um ano por ela. parece que a 4.0 nunca mais sai de beta.
Pedro Esteves |
| | | | Subqueries, stored procedures e views funcionalidades megalíticas...
Acho que vou também passar a considerar as variáveis automáticas em C como uma funcionalidade megalítica e passar a programar à lá COBOL... give me a break!
-- Carlos Rodrigues
|
| | | | variáveis automáticas? Explica lá esse novo conceito técnico.
|
| | | | O conceito de variável automática não tem nada de novo...
Todas as variáveis locais numa função são automáticas, excepto se declaradas estaticas (as globais também não são automáticas).
Por outras palavras, estas variáveis aparecem quando a função é chamada e desaparecem quando a função termina, dai o "automático".
Alias, a keyword auto é reservada desde a primeira versão do C, ainda antes de 1978 (altura do primeiro livro "The C Programming Language", de Brian W. Kernighan e Dennis M. Ritchie)...
--
"In my egoistical opinion, most people's C programs should be indented six feet downward and covered with dirt." |
| | | por Anonimo Cobarde em 19-12-02 19:05 GMT (#7)
|
| Neste momento tens 3 grandes bases de dados:
Microsoft SQL
Oracle
e
Informix
A nível de estruturação e extensão da propria base de dados tens a Informix~, com uma panóplia de aplicações bastante extensivel.
A Microsoft SQL neste momento é a que está melhor no mercado, tanto ao nivel de estabilidade (piada, né) como de desempenho, com uma capacidade gigante de processação de objectos.
Depois tens a velha Oracle que tb é mt boa mas já viu melhores dias.
Tudo depende do tipo de dados que tenhas. Cada caso é um caso e tens que avaliar todas as opiniões neste forum.
Agora venha o diabo e escolha.
Um abraço.
|
| | | | | por Anonimo Cobarde em 19-12-02 19:20 GMT (#8)
|
| Qual a melhor base de dados (open source ou freeware, de preferência open-source) que podemos encontrar hoje.
Ainda bem que sabes ler Leitão! (e ainda o queriam para editor)
|
| | | por Anonimo Cobarde em 19-12-02 22:03 GMT (#12)
|
| Pois fui eu quem escreveu. Peço desculpas, não reparei na parte -open source ou freeware, de preferência open-source- Mas mesmo assim aqui fica a minha opinião sobre as BD´s ;)
|
| | | | mania da perseguição, hum??
---------------------
The worst moment for the atheist is when he is really thankful and has nobody to thank. Dante Rossetti |
| | | | 6...
DB2
Sybase
Teradata
SQL Server está melhor? Em estudos de Windows certamente. Se abrires o campo e encarares BD relacionais em sistemas Unix e NT o Oracle está à frente destacado.
Se abrires ainda mais e incluires mainframes e/ou BDs não relacionais a IBM salta para a frente destacada.
Há estudos para todos os gostos ;)
Cumprimentos.
|
| | | | Deixa o Filesystem ser o teu motor de base de dados :).
|
| | | | De momento existem dois SGBD OpenSource que merecem ser mencionados para aplicações empresariais.
O conhecido PostGres e o a sapDB
O mysql e outras como o Firebird, simplesmente não estão maduras o suficiente.
O PostGres agora na versão 7.3 é conhecido por toda a gente e uma das bases de dados opensource mais avançadas. Não só pelas suas funções como pela sua fiabilidade e desempenho e escalibilidade. E é usada por muitas bases de dados a nivel comercial.
A Sapdb (www.sapdb.org) era até à pouco tempo uma base de dados comercial desenvolvida pela conhecida SAP, mas que recentemente foi tornada OpenSource. Embora não seja uma Oracle Ou DB2 é bastante completa e rapida, e é usada para muitas das instalações do SAP R/3 a nivel mundial. Agora na sua versão 7.4 continua a ser desenvolvida e mantida pela SAP e tem exelentes tools e documentação.
Entre estas duas, tenho me inclinado ultimamente para a SapDB devido principalmente a correr nativamente na plataforma windows (NT) ao contrário da PostGres. Mas ambas são exelentes SGBD.
Pedro Esteves |
| | | | | | Eu não sei bem a história antiga da sapDb , mas não é a adabas (embora é capaz de ter alguns componentes), a adabas é como os So's o mesmo que o BSD 4.4 lite é hoje para os BSD's actuais. Um ponto de partida. O SGBD que a Sun meteu no staroffice, o starbase é que usa mais directamente codigo da adabas (é por isso que não pode ser incluido no openoffice).
Alias a adabas é da softwareag.com
Mas o que aposto na SapDB é o seu desenvolvimento futuro.
"How many people are developing SAP DB?
Since mid-1997, SAP has made considerable investments into SAP DB, which is maintained and continuously enhanced by a dedicated team of about 100 SAP developers."
Pedro Esteves |
| | | | Estive para não responder a isto por dois motivos:
- Já gerou flames que cheguem
- O MavicX já disse praticamente tudo
Para dar achas a quem tiver fósforos a mais: Nunca usei nenhum dos produtos de que vou falar
Eu costumo comparar ou melhor, costumo dizer que o mySQL é a MS das bases de dados OpenSource. Não é grande coisa, mas está, como a MS esteve "condenado" ao sucesso.
É indiscutível que tem muitas faltas de funcionalidade. Podem vir a resolver isso na versão XPTO, mas corre-se o risco de ser como as tabelas transaccionais... um "enxerto" que foram buscar a um produto separado. E para já falamos do que existe.
O que também me parece indiscutível, embora não haja números concretos é que é muito usado. Mas não me digam que isso é porque é bom... Não façam isso no Gildot porque outros exemplos saltam logo à ideia ;). Quanto aos números concretos já há um ano os analistas (IDC e companhia) começavam a achar que os estudos teriam de começar a incluir produtos Open-Source com mySQL à cabeça.
Analisem é bem quais são as grandes utilizações e referências do mySQL. Sites Web. Não tem nada de mal, mas o grosso são SELECTS. UPDATES, INSERTS e SELECTS concorrenciais sobre os mesmos dados, a integridade dos dados, estratégias de locking e de nível de isolamento, a independência da interface e muitas outras coisas não são a preocupação principal. O principal é a rapidez do SELECT. Ora quando não há nada a verificar as coisas tendem a funcionar mais rápido. Se isto é mau...? Não muito. Serve, é de borla, tem uma série de produtos "associados" como o phpnuke, sistemas de fóruns etc. logo é muito usado
Agora cuidado ao extrapolar que por ser muito usado nesse ambiente é bom, ou utilizável noutros ambientes, e que as tais funcionalidades não fazem falta etc. Aqui entra-se no disparate. Convém que quem o tenha afirmado tenha a noção que há sistemas onde uma falha de integridade é a morte do artista. E que um trigger é fundamental para propagar eventos, e que uma procedure (para além de servir de suporte a triggers mais complexos) permite colocar código que diz respeito só aos dados no sitio onde ele é mais eficiente e onde é independente das várias aplicações que manipulam os dados: na base de dados. E que alguns sistemas têm de ser 24x7, o que implica backups online, e que quando crasham têm de ir exactamente até ao instante do crash quando levantam, e que devem permitir backups e restores parciais, mas com garantia de integridade lógica e mais uma série de coisas que mySQL não tem, e que para as suas utilizações não precisa.
No que diz respeito às procedures por exemplo, uma aplicação WEB até pode fazer tudo no PHP... Mas quem está habituado a usá-las até numa "porcariazita" as usa... (estou a pensar num sitezito que alguns já terão visitado) ;)
E salvo erro alguém referiu algo como "mySQL corrompe mais facilmente...". Isto fez-me sorrir. Porque denota que se encara a corrupção como uma coisa natural ou habitual. Mais uma vez, isto pode ser a morte do artista... As corrupções existem e podem ser lógicas ou físicas. Mas são sempre devido a BUGs e completamente inadmissíveis.
Quanto ao PostgreSQL, suporta muito mais coisas (já referidas) e consequentemente pode ser obviamente mais lento. Mas suporta outra coisa com que o mySQL nem sonha: Criação de novos e complexos tipos de dados pelos utilizadores. Ou não fosse o Michael Stonebraker quem lhe estivesse na origem. Este senhor tem uma forte "pancada" por base de dados e OO: Ingres (linguagem Vision), PostgreSQL, Illustra (origem de todo o componente OO do Informix), Informix (Visionary) e deve continuar. A menos que se reforme entretanto ;)
Quanto ao SAPdb em "manualware" pareceu-me bastante bom. Quem tenha tempo e interesse devia investigá-lo. Mas corre o risco de ter chegado muito tarde (embora com um avanço considerável).
E pronto... food for thought... espero que seja mais isto que achas para fogueiras.
Cumprimentos.
|
| | | | | | Esqueci-me de um detalhe...
O teste que foi apontado... Mesmo os TPC têm validade técnica muito limitada. Servem para criar curriculum a cada versão nova de qualquer BD, para mostrar em reuniões de gestores.
E aquela feature do cache dos resultados das queries em memória revela bem o que disse antes... Há imensos sitios onde tal é perfeitamente inútil, pois não passa um instante que a cache não seja invalidada. No entanto é uma feature catita para ambiente WEB.
Cumprimentos
|
| | | | 5 estrelas este comentário.
É pena não ter pontos de moderação :-)
Pedro Esteves |
| | | | PostgreSQL [http://www.postgresql.org/]. Tem tudo o que procuras. Obviamente não é tão rápido como o mysql ...
Este conceito que o MySQL é mais rápido que o PostgreSQL, é bastante antigo e tido como um facto. Isto era verdade antes do PostgreSQL atingir a versão 7.0, mas a partir daí, pelas minhas esperiências, isso não é verdade.
Com bases de dados pequenas, e poucos acessos concorrênciais, a diferença de performance entre elas é quase nula, e o MySQL até pode ser melhor, mas se a base de dados começa a crescer o PostgreSQL é muito melhor. O suporte a ligações concorrentes à base de dados, é tambem muito melhor no PostgreSQL, onde tenho verificado que aguenta pelo menos o dobro das ligações simultaneas à base de dados (a efectuarem, querys, updates, deletes, etc) sem perda de performance, enquanto o MySQL se vai abaixo muito mais cedo.
Outro aspecto que para mim é importante, é que o facto de ter transações, views, stored procedures, e essas coisas que muitos acham "que não faz falta" torna o desenvolvimento muito mais rápido e fácil, pois não temos nós (programadores) que andar a fazer o trabalho da base de dados.
|
| | | | | | | Boas, Tal como o _Mordor_ disse, a performance do PostgreSQL melhorou substancialmente a partir da versão 7, e principalmente a partir da 7.1 Aliás, o Tim Perdue - que esteve na fundação de sites como o PHPbuilder.com, o Geocrawler.com e a famosa SourceForge.net, escreveu dois artigos (no ano 2000), sobre o MySQL e o PostgreSQL, em duas alturas diferentes, e a conclusão sobre a performance relativa (no sentido de velocidade) foi de uma significativa melhoria da velocidade do PostgreSQL - de um artigo para o outro. MySQL and PostgreSQL Compared (Julho 2000)
http://www.phpbuilder.com/column s/tim20000705.php3 Open Source Databases: As The Tables Turn (Novembro 2000)
http://www.phpbuilder.com/column s/tim20001112.php3 Um excerto interessante do segundo artigo: I decided to test out a full port of SourceForge.net to Postgres. (...) In fact, our very first benchmarks showed Postgres running 6x faster than MySQL on a very database-intensive page (the "My Personal Page" for logged-in users). Os dois artigos têm muito mais informação sobre as duas bases de dados (para além da questão da velocidade). Contudo, e tratando-se de artigos já com 2 anos, é recomendável ver o que terá sido alterado com versões posteriores de ambas as bases de dados. Por curiosidade, o site da SourceForge começou por ser baseado em MySQL, depois em PostgreSQL e, mais tarde, em DB2 (da IBM). Feliz Natal :)
Um abraço a todos, Ricardo |
| | | | A SysBase é das melhores bases de dados do mundo (logo a seguir á Oracle e á Db2) mas será que essa versão não é só development ? Sera que se pode meter em produção numa empresa comercial sem pagar licenças ?
Ainda não li a licença mas não tou a ver.
Pedro Esteves |
| | | | | | Eu não atino com a interface do Gil...
a minha menção ao Sybase foi em resposta a uma mensagem que penso não foi publicada e que falava de 3 BD comerciais:
Oracle
SQL Server
Informix
Ficou solta de contexto.
todas estas e as que acrescentei são comerciais...
Cumprimentos
|
| |
|
