| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. |
| | O Press Release encontra-se aqui, com bastante mais informação...
|
| |
| | Para alguém que já o tenha usado, q tal corre em windows?
O ano passado tentei usá-lo em windows nas minhas aulas (em detrimento do SQL Server) e depressa me arrependi. O processo de instalação é muito mau, e tinha muitos problemas de estabilidade. Espero que esteja melhor neste aspecto, embora não o vá usar em windows novamente.
I live the way I type; fast, with a lot of mistakes. |
| |
| |
| | Bom, partindo do principio que esta e' a primeira versao oficial a suportar win32, e acabou de ser released, a unica coisa que me ocorre e' que o que experimentaste ha' um ano tenham sido hacks nao oficiais para tentar meter isso em win32.
Nao posso falar por experiencia porque nao tenho windows para experimentar isso, mas se lhe deram tanto enfase, nao acredito que seja por um mero "hack" mas sim algo minimamente estavel e funcional.
Resta apenas a esperanca ate' alguem confirmar...
Cheers.
^S^ |
| |
| | O mais provável é tê-lo executado sob Cygwin, que era a forma err.. recomendada de o fazer.
|
| |
| | | Tenho uns colegas que, para um projecto da cadeira de Base de Dados do IST, sendo possivel escolher o SGBD a utilizar, optaram pelo o postgresql, mesmo na sua versão windows (uma beta da 8.0). No que me diz respeito, e tendo experimentado outros SGBD, nomeadamente Oracle e Sybase, no que se refere a instalar o postgresql no Linux, basta-me afirmar que é a diferença entre escrever na linha de comandos algo como 'emerge postgresql' (no Gentoo Linux) para o postgresql, e andar a "apanhar bonés" com as idiossincrasias dos outros SGBDs, aquando das respectivas instalações. Em relação aos meus colegas que usaram o postgresql no windows, pelo menos não fizeram tanto barulho como os infelizes que, tendo seguido os sábios conselhos dos docentes da cadeira, lá optaram pelo Oracle ("Gostava que este ano o pessoal usasse uma base de dados a sério..."), e acabaram por perder mais tempo na instalação do que no projecto propriamente dito.
Is this desire? |
| |
| | vivas, já usei Oracle em windows e consegui instalar aquilo sem nenhuns atritos !!
___________________________________ (linooks (at) zmail (dot) pt) |
| |
| | acho que o windows é a única plataforma onde se instala oracle sem atritos...
---
Este espaço pode ser seu... |
| |
| | Nunca tive problemas em instalar 9i em RedHat e SuSE. Foi sempre a andar...
Já o 8i em Linux.... que pesadelo! :-(
Se bem que o 8.0 em Linux também não seja MUITO difícil...
Yours,
McB!
They told me it need Windows 95 or better, so I chose Linux |
| |
| | Pois, eu também consegui instalar à primeira tentativa. Mas muitos colegas meus andaram semanas de volta daquilo.
O Oracle tem muitas bizarrias na instalação, especialmente quando se quer que fique acessível por TCP/IP. É preciso paciência para o instalar.
--
Carlos Rodrigues
|
| |
| | Essa da "base de dados a sério" é paradigmática do que se passa em Portugal, onde não se conhece mais nada do que o Oracle ou SQL Server. Se falares no DB2 à maioria das pessoas, ficam a olhar para ti como se fosses um extraterrestre. E o PostgreSQL e o MySQL "são bases de dados para putos". Depois vêem-se por aí pequenos sites alimentados por um Oracle, que os deve ter endividado até à cova.
--
Carlos Rodrigues
|
| |
| | Ou então aplicações que se arrastam porque alguém não percebe o que está a fazer ou é propositado para se sacar massa (Oracle)...
|
| |
| | Com o devido respeito, porque falaste em DB2?
Porque conheces ou porque aparece nas noticias?
Cumprimentos.
|
| |
| | Sempre utilizei em websites de reduzida dimensão e que exigem uma pesquisa rápida o MySQL em detrimento do PosgreSQL. Evitava as Stored Procedures, SQLs nested para o tecto, triggers nem falar, etc.. Contudo, com o PosgreSQL 8 tudo muda de figura: para além de muito estável, como de costume, pareceu-me bem mais rápido que o 6.3 e equivalente ao MySQL.
Como tal, com a velocidade do MySQL e com as funcionalidades que este pecava, ie, Stored Procedures, Triggers, nested SQL, etc.., o Posgre acabou de tirar o lugar ao MySQL. Pena que ainda poucos ISPs de alojamento de sites a providenciem, mas julgo ser questão de tempo.
Excelente produto, recomenda-se!
Paradoxo do ano: Microsoft Works!
Dominus vobiscum |
| |
| |
| | Da maneira como escreste isso, parece que stored procedures e sub-querys são obrigatórios e que triggers são maus. :)
|
| |
| | Bem, lendo o que ele diz também se poderia depreneder que não é a primeira vez que usa o software...mas estamos a falar da música nacional não é?
|
| |
| | Eu já uso PostgreSQL a uns anos, como base de dados principal, e na minha opinião é um dos melhores SGBDs que conheco. Ja usei Oracle, SQL server, Firebird/Interbase e optei pelo PostgreSQL. A linguagem pgpsql deles é muito similar ao plpgsql, mas penso que ainda um pouco melhor. Quando a esta versão 8, tenho-a acompanhado e ja testei a final e posso dizer que está estável. Tem um detalhe que so permite ser instalado em NTFS, mas isso e por causa dos tablespaces que foram implementados nesta versão, o que é uma feature que poucos falam, mas que permite fazer muitas coisas engraçadas. PostgreSQL rulez. Fiquem bem.
|
| |
| | Isso é porque normalmente a malta não sabe o que é um tablespace e/ou como tirar partido disso.
---
Este espaço pode ser seu... |
| |
| | Sites?!...
Então é exactamente no único sítio onde o MySQL mete o PosTgreSQL no bolso que tu queres mudar? Ou achas que o pessoal do Slashdot ou da Wikipedia liga a chavões como "o MySQL não é uma RDBMS" a sério?
A grande vantagem do PostgreSQL (para além de ser "uma RDBMS a sério") é aumentar a velocidade de desenvolvimento (para quem saiba o que está a fazer) para aplicações complexas e que necessitem de funcionalidades especificas ou customizáveis.
"pareceu-me bem mais rápido que o 6.3 e equivalente ao MySQL"
Mas pode-se lá comparar à velocidade de um conjunto MySQL/MyISAM ou MySQL/InnoDB com PostgreSQL? Ou a rapidez com que o MySQL cria ligações concorrentes? Ou soluções como o MySQL Cluster?
E em aplicações Web... complexas?
Usa os dois se for preciso! Há alguma necessidade de criar uma guerra artificial entre 2 excelentes projectos? Qualquer PHP, Perl ou Python tem boas APIs para ambos e consegue-se fazer coisas espectaculares usando os pontos fortes de cada uma.
Eu até gostava que deixassem de convergir tanto e acabarem por perder as vantagens que tem para ficarem "normais". Mas tendo em conta a desvantagem da licença do MySQL se calhar é uma boa ideia o PostgreSQL aproximar-se mais do MySQL. E resta ver o que o Firebird 2 vai trazer...
|
| |
| | Calma lá...
Eu já tenho algumas bases de dados de tamanho já considerável em MySQL. Há uns tempos atrás, porque desconhecia o PostgreSQL, fiz um dump e experimentei usar o PostgreSQL, que se encontrava na mesma máquina (o método de acesso era o modo nativo de PHP). Notei, efectivamente, diferença na velocidade: o MySQL era mais rápido a responder.
Esta diferença de velocidade culmatava as Stored Procedures, os Views, os Nested SQLs, os Triggers.
Agora, que saiu o 8, um colega meu da Faculdade fez experiência similar (não um benchmarking detalhado, obviamente) onde a diferença de velocidade não é nada notória, o PostgreSQL não fica nada atrás.
Não sei quanto a ti, mas eu não gosto de fazer 3 chamadas à base de dados para simular um nested SQL, 20 para simular uma Stored Procedure, 1 para simular um Trigger, 1 para simular uma View. Repara, são transacções sobre a rede que ocupam bastantes bytes, especialmente no caso de Stored Procedures complexas. O PostgreSQL está em grande vantagem.
Paradoxo do ano: Microsoft Works!
Dominus vobiscum |
| |
| | De acordo com o teu exemplo:
1 query PostgreSQL = 20 queries MySQL para digamos, tarefas complexas.
É rara a aplicação Web que necessite desse tipo de tarefas complexas. A grande maioria do trabalho feito numa aplicação Web é leitura, seguido por escrita simples. Depois uma aplicação Web tem que criar e destruir muitas ligações concorrentes. Se o processo de gerir ligações que o PostgreSQL utiliza ainda for o mesmo, quantos mais utilizadores existirem a fazer ligações mais rapidamente raparas na vantagem do MySQL.
Ou seja, se houver uma tarefa complexa para fazer, o PostgreSQL pode fazê-la mais depressa para 1, 10, 100, etc (tudo depende da máquinda) utilizadores. Mas quantos mais utilizadores houver mais a curva de velocidade se irá aproximar do MySQL.
Mas como tinha dito... dado que o grande grosso do trabalho de uma aplicação Web é selects e inserts/updates simples, neste momento é o campo ideal para se usar MySQL em vez de PostgreSQL.
Existem depois outras razões mas dado que só estamos a falar de performance agora não interessam. Se quiseres uma análise comparativa entre as diversas ofertas Open Source dá uma espreitadela em aqui. Parece actualizada se bem que não esteja completa.
|
| |
| | | Ainda usa o mesmo método sim.
Claro que há várias plataformas permitem amortecer esse problema. Ligações persistentes no PHP/Apache, FCGI, aplication servers com ligações persistentes. Já agora, esse link mostra o MySQL 4.1 como non-ACID compliant. Mas a documentação do MySQL diz que é. Tenho a impressão que esse documento está mais que desatualizado..
|
| |
| | Ainda ontem consultei esse website, está bom, e ainda faz um trace das features que irão ser disponibilizadas (Triggers em MySQL 5.1).
Pela comparação, parece-me mesmo que o PostgreSQL parece a base de dados mais equilibrada.
Quanto aos websites, não é assim tão linear quanto isso. Estive num projecto para fazer uma loja de informática on-line, embora com 1/10 das features que uma qualquer, dá muito jeito ter Stored Procedures (e são mais eficientes, pois são menos transacções a efectuar entre cliente e servidor), Triggers e mesmo Views. Poupam-se muitas queries à base de dados e o código fica bem mais simples.
Mas atenção que sempre usei e gosto de usar MySQL. Julgo que em termos de ferramentas de administração é melhor. Contudo, deixei de o aconselhar para sites ou programas que exijam mais que queries simples (DELETE/INSERT/UPDATE/SELECT..)
Paradoxo do ano: Microsoft Works!
Dominus vobiscum |
| |
|
| | Que tal usares um sistema de templates e colocares uma ligação ao início do código e outra ao fim !?
(Exemplo PHP)
$connection=$bdsql->liga();
... (código, sql queries, etc) ...
$bdsql->desliga($connection);
O prob dos aprendizes de programação é que fazem uma ligação em todos os sítios imaginários que há instruções SQL e claro.. nunca as fecham, depois é esperar pelos timeout da connection..
Characteristic of life style... |
| |
| | | O prob dos aprendizes de programação Ou dos que usam ferramentas visuais para criar sites dinâmicos em PHP... Basta ver o código automático gerado pelo dreamweaver, é de rir.
|
| |
| | Uma vez um amigo meu k trabalhava na www.idp.pt, mostrou-me código que fazia lá para desenrrascar através do dreamweaver (ele era designer) e era uma salada russa autêntica.. mas os gajos de lá não querem saber mt.. se funcionar tá bom! o pior é quando aparecem problemas, o site fica lento, bloqueia o servidor e os serviços para os outros, etc..
Characteristic of life style... |
| |
| | Tu fazes a mais pequena ideia do que estás a falar? Não pois não, bem me parecia.
A questão não está em abrir e fechar a ligação à base de dados, está em efectuar 300 mil queries para fazer o mesmo que numa Stored Procedure.
Estes aprendizes que têm a manía que sabem...
Paradoxo do ano: Microsoft Works!
Dominus vobiscum |
| |
| | Frequentemente, em ambientes WEB a conexão é mais pesada qe a execução da(s) queries. Fazer uma conexão por página é um perfeito disparate. Existem alternativas fáceis e óbvias.
Eu não vou chamar aprendiz a ninguém... pode sempre vir um tipo atrás de mim com uma lanterna mais forte...
Cumprimentos.
|
| |
| | Mas isso é óbvio que a ligação pode ser mais pesada que a query (depende do número de bytes que seguem na query também), pelo que a ligação deverá ser apenas terminada no fim, com um timeout, mas não era isso que estava em questão.
O que estava em questão era ele assumir que eu o fazia, quando apenas me estava a referir ao número de queries e depois chamar-me aprendiz, em circunstância despropositadas (até porque ainda sou aprendiz em muitas coisas, como todos nós).
Paradoxo do ano: Microsoft Works!
Dominus vobiscum |
| |
| | O que ainda não ficou claro é que o establecimento de uma conexão numa BD obriga a chamadas de sistema que provocam muito mais peso que a resolução das queries tipicas de ambiente Web.
E também não ficou claro que a ligação NÃO deve ser terminada. Deve ser re-utilizada por outros pedidos que venham a seguir. Deve ser criada uma pool de ligações quando arrancas com o sistema e depois os pedidos vão usando as ligações rotativamente ou conforme estejam disponíveis.
Para quem usa PHP é ver os p_connect() em vez dos connect()
Cumprimentos.
|
| |
| | E resta ver o que o Firebird 2 vai trazer... Não é do Firebird 2 que irão saír as grandes novidades:Backup transaccional com recurso a cópia físicaBackup diferencialNovo protocolo de transporte XNETRapidez melhoradaTabelas DerivadasMelhorias no PSQL e DSQLInterface UNICODE e melhorias nos collationsetc...mas sim do Vulcan a versão percussora do Firebird 3: Versão nativa para plataformas 64-bitSuporte a SMP e Hyper ThreadingSuporte a ligação do engine a motores externos (oracle, db2, etc)Configuração por cada Base de Dados e por engine)Restruturação quase completa do motor Interbase/Firebird com 20 anos por uma nova arquitectura baseada em objectos para prever o crescimento para os próximos 20 anos (e paradoxo dos pradoxos arquitectada pelo mesmo velho lobo, Jim Starkey o homem do Datatrieve, que a pensou há 20 anos atrás)PS: Ecos do sucesso...
Carlos Mação
Membro do Projecto Marathon
Membro da Fundação Firebird |
| |
| | # Versão nativa para plataformas 64-bit # Suporte a SMP e Hyper Threading UH. Estás-me a dizer que o FireBird não corre decentemente em plataformas de 64bit nem aproveita múltiplos CPUs?
|
| |
| | # Versão nativa para plataformas 64-bit
# Suporte a SMP e Hyper Threading UH. Estás-me a dizer que o FireBird não corre decentemente em plataformas de 64bit nem aproveita múltiplos CPUs?
|
| |
| | | Não foi isso que eu disse, já existem builds para AMD64 ou IA64, Win on Linux, mas da mesma forma que podes pegar numa aplicação de 16 bits e compilá-la com um compilador de 32 bits isso não significa que tires partido real dos registos e processamento melhorado, para isso tens que modificar o código.Além disso mais plataformas 64 bits serão acrescentadas às mencionadas; nomeadamente Solaris. Quanto ao SMP efectivamente essa é uma limitação actual do Firebird, na presença de mais de um processador tens que instruir o Firebird para usar apenas um deles (de preferência não o primeiro) embora existam relatórios que na versão Classic(a memória utilizada pelo servidor para cada ligação corre no contexto do processo desse utilizador) existem melhorias reais de desempenho com mais de um processador. Quanto ao Hyper Threading não existem problemas com as actuais versões do Firebird embora só com a tecnologia Vulcan/Firebird 3, devido à "fine-grained threading" aí implementada, poderás sentir desempenho melhorado. PS: Neste momento já se testa o Vulcan e o processo de integração Vulcan Firebird 3 também já foi iniciado.
Carlos Mação
Membro do Projecto Marathon
Membro da Fundação Firebird |
| |
| | Ah. Como disseste "nativo", pensei que só corresse em plataformas de 64 bit compilado para ABIs de 32bit :)
|
| |
|
| | | Sempre utilizei em websites de reduzida dimensão e que exigem uma pesquisa rápida o MySQL em detrimento do PosgreSQL. Apesar de essa ser a "noção" geral, não acho que o MySQL seja mais rápido que o PG na maioria das aplicações. Administro vários sites em PHP/MySQL e o bottleneck é sempre o MySQL, mesmo quando a base de dados inteira do site poderia ser cacheada em ram. Outro problema é que muito raramente o MySQL (4.0 neste caso) recupera de situações de DoS, tendo que ser reiniciado manualmente. O facto de, no meu caso, o MySQL processar até cerca de 45 queries/s (e os sites frequentemente serem mal concebidos em termos de sql), limita gravemente a capacidade de resposta do webserver.
|
| |
| | O facto de, no meu caso, o MySQL processar até cerca de 45 queries/s (e os sites frequentemente serem mal concebidos em termos de sql), limita gravemente a capacidade de resposta do webserver.
O problema é que a falta de features do MySQL te obrigam a efectuar muito mais queries do que aquelas que seriam necessárias.
Paradoxo do ano: Microsoft Works!
Dominus vobiscum |
| |
