Persistência de objetos

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Persistência de objetos

"Cláudio Pires (Yahoo)"
Pessoal, estou iniciando em Python e gostaria de alguns conselhos para
persistir objetos (de um pequeno sistema comercial, como por exemplo,
controle de estoque) em um banco de dados.

Sei que o melhor seria a utilização de um banco 100% OO, e que em um
SGBDR clássico teremos sempre o mapeamento Objeto-Tabela para nos
preocuparmos.....
Minha questão é: Há alguma vantagem em se utilizar um banco
objeto-relacional (como o PostgreSQL)? Isso pode poupar algum trabalho
de codificação ou aumentar a performance no acesso gravação de dados?

Para essas aplicações comerciais que precisam persistir dados, como a
comunidade esta "se virando"? (que mecanismo de persistência tem sido
utilizado?)

Antecipadamente, obrigado a todos pela ajuda :)


Reply | Threaded
Open this post in threaded view
|

Re: Persistência de objetos

Osvaldo Santana Neto-2
Oi Cláudio,

2010/6/26 "Cláudio Pires (Yahoo)" <[hidden email]>:
> Pessoal, estou iniciando em Python e gostaria de alguns conselhos para
> persistir objetos (de um pequeno sistema comercial, como por exemplo,
> controle de estoque) em um banco de dados.

"A história tem mostrado" que os bancos de dados relacionais se saem bem
em sistemas com esse perfil.

> Sei que o melhor seria a utilização de um banco 100% OO, e que em um
> SGBDR clássico teremos sempre o mapeamento Objeto-Tabela para nos
> preocuparmos.....

Existem vários sistemas ORM para Python. Alguns que eu me lembro de cabeça
são: Storm (feito pelo brasileiro Gustavo Niemeyer), SQLAlchemy (um dos mais
usados) e SQLObject (um dos mais antigos).

Além desses alguns frameworks Web (como o Django) possuem um ORM como parte
de seus componentes.

> Minha questão é: Há alguma vantagem em se utilizar um banco
> objeto-relacional (como o PostgreSQL)? Isso pode poupar algum trabalho
> de codificação ou aumentar a performance no acesso gravação de dados?

O mundo dos bancos de dados estão passando por um processo bastante
"barulhento" mais recentemente com o lançamento de vários sistemas
denominados "NoSQL".

Anda bem "perigoso" e complicado escolher como e onde persistir seus dados
porque existem um sem número de alternativas voltadas para resolver determinados
tipos de problemas ao custo de uma ou outra característica.

Por exemplo: O banco de dados NoSQL MongoDB oferece muitas possibilidades de
escalabilidade horizontal ao custo de não garantir "durabilidade" dos dados
(a letra D de ACID). Em determinados cenários isso serve muito bem e torna
a adoção do MongoDB numa escolha acertada. Em outros casos não.

O que quero dizer é que é preciso tomar muito cuidado com o atual "hype" dos
bancos de dados NoSQL antes de adotar um deles no lugar de um RDBMS
"tradicional".

> Para essas aplicações comerciais que precisam persistir dados, como a
> comunidade esta "se virando"? (que mecanismo de persistência tem sido
> utilizado?)

A imensa maioria recorre à um dos ORMs citados anteriormente e usam um
RDBMS (MySQL ou PostgreSQL na maioria das vezes) para armazenar os dados.

Na minha empresa nós estamos desenvolvendo um sistema de gestão empresarial
(nos moldes desse que você está falando) e estamos usando um banco de dados
orientado a objetos bastante "antigo" e famoso na nossa comunidade: ZODB.

Estamos usando o ZODB para persistir os dados em um MySQL (de forma não
relacional nos moldes de um tabelão único com todos os objetos serializados
dentro) usando o backend RelStorage do ZODB.

Mas o software que estamos fazendo tem uma camada (fina) entre o ZODB e a
nossa aplicação para que, caso o ZODB deixe de nos atender, possamos trocá-lo
pelo MongoDB que foi o segundo colocado na nossa pesquisa.

Optamos por não usar um banco de dados relacional porque nossa aplicação tem
um diferencial para as aplicações "tradicionais": os dados são modelados em
tempo de execução, ou seja, não poderíamos ter tabelas com "schema" fixo*.

Porque insistimos em bancos de dados relacionais? Maturidade das soluções,
das ferramentas de administração, etc. Por estarem a tanto tempo "rodando"
todos já sabem de seus problemas e limitações. Isso nos deixa mais
tranquilos.

* É possível fazer isso com bancos de dados relacionais e chegamos a algo
  parecido com isso: http://bret.appspot.com/entry/how-friendfeed-uses-mysql.
  Gostamos muito dos resultados mas acabamos nos vendo implementando um
  sistema ORM "do zero" e não podíamos investir tanto tempo assim nesse
  desenvolvimento. Se a turma do friendfeed tivesse liberado o ORM deles
  como open-source provavelmente estaríamos percorrendo esse caminho.

Obrigado,
Osvaldo

--
Curso de Desenvolvimento Web com Python e Django — R$200,00 (12xR$19,00)
http://www.ludeos.com.br/s/triveos-cursos-online

--
Osvaldo Santana Neto -- Triveos Tecnologia
Cel.: +55 41 9244 1646
Reply | Threaded
Open this post in threaded view
|

Re: Persistência de objetos

Felipe Cruz
In reply to this post by "Cláudio Pires (Yahoo)"
Claudio,

Há algum tempo que eu venho revesando o uso de bancos relacionais com um
projeto que eu mesmo desenvolvi, o copycat: http://copycat.loogica.net/

A grande vantagem dele é que voce programa 100% OO e vc foca apenas na
construção dos seus objetos. É transparente e não intrusivo, ou seja, voce
usa ele sem perceber e sem ter que ficar fazendo chamadas a uma API.

Agora.. eu sempre digo que existem projetos que tem uma natureza relacional,
digamos assim, e nesses casos o SGBD já tem milhares de coisas prontas pra
facilitar a nossa vida.

at,
Felipe Cruz



Em 26 de junho de 2010 02:47, "Cláudio Pires (Yahoo)" <
[hidden email]> escreveu:

>
>
> Pessoal, estou iniciando em Python e gostaria de alguns conselhos para
> persistir objetos (de um pequeno sistema comercial, como por exemplo,
> controle de estoque) em um banco de dados.
>
> Sei que o melhor seria a utilização de um banco 100% OO, e que em um
> SGBDR clássico teremos sempre o mapeamento Objeto-Tabela para nos
> preocuparmos.....
> Minha questão é: Há alguma vantagem em se utilizar um banco
> objeto-relacional (como o PostgreSQL)? Isso pode poupar algum trabalho
> de codificação ou aumentar a performance no acesso gravação de dados?
>
> Para essas aplicações comerciais que precisam persistir dados, como a
> comunidade esta "se virando"? (que mecanismo de persistência tem sido
> utilizado?)
>
> Antecipadamente, obrigado a todos pela ajuda :)
>
>  
>


[As partes desta mensagem que não continham texto foram removidas]



------------------------------------

,-----------------------------------------------------------.
| 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

<*> Para visitar o site do seu grupo na web, acesse:
    http://br.groups.yahoo.com/group/python-brasil/

<*> Para sair deste grupo, envie um e-mail para:
    [hidden email]

<*> O uso que você faz do Yahoo! Grupos está sujeito aos:
    http://br.yahoo.com/info/utos.html


Reply | Threaded
Open this post in threaded view
|

Re: Persistência de objetos

Luciano Ramalho
ATENÇÃO: mensagem de conteúdo filosófico

Muitos aqui sabem que eu trabalhei com Zope por muitos anos, desde
1998. Tive até uma empresa especializada nisso. Uma das questões que
me atraiu para o Zope foi o ZODB. Eu sempre achei o modelo relacional
muito desengonçado para armazenar objetos, no sentido "Orientação a
Objetos" do termo (objeto é uma das palavras mais abusadas da
computação).

Em 2002, o Leo Rochael e eu inclusive fizemos uma apresentação na
O'Reilly Open Source convention narrando um caso de sucesso de
migração de Oracle para ZODB. O resumo e os slides estão disponíveis
[1]

[1] http://conferences.oreillynet.com/cs/os2002/view/e_sess/2700

Só que o ZODB, como todo banco OO que eu já estudei, tem um problema
sério: ele amarra os dados à aplicação de uma forma muito rígida. Em
particular, o ZODB armazena objetos serializados, mas não armazena as
classes. Cada objeto é serializado com uma referência que aponta para
a sua classe, mas a classe não fica no banco, fica na aplicação. Ao
desserializar, a classe tem que estar presente, se não, nada feito. Em
outras palavras, um arquivo de dados do ZODB é totalmente inútil sem a
aplicação que serviu para criar os objetos que estão lá dentro.

Acontece que os dados sempre valem mais do que a aplicação, eles são a
razão de existir da aplicação.

