pô, é completamente diferente
os rdbms possuem muitas características diferentes, mas essas
diferenças são "comandos" na linguagem sql, ou seja, na "string" que
interage com o banco.
ainda, no python, (novamente, sorry) o pep-249 padroniza a API de
todos os rdbms.

a grosso modo, os ORMs servem pra criar uma query string, e nada mais.

porém, não quero de modo algum desencorajar o desenvolvimento de um
"opl". apenas reforço que "minha opinião pessoal" é que "hoje" não
vale a pena por ser pouco provável que facilite a programação, ao
invés de complicar e deixar tudo lento pelo overhead dessa camada
extra.

2010/2/8 Marinho Brandao <marinho@...>:
> Alexandre,
>
> se for seguir o seu raciocínio, então para quê existem ORMs?
>
> 1) Cada banco relacional possui sua variante do SQL e do padrão de DDL/DML
etc,
> 2) Cada um deles possui uma forma de comunicação diferente
> 3) Cada um deles possui uma forma de indexar e armazenar páginas próprias
> 4) Já existem bibliotecas com o psycopg, MySQLdb, etc para implementar
> as particularidades e comunicação de cada um
>
> Ou seja, porque não usar direto o psycopg? Pra que existem interfaces
> como ODBC, JDBC, etc.?
>
> Veja, a gente precisa se lembrar de que relacional ou não relacional,
> todos eles são REPOSITÓRIOS DE DADOS, e os dados que são direcionados
> a eles geralmente vêm de uma classe de modelo. Ponto final.
>
> Ou seja: todos eles são formas diferentes de se armazenar dados que
> estavam em objetos... ou seja:
>
> MAPEAMENTO OBJETO -> REPOSITORIO.
>
> Agora, sobre qual é o tipo do repositório, isso é questão pro adapter
> (ou backend, como preferir) resolver, e ele provavelmente vai usar as
> bibliotecas já existentes (psycopg, pymongodb, MySQLdb, etc) pra isso.
>
> Quanto aos backends de bancos NoSQL para Django, dê uma olhada no fonte deles
;)
>
> Em 6 de fevereiro de 2010 23:07, Alexandre Fiori <fiorix@...> escreveu:
>>
>>
>>
>> o que posso compartilhar aqui é o seguinte:
>>
>> alguns amigos que trabalham na boo-box.com, com o sistema em ruby, usaram
>> couchdb e tiveram péssimas experiências. muito problema com desempenho e
>> estabilidade - como vários crashes por dia em high-load.
>>
>> sobre bibliotecas de persistência, acho bem improvável que passem a
suportar
>> "nosql" pois esses bancos não seguem uma linguagem comum como sql, que já
>> não se enquadra no PEP 249 (python database api specification v2.0:
>> http://www.python.org/dev/peps/pep-0249/)
>>
>> voltando ao assunto original desta thread, the é desempenho vs capacidade,
>> posso compartilhar o seguinte:
>>
>> o maior sistema que já desenvolvi com python e rdbm era baseado em pgsql;
>> mas antes, fiz diversos testes com mysql, sybase, firebird e até lucene -
>> pois um dos requisitos era full-text search. o pgsql foi o que se comportou
>> melhor, com cerca de 10 milhões de registros adicionados e removidos por
>> dia, mantendo uma média de 250 milhões de registros constantes na base.
>>
>> usando sharding, dividindo read e write para máquinas diferentes, com 6
>> máquinas (3 masters e 3 slaves), funcionou perfeito. a indexação é meio
>> lenta, pois cada insert já indexava também os campos de busca por texto,
>> usando "fast full-text search" - artigo do meu blog:
>> http://fiorix.wordpress.com/2009/03/12/postgresql-fast-full-text-search/
>>
>> por fim, sobre nosql:
>>
>> tenho mantido dois "drivers" para bancos completamente diferentes, baseados
>> em twisted, para redis e mongodb.
>> http://github.com/fiorix/txredisapi
>> http://github.com/fiorix/mongo-async-python-driver
>>
>> é impossível que essas APIs sejam padronizadas e enquadradas em algo como
>> sqlalchemy, pois os métodos providos por esses bancos são totalmente fora
do
>> padrão sql.
>>
>> ainda, vale lembrar que o mongodb (que é c++ e não c) permite acessar os
>> registros através do filesystem, usando o gridfs:
>>
>> http://www.mongodb.org/display/DOCS/GridFS+Specification
>> e um módulo REST pro nginx, que acessa o gridfs:
>> http://github.com/mdirolf/nginx-gridfs
>>
>> a única limitação é que cada registro pode ter no máximo 4MB. além
disso, o
>> mongodb tem uma limitação de base máxima de 2.5GB em máquinas 32bit - já
em
>> máquinas 64bit o tamanho da base é ilimitada, e em ambos os casos ele é
>> super rápido pois o acesso aos dados é feito por meio de mmap, onde o
kernel
>> já se encarrega de fazer cache dos dados mais acessados.
>>
>> http://blog.mongodb.org/post/137788967/32-bit-limitations
>>
>> espero que ajude.
>>
>> abs
>>
>> AF
>>
>> 2010/2/6 Marinho Brandao <marinho@...>
>>
>> >
>> >
>> > Ha, e mais uma coisa...
>> >
>> > Uma coisa que andei falando recentemente na lista do Tornado e no
>> > Twitter, mas falei também há uns 4 ou 5 anos quando entrei na
>> > python-brasil:
>> >
>> > Eu sinto falta de uma biblioteca de persistência no Python *que não
>> > seja presa* ao modelo ORM. De fato, as bibliotecas que eu conheço
>> > razoavelmente (SQLAlchemy, Django e SQLObject) estão *muito* presas ao
>> > relacional e à normalização. Chega a ser inviável adaptá-los a bancos
>> > NoSQL.
>> >
>> > Eu já fiz uma OPF (que acho um nome mais razoável do que ORM) em
>> > Delphi que era bem mais compatível com esse modelo, e se não fosse a
>> > inviabilidade de reinventar a roda, eu faria uma semelhante no Python,
>> > mas o fato é que hoje não é nada prático usar mais de um banco de
>> > dados (de paradigmas diferentes) nas bibliotecas que eu conheço no
>> > Python
>> >
>> > Só uma centavo a mais... :)
>> >
>> > Em 6 de fevereiro de 2010 19:13, Marinho Brandao
<marinho@...<marinho%40gmail.com>>
>> > escreveu:
>> >
>> > > Oi Marco, boa noite
>> > >
>> > >> Aproveitando a mensagem do Luciano e essa discussão off-topic sobre
>> > Banco de Dados...
>> > >
>> > > nem tão off assim :P
>> > >
>> > >> Gostaria da receber opinião do pessoal da lista para o seguinte
>> > problema.
>> > >>
>> > >> Já faz algum tempo que participo do desenvolvimento de um sistema que
>> > não usa Banco de Dados,
>> > >> todas as informações são armazenadas em arquivos proprietários no
"file
>> > system". O motivo
>> > >> de usar essa abordagem é porque ainda não encontramos uma solução
viável
>> > de banco de dados
>> > >> para armazenar um grande volume de dados. Estou falando algo em torno de
>> > 60 milhöes de
>> > >> registros sendo inseridos na base de dados por dia.
>> > >
>> > > vixi, isso é MUITA coisa... hehe :)
>> > >
>> > >> Atualmente estou começando a analisar bancos de dados orientados a
>> > coluna
>> > >> http://en.wikipedia.org/wiki/Column-oriented_DBMS (ouvi dizer que um
>> > produto da HP está usando
>> > >> o Sybase IQ que é um banco de dados orientado a coluna) para
>> > armazenamento de grandes volumes
>> > >> de dados). Confesso que Banco de Dados não é muito minha praia....
>> > >>
>> > >> Gostaria de receber opiniões das pessoas da lista a respeito desse
>> > conceito de banco de dados ou
>> > >> de algum outro modelo de armazenamento para grandes volumes de dados.
>> > >>
>> > >> Para não ficar tão distante do mundo Python, esse sistema foi todo
>> > desenvolvido em Python.
>> > >
>> > > Olha, eu tenho tido experiência prática com o CouchDB e com o MongoDB.
>> > > Nada no nível de 60 milhões de registros diários, mas as minhas
>> > > opiniões sobre os dois estão assim:
>> > >
>> > > Sobre o CouchDB, estamos usando num sistema onde há mais de 4000
>> > > instituições cadastradas e cada uma delas entra com suas informações,
>> > > *mas* essas informações são peculiares de cada uma (imagine que uma
>> > > universidade federal do Kansas possua informações que divergem por
>> > > definição de uma escola de artes particular de Nova York, e assim por
>> > > diante. O CouchDB é REST nativo e suporta persistência assíncrona.
>> > >
>> > > Sobre o MongoDB, estamos usando num aplicativo pequeno, desktop, que é
>> > > instalado com instalador e em várias redes locais pequenas (de uma a 5
>> > > máquinas cada). O desempenho do Mongo me pareceu superior, é muito
>> > > fácil de instalar standalone, e às vezes lembra o memcache (ele tem um
>> > > cache em memória na fronteira entre a comunicação e a persistência.
>> > > Por outro lado, não tem REST nem persistência assíncrona (coisas que
>> > > estão em desenvolvimento). Outra coisa peculiar do Mongo é que o BSON
>> > > (formato semelhante ao JSON) é usado para filtro, map/reduce e o
>> > > diabo, e às vezes é meio esquisito, com JavaScript e umas macros no
>> > > meio da história.
>> > >
>> > > Resumindo, o CouchDB parece mais lento, porém mais elegante. O Mongo
>> > > parece mais prático para trabalhar distribuído. E outra coisa: o
>> > > CouchDB é Erlang e o MongoDB é C puro, ou seja...
>> > >
>> > > Bom, é isso o que eu tenho visto até aqui :)
>> > >
>> > > --
>> > > Marinho Brandão (José Mário)
>> > > http://marinhobrandao.com/
>> > >
>> >
>> > --
>> > Marinho Brandão (José Mário)
>> > http://marinhobrandao.com/
>> >
>> >
>>
>> --
>> Ship ahoy! Hast seen the While Whale?
>> - Melville's Captain Ahab
>>
>> [As partes desta mensagem que não continham texto foram removidas]
>>
>>
>
>
> --
> Marinho Brandão (José Mário)
> http://marinhobrandao.com/
>
>
> ------------------------------------
>
> ,-----------------------------------------------------------.
> | Antes de enviar um e-mail para o grupo leia:              |
> | http://www.pythonbrasil.com.br/moin.cgi/AntesDePerguntar  |
> | E se você é usuário do BOL lembre-se de cadastrar o       |
> | e-mail do grupo na lista branca do seu sistema anti-spam. |
> `-----------------------------------------------------------´Links do Yahoo!
Grupos
>
>
>



--
Ship ahoy! Hast seen the While Whale?
- Melville's Captain Ahab