Então não faz sentido que a indisponibilidade da aplicação, por
qualquer motivo (técnico, comercial, político...) implique na
indisponibilidade dos dados. Esta consideração é um dos principais
motivos para optar por um BD relacional, em vez de um DBOO. E
consequentemente, pagar o alto preço de persistir objetos
esquartejados em uma base relacional normalizada.

Mas existe um caminho do meio. São os bancos de dados
semi-estruturados, uma das categorias de "NoSQL", melhor representados
pelo CouchDB e pelo MongoDB.

Nesses bancos de dados semi-estruturados o que a gente armazena e
recupera não são "objetos" no sentido de Java ou Python, e nem algo
tão complicado como XML, mas apenas estruturas aninhadas de
dicionários, listas e alguns tipos primitivos. Na prática, algo como
JSON.

Isso significa que os dados são completamente independentes de
aplicação e até de linguagem de programação, mas pelo menos eles podem
ter uma topologia parecida com a topologia dos objetos, e não uma
topologia completamente diferente devido às restrições da
normalização.

É por isso que eu estou convicto que a melhor maneira, hoje, de
persistir objetos é usar um banco de dados semi-estruturado. É mais
interoperável que um BDOO, e mais conveniente que um BD relacional.

[ ]s
Luciano
Reply | Threaded
Open this post in threaded view
|

Re: Persistência de objetos

Osvaldo Santana Neto-2
Oi Luciano,

2010/6/30 Luciano Ramalho <[hidden email]>:
> ATENÇÃO: mensagem de conteúdo filosófico
[corta]

> Só que o ZODB, como todo banco OO que eu já estudei, tem um problema
> sério: ele amarra os dados à aplicação de uma forma muito rígida. Em
> particular, o ZODB armazena objetos serializados, mas não armazena as
> classes. Cada objeto é serializado com uma referência que aponta para
> a sua classe, mas a classe não fica no banco, fica na aplicação. Ao
> desserializar, a classe tem que estar presente, se não, nada feito. Em
> outras palavras, um arquivo de dados do ZODB é totalmente inútil sem a
> aplicação que serviu para criar os objetos que estão lá dentro.
>
> Acontece que os dados sempre valem mais do que a aplicação, eles são a
> razão de existir da aplicação.
>
> Então não faz sentido que a indisponibilidade da aplicação, por
> qualquer motivo (técnico, comercial, político...) implique na
> indisponibilidade dos dados. Esta consideração é um dos principais
> motivos para optar por um BD relacional, em vez de um DBOO. E
> consequentemente, pagar o alto preço de persistir objetos
> esquartejados em uma base relacional normalizada.

É importante ter em mente isso que o Luciano está dizendo. Apesar de
não ter dito isso no meu e-mail anterior nós consideramos esses
aspectos antes de adotar o ZODB para desenvolver o produto sobre o
qual havia comentado.

A nossa aplicação é Web. Ela roda num cenário onde a aplicação *e*
o banco de dados estará sempre disponível.

Mesmo assim estamos tomando cuidados para trabalhar apenas com a
serialização de objetos nativos do Python (dict, str, etc) ou
derivações deles que podem ser recuperados por classes "burras"
(apenas a derivação sem a implementação).

Nós também nos esforçamos para não acoplar nosso sistema demais ao
ZODB para que, futuramente, a gente possa migrar facilmente para
outra alternativa caso essa deixe de nos atender satisfatoriamente.

Mas vocês devem estar se perguntando: porque ele escolheu ZODB se
pra isso ele está tendo que tomar todas essas precauções? Porque
não optou logo por um MongoDB ou por um CouchDB?

Medo. Não vão muito longe as histórias de bases de dados CouchDB
"corrompidas". A base instalada de ZODBs (principalmente em portais
Zope/Plone) é absurdamente maior que a quantidade de bases instaladas
com alternativas mais "novas".

A quantidade de problemas conhecidos e resolvidos em bases ZODB é
gigante.

Outro fator (pessoal) para a escolha: eu odeio trabalhar com software
que eu não possa ou não saiba consertar. Eu sou um ótimo programador
Python e um programador C++ medíocre. Com Erlang eu não sei fazer nem
"Hello World". Me sinto muito mais confortável com o ZODB escrito
majoritariamente em Python (com pitadas em C) do que com as alternativas
escritas em Klingon.

Valeu,
Osvaldo

--
Curso de Desenvolvimento Web com Python e Django — R$200,00 (12xR$19,00)
http://www.ludeos.com.br/s/triveos-cursos-online

--
Osvaldo Santana Neto -- Triveos Tecnologia
Cel.: +55 41 9244 1646
Reply | Threaded
Open this post in threaded view
|

Re: Persistência de objetos

Felipe Cruz
In reply to this post by Luciano Ramalho
>
> Acontece que os dados sempre valem mais do que a aplicação, eles são a
> razão de existir da aplicação.
>
> Sempre? Em um jogo, a aplicação vale muito mais que os dados (uma campanha
salva). Eu não acho que exista algo mais importente. Talvez em sistemas de
informação os dados sejam mais valiosos mas não vale pra todos os softwares
que usam persistencia.


> Então não faz sentido que a indisponibilidade da aplicação, por
> qualquer motivo (técnico, comercial, político...) implique na
> indisponibilidade dos dados. Esta consideração é um dos principais
> motivos para optar por um BD relacional, em vez de um DBOO. E
> consequentemente, pagar o alto preço de persistir objetos
> esquartejados em uma base relacional normalizada.
>
> Mas existe um caminho do meio. São os bancos de dados
> semi-estruturados, uma das categorias de "NoSQL", melhor representados
> pelo CouchDB e pelo MongoDB.
>
> Nesses bancos de dados semi-estruturados o que a gente armazena e
> recupera não são "objetos" no sentido de Java ou Python, e nem algo
> tão complicado como XML, mas apenas estruturas aninhadas de
> dicionários, listas e alguns tipos primitivos. Na prática, algo como
> JSON.
>
> Isso significa que os dados são completamente independentes de
> aplicação e até de linguagem de programação, mas pelo menos eles podem
> ter uma topologia parecida com a topologia dos objetos, e não uma
> topologia completamente diferente devido às restrições da
> normalização.
>
> É por isso que eu estou convicto que a melhor maneira, hoje, de
> persistir objetos é usar um banco de dados semi-estruturado. É mais
> interoperável que um BDOO, e mais conveniente que um BD relacional.
>

Fugindo um pouco do topico inicial...

Eu sempre levanto um questionamento a respeito disso, que é o real ganho do
uso de um dispositivo de persistência separado da aplicação.

Existem muitas aplicações onde isso não é necessário. Jogos, aplicações
desktop e até aplicações web.

Hoje eu só uso um BD relacional por requisitos de cliente. Sobre os NoSQL eu
acho que vale a pena avaliar as várias soluções que existem porque cada uma
tem suas vantagens e desvantagens.

Outro ponto a se pensar, é que a aparente interoperabilidade entre
linguagens não é um mar de rosas. É muito mais fácil migrar do mysql pro
oracle ou postgre do que migrar os dados do couchdb pro redis ou cassandra
por exemplo.

Então como sempre.. o nosso trabalho é avaliar isso tudo.

at,
Felipe Cruz

at,
Felipe Cruz


[As partes desta mensagem que não continham texto foram removidas]

Reply | Threaded
Open this post in threaded view
|

Re: Persistência de objetos

Carlos Ribeiro
In reply to this post by Luciano Ramalho
2010/6/30 Luciano Ramalho <[hidden email]>

> ATENÇÃO: mensagem de conteúdo filosófico
>
> Muitos aqui sabem que eu trabalhei com Zope por muitos anos, desde
> 1998. Tive até uma empresa especializada nisso. Uma das questões que
> me atraiu para o Zope foi o ZODB. Eu sempre achei o modelo relacional
> muito desengonçado para armazenar objetos, no sentido "Orientação a
> Objetos" do termo (objeto é uma das palavras mais abusadas da
> computação).
>
> Em 2002, o Leo Rochael e eu inclusive fizemos uma apresentação na
> O'Reilly Open Source convention narrando um caso de sucesso de
> migração de Oracle para ZODB. O resumo e os slides estão disponíveis
> [1]
>
> [1] http://conferences.oreillynet.com/cs/os2002/view/e_sess/2700
>
> Só que o ZODB, como todo banco OO que eu já estudei, tem um problema
> sério: ele amarra os dados à aplicação de uma forma muito rígida. Em
> particular, o ZODB armazena objetos serializados, mas não armazena as
> classes. Cada objeto é serializado com uma referência que aponta para
> a sua classe, mas a classe não fica no banco, fica na aplicação. Ao
> desserializar, a classe tem que estar presente, se não, nada feito. Em
> outras palavras, um arquivo de dados do ZODB é totalmente inútil sem a
> aplicação que serviu para criar os objetos que estão lá dentro.
>

Além disso tem o problema das versões e migrações, que são um problema a ser
tratado em qualquer um desses ambientes.


> Acontece que os dados sempre valem mais do que a aplicação, eles são a
> razão de existir da aplicação.
>

Concordo 100%! Aliás esse é o mote do data portability e de toda briga com
formatos fechados como o padrão MS Office. Tem também o problema do dead
media (vc tem um backup mas não tem como ler). E é uma das razões do apelo
de formatos baseados em texto (se possível ASCII) comum.


> Então não faz sentido que a indisponibilidade da aplicação, por
> qualquer motivo (técnico, comercial, político...) implique na
> indisponibilidade dos dados. Esta consideração é um dos principais
> motivos para optar por um BD relacional, em vez de um DBOO. E
> consequentemente, pagar o alto preço de persistir objetos
> esquartejados em uma base relacional normalizada.
>
> Mas existe um caminho do meio. São os bancos de dados
> semi-estruturados, uma das categorias de "NoSQL", melhor representados
> pelo CouchDB e pelo MongoDB.
>
> Nesses bancos de dados semi-estruturados o que a gente armazena e
> recupera não são "objetos" no sentido de Java ou Python, e nem algo
> tão complicado como XML, mas apenas estruturas aninhadas de
> dicionários, listas e alguns tipos primitivos. Na prática, algo como
> JSON.
>
> Isso significa que os dados são completamente independentes de
> aplicação e até de linguagem de programação, mas pelo menos eles podem
> ter uma topologia parecida com a topologia dos objetos, e não uma
> topologia completamente diferente devido às restrições da
> normalização.
>
> É por isso que eu estou convicto que a melhor maneira, hoje, de
> persistir objetos é usar um banco de dados semi-estruturado. É mais
> interoperável que um BDOO, e mais conveniente que um BD relacional.
>

Apesar de concordar em 90% do que foi dito, é preciso ponderar sobre o
significado de "conveniente". BDs relacionais são extremamente convenientes
sob vários aspectos, como geração de relatórios e geração de consultas
customizadas.

Eu ainda sou do tempo em que se fazia relatório com arquivos "flat file",
estilo Unix (texto livre) ou COBOL (estruturado com colunas fixas; na
verdade eu nunca mexi com COBOL mas lembro como era). Até hoje é comum
processar logs dessa forma, o que prova que "conveniência" é algo
extremamente relativo :-)

Detalhes à parte, concordo que é legal pensar em em bancos de dados
semi-estruturados como sendo uma solução de armazenamento independente da
aplicação. O "gancho" que liga os dois é o conceito de "key/value", que
permite reunir dados esparsos ou referenciá-los diretamente, independente da
estrutura da linguagem utilizada. Ainda tem muita coisa para se evoluir
neste sentido, porque a solução final não oferece ainda a mesma
"conveniência" (leia-se consultas e relatórios) do SQL, e nem é tão bem
"amarradinha" na aplicação como um banco de dados OO puro pode ser.

--
Carlos Ribeiro
Consultoria em Projetos
twitter: http://twitter.com/carribeiro
blog: http://rascunhosrotos.blogspot.com
mail: [hidden email]


[As partes desta mensagem que não continham texto foram removidas]

Reply | Threaded
Open this post in threaded view
|

Re: Persistência de objetos

Osvaldo Santana Neto-2
Oi Carlos,

2010/6/30 Carlos Ribeiro <[hidden email]>:
> 2010/6/30 Luciano Ramalho <[hidden email]>
[corta]
> Detalhes à parte, concordo que é legal pensar em em bancos de dados
> semi-estruturados como sendo uma solução de armazenamento independente da
> aplicação. O "gancho" que liga os dois é o conceito de "key/value", que
> permite reunir dados esparsos ou referenciá-los diretamente, independente da
> estrutura da linguagem utilizada. Ainda tem muita coisa para se evoluir
> neste sentido, porque a solução final não oferece ainda a mesma
> "conveniência" (leia-se consultas e relatórios) do SQL, e nem é tão bem
> "amarradinha" na aplicação como um banco de dados OO puro pode ser.

Só pra discordar um pouco de você aqui...

Algumas alternativas NoSQL oferecem serviços de consulta sim. O MongoDB
tem uma "query language"[1] e o CouchDB oferece um mecanismo de busca
extremamente poderoso (baseado em MapReduce) para criação de consultas
também.

Lembro de ter visto outros que também implementavam linguagens/sistemas
de consulta também.

Valeu,
Osvaldo

[1] http://www.mongodb.org/display/DOCS/Mongo+Query+Language

--
Curso de Desenvolvimento Web com Python e Django — R$200,00 (12xR$19,00)
http://www.ludeos.com.br/s/triveos-cursos-online

--
Osvaldo Santana Neto -- Triveos Tecnologia
Cel.: +55 41 9244 1646
Reply | Threaded
Open this post in threaded view
|

Re: Persistência de objetos

Paulo Eduardo Neves-3
Em 30 de junho de 2010 17:08, Osvaldo Santana <[hidden email]> escreveu:
>
> Algumas alternativas NoSQL oferecem serviços de consulta sim. O MongoDB
> tem uma "query language"[1] e o CouchDB oferece um mecanismo de busca
> extremamente poderoso (baseado em MapReduce) para criação de consultas
> também.

Sem dúvida que existem, mas nenhuma destas linguagens são tão maduras
e conhecidas quanto o SQL. Jogar fora a possibilidade de fazer
consultas eventuais para investigar seus dados é um importante motivo
para se pensar duas vezes antes de abandonar o BDs relacionais. Sem
contar as inúmeras soluções já conhecidas de migração de dados,
backup, segurança, replicação etc. e tal.

Mas o que eu queria contribuir mesmo para a discussão é lembrar que
outra das grandes vantagens dos BDs tradicionais são as Constraints.
Concordando que os dados são mais importantes que a plicação, elas
garantem que você está com seus dados consistentes. Acho até que
poderiam ser mais utilizadas, mas só o feijão-com-arroz de NOT NULL,
chaves estrangeiras e UNIQUE já são uma mão na roda e impedem vários
erros de programação.

Claro que os NoSQL têm seu valor, mas é preciso evitar cair no hype.
Um computador merreca de hoje pode ter sozinho um banco de dados,
servidor web e servidor de aplicações e atender dezenas de milhares de
usuários.

[]s
--
Paulo Eduardo Neves
http://www.mosquito.pro.br
Reply | Threaded
Open this post in threaded view
|

Re: Persistência de objetos

Luciano Ramalho
In reply to this post by Felipe Cruz
2010/6/30 Felipe Cruz <[hidden email]>:
>>
>> Acontece que os dados sempre valem mais do que a aplicação, eles são a
>> razão de existir da aplicação.
>>
>> Sempre? Em um jogo, a aplicação vale muito mais que os dados (uma campanha
> salva). Eu não acho que exista algo mais importente. Talvez em sistemas de
> informação os dados sejam mais valiosos mas não vale pra todos os softwares
> que usam persistencia.

Eu estava pensando em sistemas de informação. Acho que todo mundo
estava, até você sacar os jogos da cartola, Felipe ;-).

> Fugindo um pouco do topico inicial...
>
> Eu sempre levanto um questionamento a respeito disso, que é o real ganho do
> uso de um dispositivo de persistência separado da aplicação.
>
> Existem muitas aplicações onde isso não é necessário. Jogos, aplicações
> desktop e até aplicações web.

Eu concordo que existem muitos casos em que o melhor mecanismo de
persistência é um grafo de objetos serializado e gravado em disco.
Algo que em Python fazemos em uma linha, com uma chamada de
pickle.dump.

> Hoje eu só uso um BD relacional por requisitos de cliente. Sobre os NoSQL eu
> acho que vale a pena avaliar as várias soluções que existem porque cada uma
> tem suas vantagens e desvantagens.

Sim, eu estou ensaiando uma palestra sobre isso. NoSQL é um termo tão
amplo que abarca key-value stores, bancos de grafos, bancos de
documentos, bicicletas, estrelas cadentes, atuns e muito mais. Quase
tudo no universo é NoSQL!

A minha perspectiva é a do desenvolvedor que está preocupado em ter
uma forma confortável e interoperável de armazenar e recuperar dados
de um modelo de dados orientado a objetos. No largo espectro de opções
NoSQL, as que melhor atendem estes requisitos, na minha opinão, são os
bancos semi-estruturados melhor representados hoje pelo MongoDB e pelo
CouchDB, que suportam um modelo de dados mais simples que um graph
database e mais rico que um key-value (onde basicamente o modelo é: me
dá uma chave que eu te devolvo um blob).

> Outro ponto a se pensar, é que a aparente interoperabilidade entre
> linguagens não é um mar de rosas. É muito mais fácil migrar do mysql pro
> oracle ou postgre do que migrar os dados do couchdb pro redis ou cassandra
> por exemplo.

Não entendi o que isso tem a ver com interoperabilidade entre
linguagens. O meu ponto é que é muito mais fácil fazer uma aplicação
Ruby acessar um CouchDB cujos dados foram criados por uma aplicação
Python do que fazer uma aplicação Ruby recuperar dados de um ZODB.

> Então como sempre.. o nosso trabalho é avaliar isso tudo.

Só.

[ ]s
Luciano
Reply | Threaded
Open this post in threaded view
|

Re: Persistência de objetos

Felipe Cruz
Em 30 de junho de 2010 19:10, Luciano Ramalho <[hidden email]> escreveu:

>
>
> 2010/6/30 Felipe Cruz <[hidden email] <felipecruz%40loogica.net>>:
>
> >>
> >> Acontece que os dados sempre valem mais do que a aplicação, eles são a
> >> razão de existir da aplicação.
> >>
> >> Sempre? Em um jogo, a aplicação vale muito mais que os dados (uma
> campanha
> > salva). Eu não acho que exista algo mais importente. Talvez em sistemas
> de
> > informação os dados sejam mais valiosos mas não vale pra todos os
> softwares
> > que usam persistencia.
>
> Eu estava pensando em sistemas de informação. Acho que todo mundo
> estava, até você sacar os jogos da cartola, Felipe ;-).
>

Mesmo em sistemas de informação, nem sempre o dado é o motivo da aplicação
existir. Acredito que não possa ser feita a afirmação de que em *todas* as
aplicações (do tipo sistemas de informação) os dados são mais importantes.

Apenas isso..




>
>
> > Fugindo um pouco do topico inicial...
> >
> > Eu sempre levanto um questionamento a respeito disso, que é o real ganho
> do
> > uso de um dispositivo de persistência separado da aplicação.
> >
> > Existem muitas aplicações onde isso não é necessário. Jogos, aplicações
> > desktop e até aplicações web.
>
> Eu concordo que existem muitos casos em que o melhor mecanismo de
> persistência é um grafo de objetos serializado e gravado em disco.
> Algo que em Python fazemos em uma linha, com uma chamada de
> pickle.dump.
>

Perfeito.. a questão é mostrar pras pessoas que isso não é feio.. pelo
contrario.
É simples e muito poderoso.


>
>
> > Hoje eu só uso um BD relacional por requisitos de cliente. Sobre os NoSQL
> eu
> > acho que vale a pena avaliar as várias soluções que existem porque cada
> uma
> > tem suas vantagens e desvantagens.
>
> Sim, eu estou ensaiando uma palestra sobre isso. NoSQL é um termo tão
> amplo que abarca key-value stores, bancos de grafos, bancos de
> documentos, bicicletas, estrelas cadentes, atuns e muito mais. Quase
> tudo no universo é NoSQL!
>
> A minha perspectiva é a do desenvolvedor que está preocupado em ter
> uma forma confortável e interoperável de armazenar e recuperar dados
> de um modelo de dados orientado a objetos. No largo espectro de opções
> NoSQL, as que melhor atendem estes requisitos, na minha opinão, são os
> bancos semi-estruturados melhor representados hoje pelo MongoDB e pelo
> CouchDB, que suportam um modelo de dados mais simples que um graph
> database e mais rico que um key-value (onde basicamente o modelo é: me
> dá uma chave que eu te devolvo um blob).
>

Concordo com o seu argumento, mas ainda existe um GAP. Documentos são
diferentes
de objetos.

Sobre a chave -> blob, o pessoal do friendfeed fez isso com o mysql:
http://bret.appspot.com/entry/how-friendfeed-uses-mysql

Pra enriquecer sua apresentação, veja o redis. Voce pode usar glob para
consultar chaves do tipo

GET user:*

E ele retorna user:1 -> XXXX user:2 XXXX e por ai vai



> > Outro ponto a se pensar, é que a aparente interoperabilidade entre
> > linguagens não é um mar de rosas. É muito mais fácil migrar do mysql pro
> > oracle ou postgre do que migrar os dados do couchdb pro redis ou
> cassandra
> > por exemplo.
>
> Não entendi o que isso tem a ver com interoperabilidade entre
> linguagens. O meu ponto é que é muito mais fácil fazer uma aplicação
> Ruby acessar um CouchDB cujos dados foram criados por uma aplicação
> Python do que fazer uma aplicação Ruby recuperar dados de um ZODB.
>
>
Me expressei mal.. A questão é que se voce hoje usa o couchdb.. voce fica
preso a ele.
Ao ponto de que bancos SQL são mais facilmente portaveis entre si.

E cuidado com o couchdb especialmente porque ele diz que é distribuído mas
não é!



> > Então como sempre.. o nosso trabalho é avaliar isso tudo.
>
> Só.
>
> [ ]s
> Luciano
>
>  
>


[As partes desta mensagem que não continham texto foram removidas]



------------------------------------

,-----------------------------------------------------------.
| 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

<*> Para visitar o site do seu grupo na web, acesse:
    http://br.groups.yahoo.com/group/python-brasil/

<*> Para sair deste grupo, envie um e-mail para:
    [hidden email]

<*> O uso que você faz do Yahoo! Grupos está sujeito aos:
    http://br.yahoo.com/info/utos.html


Reply | Threaded
Open this post in threaded view
|

Re: Persistência de objetos

Alberto Fabiano-2
In reply to this post by Osvaldo Santana Neto-2
2010/6/29 Osvaldo Santana <[hidden email]>

>
>
>
>  <snip>

> Minha questão é: Há alguma vantagem em se utilizar um banco
> > objeto-relacional (como o PostgreSQL)? Isso pode poupar algum trabalho
> > de codificação ou aumentar a performance no acesso gravação de dados?
>
> O mundo dos bancos de dados estão passando por um processo bastante
> "barulhento" mais recentemente com o lançamento de vários sistemas
> denominados "NoSQL".
>
> Anda bem "perigoso" e complicado escolher como e onde persistir seus dados
> porque existem um sem número de alternativas voltadas para resolver
> determinados
> tipos de problemas ao custo de uma ou outra característica.
>
>
<OFF TOPIC>

    Vulgarizando, assim como o próprio termo o faz, muito do que hoje se
chama de forma desengonçada de NoSQL é o que já  { fazíamos | fazemos }  com
nossos hashtables servers, nos divertindo implementando hopscotch e/ou
cuchoo hashing entre outros arranjos de otimização, sofisticação ou
simplesmente utilizando algum esquema de hash_map.

   Aliás, esta é uma piada que só tem graça para quem já passou pela
situação, mas ela é a seguinte:

    P: "O que um desenvolvedor que usa hashtables faz quando alguém diz que
ele precisa armazenar seus dados num SGBD?"
    R: "Propõe-se desenvolver um servidor de hashtables"

   Quando li o primeiro artigo sobre  NoSQL, na mesma hora lembrei desta
*piada*; pois logo pensei que se tratava de arquiteturas de hash tables
persistentes e/ou distribuídos, entre outras coisas (obviamente). Aém de ter
ficado com a mesma sensação de quando, na década de 90, eu entendi
*finalmente* o que era o os Component Object Model, sim o tal do COM! Pois
eu lia, lia, lia e não entendia! Porém  lá estava eu a utilizar vtables
"alucinadamente"...  quando entendi que o tal do COM era um esquema padrão
de layout para se utilizar vtables na memória, assim como um padrão de
chamadas para invocá-las, na mesma hora eu pensei: porque este bando de
caras que escreveram este "monte" de artigos não escreveram isto antes? E
juro que certa vez peguei um artigo que falava deste "catso" de COM e em
momento algum havia algum havia esta definição, vtable nem constava no
índice!

   Então, vejo artigos falando de NoSQL (não são todos obviamente) que em
nenhum momento eles citam que estes são esquemas de hash tables
persistentes,  hash tables distribuídos ou algo do gênero (tsc)

   Bom, sei lá...

</OFF TOPIC>

[]s++;

A.F.


[As partes desta mensagem que não continham texto foram removidas]

Reply | Threaded
Open this post in threaded view
|

Re: Persistência de objetos

Felipe Cruz
São várias questões..

Talvez uma bem comum seja o marketing. Voce pode dizer que seu projeto é um
hash distribuido ou dizer que ele
é um banco nao relacional NoSQL schemaless distribuido chave-valor tabajara
etc e tal..

Software é como música nesse sentido. Nem sempre a música que toca no rádio
é a melhor.. assim como nem
sempre o software mais famoso é o melhor.. mas quem ganha dinehrio é quem
fez o famoso e nao quem fez o melhor
que 10 pessoas usam.




Em 30 de junho de 2010 20:14, Alberto Fabiano <[hidden email]>escreveu:

>
>
> 2010/6/29 Osvaldo Santana <[hidden email] <osantana%40triveos.com>>
>
> >
> >
> >
> > <snip>
>
>
> > Minha questão é: Há alguma vantagem em se utilizar um banco
> > > objeto-relacional (como o PostgreSQL)? Isso pode poupar algum trabalho
> > > de codificação ou aumentar a performance no acesso gravação de dados?
> >
> > O mundo dos bancos de dados estão passando por um processo bastante
> > "barulhento" mais recentemente com o lançamento de vários sistemas
> > denominados "NoSQL".
> >
> > Anda bem "perigoso" e complicado escolher como e onde persistir seus
> dados
> > porque existem um sem número de alternativas voltadas para resolver
> > determinados
> > tipos de problemas ao custo de uma ou outra característica.
> >
> >
> <OFF TOPIC>
>
> Vulgarizando, assim como o próprio termo o faz, muito do que hoje se
> chama de forma desengonçada de NoSQL é o que já { fazíamos | fazemos } com
> nossos hashtables servers, nos divertindo implementando hopscotch e/ou
> cuchoo hashing entre outros arranjos de otimização, sofisticação ou
> simplesmente utilizando algum esquema de hash_map.
>
> Aliás, esta é uma piada que só tem graça para quem já passou pela
> situação, mas ela é a seguinte:
>
> P: "O que um desenvolvedor que usa hashtables faz quando alguém diz que
> ele precisa armazenar seus dados num SGBD?"
> R: "Propõe-se desenvolver um servidor de hashtables"
>
> Quando li o primeiro artigo sobre NoSQL, na mesma hora lembrei desta
> *piada*; pois logo pensei que se tratava de arquiteturas de hash tables
> persistentes e/ou distribuídos, entre outras coisas (obviamente). Aém de
> ter
> ficado com a mesma sensação de quando, na década de 90, eu entendi
> *finalmente* o que era o os Component Object Model, sim o tal do COM! Pois
> eu lia, lia, lia e não entendia! Porém lá estava eu a utilizar vtables
> "alucinadamente"... quando entendi que o tal do COM era um esquema padrão
> de layout para se utilizar vtables na memória, assim como um padrão de
> chamadas para invocá-las, na mesma hora eu pensei: porque este bando de
> caras que escreveram este "monte" de artigos não escreveram isto antes? E
> juro que certa vez peguei um artigo que falava deste "catso" de COM e em
> momento algum havia algum havia esta definição, vtable nem constava no
> índice!
>
> Então, vejo artigos falando de NoSQL (não são todos obviamente) que em
> nenhum momento eles citam que estes são esquemas de hash tables
> persistentes, hash tables distribuídos ou algo do gênero (tsc)
>
> Bom, sei lá...
>
> </OFF TOPIC>
>
> []s++;
>
> A.F.
>
>
> [As partes desta mensagem que não continham texto foram removidas]
>
>  
>


[As partes desta mensagem que não continham texto foram removidas]



------------------------------------

,-----------------------------------------------------------.
| 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

<*> Para visitar o site do seu grupo na web, acesse:
    http://br.groups.yahoo.com/group/python-brasil/

<*> Para sair deste grupo, envie um e-mail para:
    [hidden email]

<*> O uso que você faz do Yahoo! Grupos está sujeito aos:
    http://br.yahoo.com/info/utos.html


Reply | Threaded
Open this post in threaded view
|

Re: Persistência de objetos

Alberto Fabiano-2
Well...

2010/6/30 Felipe Cruz <[hidden email]>

> São várias questões..
>
> Talvez uma bem comum seja o marketing. Voce pode dizer que seu projeto é um
> hash distribuido ou dizer que ele
> é um banco nao relacional NoSQL schemaless distribuido chave-valor tabajara
> etc e tal..
>
> Software é como música nesse sentido. Nem sempre a música que toca no rádio
> é a melhor.. assim como nem
> sempre o software mais famoso é o melhor.. mas quem ganha dinehrio é quem
> fez o famoso e nao quem fez o melhor
> que 10 pessoas usam.
>
>
>
@Felipe,

Talvez por influência do meu mundinho quântico, esta thread me parece aquele
famoso quadro (que eu gosto muito) do Dalí: "Destroços de um Automóvel Dando
a Luz a um Cavalo Cego Mordendo um Telefone".

A pergunta do @Cláudio é pertinente e no geral o desenvolvimento da thread
pelo @Osvaldo, @Luciano, @Carlos & cia foi legal, mas algumas de suas
nuances me incomodoram. Pois, seguindo a tua linha (me senti até mais
confortável quando vi teus pitacos e os desdobramentos deles) quanto a
*preferência* para mim o mais importante é a *solução computacional*, que
(como exemplo) às vezes não é o sistema de gerenciamento de energia com SGBD
ou um modelo de persistência MRNN, mas simplesmente um conjunto de
dispositivos de automação que controlam a iluminação por temporização,
intensidade e presença, lâmpadas econômicas entre outros dispositivos que em
seu core tem MCUs de 8 bits, que pode gerar dados ou não! Todos tem sua
importância mais seja num jogo, num stack firmware de um radio base band ou
num controle de estoque o mais importante são as soluções computacionais
para as necessidades funcionais. E, para evitar certas armadilhas, a saída é
sempre aplicar a dúvida hiperbólica; é uma velha lição que ganhou várias
técnicas ditas *revolucionárias*, mas é sempre um bom caminho: encontrar a
causa raiz do problema para se oferecer a melhor solução.

Quanto ao sucesso, costumo brincar que ele muitas vezes é proveniente da
densidade de potência irradiada pelo gerador do campo de distorção da
realidade presente no ator e/ou artefato de sucesso, que tem como fonte a
energia escura, sendo área da neurociência e da (bio)física quântica; não do
marketing que é apenas seu manipulador. Afinal como explicar que termos que
descrevem o que são estes modelos de persistência (dito alternativos)
existem a mais de 20 anos, e justamente um que (como o @Luciano já disse)
pode significar qualquer coisa - e quase que inapropriadamente o que ele se
propõe - adquira maior popularidade? E o curioso é que quem figurava como
"alternativo" a algum tempo eram os SGBDs.

Se analisamos com cuidado, vamos perceber que no mínimo a 2 décadas, existem
e são utilizados vários modelos de persistência de dados e agora alguns
estão caindo no mainstream e ficando mais acessíveis através de opções "Open
Source". Como a história da vtable que eu estava comentando, elas já
existiam desde a década de 70 (obviamente ganhando vários aperfeiçoamentos
desde seu surgimento) mas foi com o surgimento do COM em 1993  que o modelo
caiu no mainstream.

O que é mais apropriado? Boa pergunta! Mas uma orientação é que nem tudo é
prego e uma caixa de ferramenta não deve existir apenas um martelo.

Como o @Luciano, eu também prefiro aquilo que eu domino e sei consertar caso
eu, algo ou alguém fizer algum estrago! A 10 anos eu não curtia SGBDs e
SQLs, eu era mais fã de hash tables, mas aprendi a gostar de SGBDs! :-)
Sinceramente? Estou curioso para ver esta palestra do @Luciano,  afinal de
Bóson de Higgs à POP Fields, de rainbow trap à luciferina, tudo é NoSQL! :-P

[]s++;

--
A.F.
"""
 The best way to predict the future is to invent it ,  Alan Key

"""
/*  0x42 0x69 0x74 0x20 0x46 0x61 0x6e  */

>
>
> Em 30 de junho de 2010 20:14, Alberto Fabiano <[hidden email]
> >escreveu:
>
> >
> >
> > 2010/6/29 Osvaldo Santana <[hidden email] <osantana%40triveos.com
> >>
> >
> > >
> > >
> > >
> > > <snip>
> >
> >
> > > Minha questão é: Há alguma vantagem em se utilizar um banco
> > > > objeto-relacional (como o PostgreSQL)? Isso pode poupar algum
> trabalho
> > > > de codificação ou aumentar a performance no acesso gravação de dados?
> > >
> > > O mundo dos bancos de dados estão passando por um processo bastante
> > > "barulhento" mais recentemente com o lançamento de vários sistemas
> > > denominados "NoSQL".
> > >
> > > Anda bem "perigoso" e complicado escolher como e onde persistir seus
> > dados
> > > porque existem um sem número de alternativas voltadas para resolver
> > > determinados
> > > tipos de problemas ao custo de uma ou outra característica.
> > >
> > >
> > <OFF TOPIC>
> >
> > Vulgarizando, assim como o próprio termo o faz, muito do que hoje se
> > chama de forma desengonçada de NoSQL é o que já { fazíamos | fazemos }
> com
> > nossos hashtables servers, nos divertindo implementando hopscotch e/ou
> > cuchoo hashing entre outros arranjos de otimização, sofisticação ou
> > simplesmente utilizando algum esquema de hash_map.
> >
> > Aliás, esta é uma piada que só tem graça para quem já passou pela
> > situação, mas ela é a seguinte:
> >
> > P: "O que um desenvolvedor que usa hashtables faz quando alguém diz que
> > ele precisa armazenar seus dados num SGBD?"
> > R: "Propõe-se desenvolver um servidor de hashtables"
> >
> > Quando li o primeiro artigo sobre NoSQL, na mesma hora lembrei desta
> > *piada*; pois logo pensei que se tratava de arquiteturas de hash tables
> > persistentes e/ou distribuídos, entre outras coisas (obviamente). Aém de
> > ter
> > ficado com a mesma sensação de quando, na década de 90, eu entendi
> > *finalmente* o que era o os Component Object Model, sim o tal do COM!
> Pois
> > eu lia, lia, lia e não entendia! Porém lá estava eu a utilizar vtables
> > "alucinadamente"... quando entendi que o tal do COM era um esquema padrão
> > de layout para se utilizar vtables na memória, assim como um padrão de
> > chamadas para invocá-las, na mesma hora eu pensei: porque este bando de
> > caras que escreveram este "monte" de artigos não escreveram isto antes? E
> > juro que certa vez peguei um artigo que falava deste "catso" de COM e em
> > momento algum havia algum havia esta definição, vtable nem constava no
> > índice!
> >
> > Então, vejo artigos falando de NoSQL (não são todos obviamente) que em
> > nenhum momento eles citam que estes são esquemas de hash tables
> > persistentes, hash tables distribuídos ou algo do gênero (tsc)
> >
> > Bom, sei lá...
> >
> > </OFF TOPIC>
> >
> > []s++;
> >
> > A.F.
> >
> >
> > [As partes desta mensagem que não continham texto foram removidas]
> >
> >
> >
>
>
> [As partes desta mensagem que não continham texto foram removidas]
>
>
>
> ------------------------------------
>
> ,-----------------------------------------------------------.
> | 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
>
>
>


[As partes desta mensagem que não continham texto foram removidas]

Reply | Threaded
Open this post in threaded view
|

Re: Persistência de objetos

Luciano Ramalho
In reply to this post by Felipe Cruz
2010/6/30 Felipe Cruz <[hidden email]>:
> Mesmo em sistemas de informação, nem sempre o dado é o motivo da aplicação
> existir. Acredito que não possa ser feita a afirmação de que em *todas* as
> aplicações (do tipo sistemas de informação) os dados são mais importantes.
>
> Apenas isso..

OK, concordo Felipe. Se isso aqui fosse um artigo acadêmico, pode crer
que eu não teria dito que os dados são *sempre* mais valiosos que a
aplicação. Mas eu encaro essa lista mais como uma conversa de bar, no
melhor sentido, e em conversas de bar a gente exagera um pouco para
dar mais efeito, OK? No bar *sempre* significa *a maioria das vezes* e
*a maioria* significa *alguns*.

Agora, se a gente estivesse num bar de verdade, eu perguntaria, "Ah é,
então me fala um sistema de informação onde o dado não é o motivo dele
existir." Mas temos coisas mais importantes a discutir, então não vou
me prender ainda mais a este detalhe.

>> Eu concordo que existem muitos casos em que o melhor mecanismo de
>> persistência é um grafo de objetos serializado e gravado em disco.
>> Algo que em Python fazemos em uma linha, com uma chamada de
>> pickle.dump.
>>
>
> Perfeito.. a questão é mostrar pras pessoas que isso não é feio.. pelo
> contrario.
> É simples e muito poderoso.

É isso aí!

>
>
>>
>>
>> > Hoje eu só uso um BD relacional por requisitos de cliente. Sobre os NoSQL
>> eu
>> > acho que vale a pena avaliar as várias soluções que existem porque cada
>> uma
>> > tem suas vantagens e desvantagens.
>>
>> Sim, eu estou ensaiando uma palestra sobre isso. NoSQL é um termo tão
>> amplo que abarca key-value stores, bancos de grafos, bancos de
>> documentos, bicicletas, estrelas cadentes, atuns e muito mais. Quase
>> tudo no universo é NoSQL!
>>
>> A minha perspectiva é a do desenvolvedor que está preocupado em ter
>> uma forma confortável e interoperável de armazenar e recuperar dados
>> de um modelo de dados orientado a objetos. No largo espectro de opções
>> NoSQL, as que melhor atendem estes requisitos, na minha opinão, são os
>> bancos semi-estruturados melhor representados hoje pelo MongoDB e pelo
>> CouchDB, que suportam um modelo de dados mais simples que um graph
>> database e mais rico que um key-value (onde basicamente o modelo é: me
>> dá uma chave que eu te devolvo um blob).
>>
>
> Concordo com o seu argumento, mas ainda existe um GAP. Documentos são
> diferentes
> de objetos.

Sem dúvida. Eu não estou afirmando que não existe gap, mas sim que o
gap é muito menor do que o gap do modelo relacional ao OO, o famoso
"impedance mismacth".

E por outro lado, se o gap não existe, então você está lidando com um
BD OO, e aí tem todo aquele acoplamento entre o BD e a aplicação, que
sempre vai existir até que inventem um object model universal aceito
por todos. Mas esperar que isso aconteça é como esperar que alguém
invente uma linguagem de programação universal aceita por todos. (Tem
adeptos de certas linguagens que acreditam que isso já aconteceu ;-).

Então o gap é bem vindo até. Só não precisa ser um abismo tão largo!

>
> Sobre a chave -> blob, o pessoal do friendfeed fez isso com o mysql:
> http://bret.appspot.com/entry/how-friendfeed-uses-mysql

Eu vi, é muito interessante este post. O Osvaldo Santana vive citando ele.

> Pra enriquecer sua apresentação, veja o redis. Voce pode usar glob para
> consultar chaves do tipo
>
> GET user:*
>
> E ele retorna user:1 -> XXXX user:2 XXXX e por ai vai

Isso é bem interessante.

Mas o que eu creio que nenhum key-value faz, por definição, é permitir
consultas por campos além da chave. Porque se permite isso, já não é
mais um mero key-value storage,  confere?


>> Não entendi o que isso tem a ver com interoperabilidade entre
>> linguagens. O meu ponto é que é muito mais fácil fazer uma aplicação
>> Ruby acessar um CouchDB cujos dados foram criados por uma aplicação
>> Python do que fazer uma aplicação Ruby recuperar dados de um ZODB.
>>
>>
> Me expressei mal.. A questão é que se voce hoje usa o couchdb.. voce fica
> preso a ele.

Você fica "preso" ao JSON, um formato de intercâmbio de dados que
todas as linguagens de programação importantes da atualidade conseguem
ler e gravar de forma simples e confiável.

> Ao ponto de que bancos SQL são mais facilmente portaveis entre si.

Poderiam ser muito mais, na verdade. É triste massagear um dump de
MySQL para migrá-lo para PostgreSQL, mesmo supondo que você não vai
mudar a estrutura das tabelas.

Às vezes a forma mais fácil de converter uma massa de dados de um
banco relacional para outro é convertê-la para um formato
intermediário, como JSON ;-). Principalmente se, na hora da conversão,
você pretende mudar a estrutura das tabelas, o que na prática é bem
comum.

Na verdade, é interessante notar que uma das motivações iniciais dos
pesquisadores que formalizaram o modelo de dados semiestruturado era
facilitar a conversão de massas de dados entre sistemas com modelagens
relacionais diferentes. A fonte dessa info é este livro:

http://www.amazon.com/Data-Web-Relations-Semistructured-Management/dp/155860622X

> E cuidado com o couchdb especialmente porque ele diz que é distribuído mas
> não é!

O meu interesse atual no CouchDB é mais acadêmico do que prático. O
CouchDB, com sua API REST,  suporte direto a JSON e interface Web
embutida (Futon) é um exemplo mais claro e didático do que seja um bd
semiestruturado moderno, na minha opinião.

Mas no trabalho, estou mais interessado em usar MongoDB, porque sinto
que ele tem mais adeptos com projetos reais, alguns até quase em
produção, e no Brasil.

>> > Então como sempre.. o nosso trabalho é avaliar isso tudo.

Felipe, muito grato pelo alto nível da discussão!

[ ]s
Luciano
Reply | Threaded
Open this post in threaded view
|

Re: Persistência de objetos

Alberto Fabiano-2
In reply to this post by Alberto Fabiano-2
Olá Pessoal,

Antes de qualquer coisa, realmente, há muitas soluções de modelos de
persistência e sobre o que é melhor é sempre algo muito relativo, pois é a
necessidade de cada sistema que determina - inclusive se é necessário um
modelo de persistência num dado elemento do sistema e quantos ele terá  -
assim como o domínio dos desenvolvedores que dirá qual será o melhor
elemento/servidor/alternativa. Se soluções home made de hash tables, um
servidor SGBD - PosgreSQL - um servidor de filas (do tipo um OpenMQ ou outra
solução bem cara) ou um destes schemaless que estão ganhando popularidade e
credibilidade, isto é sempre algo a se analisar muito bem,  evitar dores de
cabeça é sempre necessário; senão uma arte.


@Felipe, sobre este teu comentário:


> Estou dizendo que realmente, quase ninguem cita. Uma possivel razao, é que
> é necessário fazer marketing para divulgar um projeto. Então no meio de
> varias buzzwords, ou quase, como scalability, schemaless, NoSQL,
> non-relational, key value, document-orientded a questão de que muitos desses
> projetos a grosso modo são hashes distribuidos não fica tão aparente.
>
>
Concordo plenamente, muito bem colocado!  As vezes você fica lá no seu
cantinho programando, e vão surgindo novos produtos - seja closed ou open
source -  e surge um movimento, como o @Osvaldo bem colocou, rebatizando
alguns conceitos que já existiam e que você já sabia e até chamava de outra
forma (talvez até com um nome mais apropriado) e vem um sujeito e diz que o
que você faz na realidade é o XXXX e que o cara que surgiu depois é que é o
inovador. Nestas horas eu só consigo em pensar numa coisa...

<snip>


> Talvez uma bem comum seja o marketing. Voce pode dizer que seu projeto é um
>> hash distribuido ou dizer que ele
>> é um banco nao relacional NoSQL schemaless distribuido chave-valor
>> tabajara
>> etc e tal..
>>
>>
Yep! Independente da técnica, na dose certa, um pouco de *marketing* sempre
faz bem e salva muitas horas de código, noites de sono e know-how adquirido.
Mas isto é literalmente conversa para uma mesa de bar.



> Software é como música nesse sentido. Nem sempre a música que toca no rádio
>> é a melhor.. assim como nem
>> sempre o software mais famoso é o melhor.. mas quem ganha dinehrio é quem
>> fez o famoso e nao quem fez o melhor
>> que 10 pessoas usam.
>>
>>
Eventualmente, o melhor se torna famoso e pode ganhar uma grana suficiente
para o cara viver bem, mas ela não vai ganhar o hype que outros que se
enquadram perfeitamente na colocação que você fez, recebeu.


> > >
>> > > <snip>
>> >
>> >
>> > > Minha questão é: Há alguma vantagem em se utilizar um banco
>> > > > objeto-relacional (como o PostgreSQL)? Isso pode poupar algum
>> trabalho
>> > > > de codificação ou aumentar a performance no acesso gravação de
>> dados?
>> > >
>>
>
A questão de aumentar a performance é sempre muito relativo, para avaliar a
questão da vantagem é sempre necessário considerar o Risco, e este sempre
existirá principalmente porque "o que todos indicam hoje" como a melhor
solução, no futuro pode render grandes dores de cabeça e para que isto possa
ser previsível, as pessoas certas precisam ser ouvidas! Por isto é sempre
bom testar, avaliar, homologar algo antes de considerar para tua solução.

<snip>



> > Mesmo em sistemas de informação, nem sempre o dado é o motivo da
> aplicação
> > existir. Acredito que não possa ser feita a afirmação de que em *todas*
> as
> > aplicações (do tipo sistemas de informação) os dados são mais
> importantes.
> >
> > Apenas isso..
>
> OK, concordo Felipe. Se isso aqui fosse um artigo acadêmico, pode crer
> que eu não teria dito que os dados são *sempre* mais valiosos que a
> aplicação. Mas eu encaro essa lista mais como uma conversa de bar, no
> melhor sentido, e em conversas de bar a gente exagera um pouco para
> dar mais efeito, OK? No bar *sempre* significa *a maioria das vezes* e
> *a maioria* significa *alguns*.
>
> Agora, se a gente estivesse num bar de verdade, eu perguntaria, "Ah é,
> então me fala um sistema de informação onde o dado não é o motivo dele
> existir." Mas temos coisas mais importantes a discutir, então não vou
> me prender ainda mais a este detalhe.
>
>
@Luciano, realmente! O tema é sedutor e tende muito para uma conversa de
bar.



> Na verdade, é interessante notar que uma das motivações iniciais dos
> pesquisadores que formalizaram o modelo de dados semiestruturado era
> facilitar a conversão de massas de dados entre sistemas com modelagens
> relacionais diferentes. A fonte dessa info é este livro:
>
>
> http://www.amazon.com/Data-Web-Relations-Semistructured-Management/dp/155860622X
>
>
Curiosamente, uma das soluções de hash tables distribuída - que participei
no desenvolvimento -  tinha justamente este propósito! Outro caso, era um
modelo que se misturava conceitos entre servidor de filas, gatekeeper de
alta perfomance, entre outras coisas e que precisava de muita perfomance
pois ele poderia ser um grande gargalo num elemento de uma grande
arquitetura de sistemas distribuídos. E tinha um único nome, sinceramente?
Esta experiência me ensinou uma grande lição sobre a importância da
segmentação e sobre aquilo que hoje utilizamos a  buzzword "Arquitetura"
para denominar.


> > E cuidado com o couchdb especialmente porque ele diz que é distribuído
> mas
> > não é!
>
> O meu interesse atual no CouchDB é mais acadêmico do que prático. O
> CouchDB, com sua API REST, suporte direto a JSON e interface Web
> embutida (Futon) é um exemplo mais claro e didático do que seja um bd
> semiestruturado moderno, na minha opinião.
>
> Mas no trabalho, estou mais interessado em usar MongoDB, porque sinto
> que ele tem mais adeptos com projetos reais, alguns até quase em
> produção, e no Brasil.
>
>
É no final, isto acaba tendo enorme importância. Mas por n razões ela foge
do escopo desta thread. /o7


>
> >> > Então como sempre.. o nosso trabalho é avaliar isso tudo.
>
>
@Felipe,

       E dependendo da função no projeto este realmente é "o trabalho". Só
avaliando, muito bem para não cair em certas armadilhas e não ajudar no
desenvolvimento de uma bomba relógio. Numas destas, eu já esvaziei a minha
mesa e fui embora pois não queria participar do conluio. Realmente um dos
nossos trabalhos  "é avaliar isto tudo".



> Felipe, muito grato pelo alto nível da discussão!
>
>
@Luciano, acho que todos estão de parabéns pelo alto nível da discussão,
inclusive o @Felipe que chamou a atenção para alguns pontos bem pertinentes.

[]s++;

A.F.


[As partes desta mensagem que não continham texto foram removidas]

Reply | Threaded
Open this post in threaded view
|

Re: Persistência de objetos

Carlos Ribeiro
In reply to this post by Luciano Ramalho
2010/7/1 Luciano Ramalho <[hidden email]>

> 2010/6/30 Felipe Cruz <[hidden email]>:
> > Mesmo em sistemas de informação, nem sempre o dado é o motivo da
> aplicação
> > existir. Acredito que não possa ser feita a afirmação de que em *todas*
> as
> > aplicações (do tipo sistemas de informação) os dados são mais
> importantes.
> >
> > Apenas isso..
>
> OK, concordo Felipe. Se isso aqui fosse um artigo acadêmico, pode crer
> que eu não teria dito que os dados são *sempre* mais valiosos que a
> aplicação. Mas eu encaro essa lista mais como uma conversa de bar, no
> melhor sentido, e em conversas de bar a gente exagera um pouco para
> dar mais efeito, OK? No bar *sempre* significa *a maioria das vezes* e
> *a maioria* significa *alguns*.
>
> Agora, se a gente estivesse num bar de verdade, eu perguntaria, "Ah é,
> então me fala um sistema de informação onde o dado não é o motivo dele
> existir." Mas temos coisas mais importantes a discutir, então não vou
> me prender ainda mais a este detalhe.
>

Permitam-me uma digressão filosófica, recuando um bocado no tempo.

Aprendi OOP no fim dos anos 80, usando Turbo Pascal 5.0 (ou 5.5). Na época,
o material a respeito (livros e o próprio manual do Turbo Pascal) traziam
uma explicação dos "três princípios básicos" de OOP:

- Encapsulamento: métodos e dados no mesmo objeto.
- Ocultação de informação: "information hiding", ou acesso controlado aos
dados.
- Herança: capacidade de construir novos objetos com base nos objetos
antigos.

(Engraçado que eu procurei agora, na Wikipedia e no C2 Wiki, mas não achei
nada tão categórico. Mas achei uns manuais do TP em PDF :-) De todo modo...)

O tema fundamental na época era justamente a importância de garantir que os
dados seriam interpretados no contexto correto. Foi esse o "mote" de OOP na
época, em comparação com a programação procedural/imperativa. E não é muito
diferente da idéia de estabelecer "constraints" nos bancos de dados.
Constraints são exatamente isso: comportamentos associados à descrição dos
dados, que (de certa forma) satisfazem os princípios de encapsulamento
estabelecidos acima.

De certa forma, o que estamos discutindo e questionando agora é justamente a
importância relativa de dados e código. Em linhas gerais ambos são
igualmente importantes. Dependendo do contexto, o programa rodando pode ser
mais importante (como no caso dos jogos que o Felipe lembrou); neste caso os
dados podem ter valor meramente transitório. Mas assim que se pensa no longo
prazo, o dado assume um papel diferente. Os dados tem (digamos) "valor
arqueológico", muito tempo depois que os sistemas nos quais o programa foi
desenhado para rodar tenham sido descontinuados.

O problema é como criar um tipo de "binding" entre os dados e o código, que
possa ser expresso dentro do código nos termos de OOP, mas que preserve o
potencial de sobrevida a longo prazo dos dados. Na soluções que eu já
estudei, sempre acontece uma entre duas coisas:

1) A solução mantém o binding entre o objeto e os dados persistidos de forma
coesa. Neste caso, os dados tendem a ficar engessados e difíceis de tratar
com ferramentas de consulta genéricas.

2) A solução adota um binding mais "frouxo". Neste caso, os dados são mais
facilmente tratáveis, mas a coesão entre o modelo do objeto e o modelo dos
dados precisa ser implementada pelo programador. Os ORMs comuns atuam desta
forma. Acho que os drivers para novos bancos NoSQL precisam adotar um
mecanismo parecido, que permita explorar suas características próprias;
porém duvido que seja possível adotar uma arquitetura genérica.

Outro aspecto dessa resurgência de interesse em esquemas inovadores de
armazenamento é uma revalorização do antigo estudo de estruturas de dados.
Boa parte dos programadores formados recentemente não tem a menor idéia de
que existem estruturas alternativas, desde hash tables até radix trees. E
esta é uma grande perda, pois fica sempre a sensação de que "se tudo que
você tem é um martelo, qualquer parafuso vira prego". Ou seja: está (quase)
todo mundo martelando parafusos dentro de SGBDs, quando seria mais adequado
tratá-los com a chave de fenda dada uma outra solução.

--
Carlos Ribeiro
Consultoria em Projetos
twitter: http://twitter.com/carribeiro
blog: http://rascunhosrotos.blogspot.com
mail: [hidden email]


[As partes desta mensagem que não continham texto foram removidas]

Reply | Threaded
Open this post in threaded view
|

Re: Persistência de objetos

Felipe Cruz
Espero que não tenha problema em dar continuidade ao off-topic que não é tão
off-topic assim :)

Outro aspecto dessa resurgência de interesse em esquemas inovadores de
armazenamento é uma revalorização do antigo estudo de estruturas de dados.
Boa parte dos programadores formados recentemente não tem a menor idéia de
que existem estruturas alternativas, desde hash tables até radix trees. E
esta é uma grande perda, pois fica sempre a sensação de que "se tudo que
você tem é um martelo, qualquer parafuso vira prego". Ou seja: está (quase)
todo mundo martelando parafusos dentro de SGBDs, quando seria mais adequado
tratá-los com a chave de fenda dada uma outra solução.

Perfeito...

Ai vai mais um projeto pra quem não conhece, o Tokyo cabinet. Ele é bem cru
nessa questão de marketing ou seja, ele diz o que ele é internamente (ele
usa hashes, B-Tree etc..). Perfeito pra quem quer aprender mais a fundo.

No geral, eu me sinto muito confortavel com persistencia OO (real, sem ORM)
desde quando era apenas um javaniano(rs) e mantive isso na meu dia dia com
python implementando um projeto de persistencia OO. Sempre fui muito crítico
com relação a SGBD's pelo motivo que o Carlos citou.. "martelar parafusos"

Pro Luciano, que vai fazer uma palestra sobre NoSQL, tenho uma sugestão. As
palestras atuais são MUITO repetitivas. Tente fugir um pouco dessas
buzzwords, dessas coisas repetidas.. O barato do NoSQL não é só a tecnologia
mas como conseguiu quebrar paradigmas.. Eu fiz especialização em banco de
dados, meu projeto final foi persistencia OO em Java, tenho um projeto de
persistencia OO em python e acompanho vários desses projetos muitos desde o
inicio, quando quase ninguem conhecia. Se quiser sugestoes manda um email..

Em maio do ano passado, o termo NoSQL não existia. Eu escrevi no meu blog
sobre isso e usei o termo SqlFree

http://www.loogica.net/blog/2009/05/09/banco-de-dados-alternativos-sql-free/

at,
Felipe Cruz





Em 1 de julho de 2010 11:03, Carlos Ribeiro <[hidden email]> escreveu:

>
>
> 2010/7/1 Luciano Ramalho <[hidden email] <ramalho%40gmail.com>>
>
>
> > 2010/6/30 Felipe Cruz <[hidden email] <felipecruz%40loogica.net>
> >:
> > > Mesmo em sistemas de informação, nem sempre o dado é o motivo da
> > aplicação
> > > existir. Acredito que não possa ser feita a afirmação de que em *todas*
> > as
> > > aplicações (do tipo sistemas de informação) os dados são mais
> > importantes.
> > >
> > > Apenas isso..
> >
> > OK, concordo Felipe. Se isso aqui fosse um artigo acadêmico, pode crer
> > que eu não teria dito que os dados são *sempre* mais valiosos que a
> > aplicação. Mas eu encaro essa lista mais como uma conversa de bar, no
> > melhor sentido, e em conversas de bar a gente exagera um pouco para
> > dar mais efeito, OK? No bar *sempre* significa *a maioria das vezes* e
> > *a maioria* significa *alguns*.
> >
> > Agora, se a gente estivesse num bar de verdade, eu perguntaria, "Ah é,
> > então me fala um sistema de informação onde o dado não é o motivo dele
> > existir." Mas temos coisas mais importantes a discutir, então não vou
> > me prender ainda mais a este detalhe.
> >
>
> Permitam-me uma digressão filosófica, recuando um bocado no tempo.
>
> Aprendi OOP no fim dos anos 80, usando Turbo Pascal 5.0 (ou 5.5). Na época,
> o material a respeito (livros e o próprio manual do Turbo Pascal) traziam
> uma explicação dos "três princípios básicos" de OOP:
>
> - Encapsulamento: métodos e dados no mesmo objeto.
> - Ocultação de informação: "information hiding", ou acesso controlado aos
> dados.
> - Herança: capacidade de construir novos objetos com base nos objetos
> antigos.
>
> (Engraçado que eu procurei agora, na Wikipedia e no C2 Wiki, mas não achei
> nada tão categórico. Mas achei uns manuais do TP em PDF :-) De todo
> modo...)
>
> O tema fundamental na época era justamente a importância de garantir que os
> dados seriam interpretados no contexto correto. Foi esse o "mote" de OOP na
> época, em comparação com a programação procedural/imperativa. E não é muito
> diferente da idéia de estabelecer "constraints" nos bancos de dados.
> Constraints são exatamente isso: comportamentos associados à descrição dos
> dados, que (de certa forma) satisfazem os princípios de encapsulamento
> estabelecidos acima.
>
> De certa forma, o que estamos discutindo e questionando agora é justamente
> a
> importância relativa de dados e código. Em linhas gerais ambos são
> igualmente importantes. Dependendo do contexto, o programa rodando pode ser
> mais importante (como no caso dos jogos que o Felipe lembrou); neste caso
> os
> dados podem ter valor meramente transitório. Mas assim que se pensa no
> longo
> prazo, o dado assume um papel diferente. Os dados tem (digamos) "valor
> arqueológico", muito tempo depois que os sistemas nos quais o programa foi
> desenhado para rodar tenham sido descontinuados.
>
> O problema é como criar um tipo de "binding" entre os dados e o código, que
> possa ser expresso dentro do código nos termos de OOP, mas que preserve o
> potencial de sobrevida a longo prazo dos dados. Na soluções que eu já
> estudei, sempre acontece uma entre duas coisas:
>
> 1) A solução mantém o binding entre o objeto e os dados persistidos de
> forma
> coesa. Neste caso, os dados tendem a ficar engessados e difíceis de tratar
> com ferramentas de consulta genéricas.
>
> 2) A solução adota um binding mais "frouxo". Neste caso, os dados são mais
> facilmente tratáveis, mas a coesão entre o modelo do objeto e o modelo dos
> dados precisa ser implementada pelo programador. Os ORMs comuns atuam desta
> forma. Acho que os drivers para novos bancos NoSQL precisam adotar um
> mecanismo parecido, que permita explorar suas características próprias;
> porém duvido que seja possível adotar uma arquitetura genérica.
>
> Outro aspecto dessa resurgência de interesse em esquemas inovadores de
> armazenamento é uma revalorização do antigo estudo de estruturas de dados.
> Boa parte dos programadores formados recentemente não tem a menor idéia de
> que existem estruturas alternativas, desde hash tables até radix trees. E
> esta é uma grande perda, pois fica sempre a sensação de que "se tudo que
> você tem é um martelo, qualquer parafuso vira prego". Ou seja: está (quase)
> todo mundo martelando parafusos dentro de SGBDs, quando seria mais adequado
> tratá-los com a chave de fenda dada uma outra solução.
>
>
> --
> Carlos Ribeiro
> Consultoria em Projetos
> twitter: http://twitter.com/carribeiro
> blog: http://rascunhosrotos.blogspot.com
> mail: [hidden email] <carribeiro%40gmail.com>
>
> [As partes desta mensagem que não continham texto foram removidas]
>
>  
>


[As partes desta mensagem que não continham texto foram removidas]



------------------------------------

,-----------------------------------------------------------.
| 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

<*> Para visitar o site do seu grupo na web, acesse:
    http://br.groups.yahoo.com/group/python-brasil/

<*> Para sair deste grupo, envie um e-mail para:
    [hidden email]

<*> O uso que você faz do Yahoo! Grupos está sujeito aos:
    http://br.yahoo.com/info/utos.html