2011/6/29 Flavio Henrique Araque Gurgel <fha...@gmail.com>:
> Esta thread está ficando agradavelmente construtiva!
Ufa! Já estava com medo do Teles pedir para eu baixar a bola…
> E olha que, neste caso, nem estou falando d*o* case do milênio :) Nele
> o banco de dados é praticamente um "saco de dados".
E pensar que tem dinheiro público nisso… privatização já! Se querem
desperdiçar dinheiro, que seja privado… mas, enfim, o setor privado às vezes
me parece estar ainda mais atrasado que o público, no quesito liberdade de
Informática… pelo menos, no caso de empresas estabelecidas ou que não são de
Informática.
> E o SGBD: Cata os dados, valida input, trata strings, verifica
> consistência em todas as tabelas relacionadas, insere cada pedaço do
> formulário em 10 tabelas diferentes, atualiza a tabela de histórico,
> computa sequências, atualiza índices, checa as restrições locais e
> estrangeiras e "comita tudo.
Não parece coisa de clipeiro? Digo, fazendo proceduralmente o que poderia ser
declarativo? Ou entendi errado?
> Agora no duro: se a parte toda de validação de input e tratamento de
> strings fosse na aplicação, a aplicação abrisse uma transação com o
> banco e resolvesse sua vida, o processamento de cada passo no pl/pgsql
> poderia muito bem ser dela, distribuindo bem melhor a carga entre seus
> três servidores.
Mas validação não costuma ser conformidade a tipos de dados e integridade
referencial, pelo menos num sistema bem modelado? Nesse caso, se entendi
direito, o que chamas de validação não tem de ser, em última instância,
garantido pelo SGBD?
Talvez tenhamos, aí, outra limitação tecnológica. O único sistema de
desenvolvimento e execução de programas aplicativos realmente integrado ao
SGBD e ao modelo relacional que conheço é o Alphora Dataphor — que, acho,
infelizmente inda não foi portado nem para Mono, nem sequer para PostgreSQL —,
e ele resolve essa questão exportando, automaticamente, as restrições de
integridade da base para a interface, mesmo que cliente servidor; no caso, o
cliente interpreta (ou compila, sei lá) o mesmo código D (D4) que a base, e é
atualizado automaticamente quando a base muda.
> Vamos então nomear melhor os bois: a regra tem que estar no SGBD sim,
> ok. Restrições, regras e etc. Mas o processamento das informações
> _antes_ de chegar no SGBD, isso não deveria estar com ele. E, neste
> caso, está.
Perfeito.
> O agora Microsoft Skype tem um excelente caso de sucesso justamente
> separando tudo: chamada remota de função com o plproxy é um sucesso.
Sim, mas é um caso bem específico, de quase perversão da base para
escalabilidade extrema.
> E, juro, mandei estudo disso para o cliente. Era só modificar 70
> funções em pl/pgsql e a aplicação toda, mas ia ficar "da hora". O
> custo foi proibitivo e ameaçaram trocar pelo RAC se fossem gastar a
> grana toda :P
De fato, uma das vantagens teóricas do modelo relacional que perdemos por
causa das limitações do SQL, entre outros fatores, é não precisar alterar a
aplicação por mudança no modelo físico…
>> Pois é, mas se considerarmos que todas as regras de negócios devem ser
>> implementadas como restrições, de preferência declarativas, fica
>> contraditório
>> ter isso fora da base, não? Ou minha lógica falhou nalgum ponto que não
>> alcancei?
>
> Como falei acima, tô contigo na questão regra de negócio. O problema é
> o processamento do negócio. IMHO, deve estar fora do SGBD.
Pode me esclarecer o que consideras ‘processamento do negócio’ em
contraposição a ‘regra de negócio’? Talvez eu não tenha entendido direito.
> PostgreSQL é a melhor implementação da ISO, reconhecido e utilizado
> academicamente por isso.
Concordo, só não lembro se já passamos a conformidade do DB2 — que obviamente
não serve para a Academia.
> E olha que a comunidade não tem dinheiro pra ficar comprando norma.
:-)
> Aliás, norma, do jeito como é no nosso mundo, na minha opinião, é só
> um jeito de ganhar dinheiro com patent war.
Concordo — gênero, número & grau. E caso. Não contigo, com a gramática.
> Existem sim. Os integrantes dessas equipes se chamam nerds. E eles
> estão em alta no mercado de trabalho e até na vida afetiva.
Não posso reclamar no afetivo, mas no mercado de trabalho acho que não fui
/nerd/ suficiente, virei burocrata.
> Claro que tem que ter um balanço: nerdice versus praticidade.
> Não acho que o mundo deva ser 100% nerd pra fazer as coisas em TI.
> Ninguém ganharia dinheiro. Eu proponho um balanço: bem feito na
> medida, tem que ser bem feito mas tem que ser prático ou não vai pra
> frente.
Creio que, se todos fizessem bem feito, haveria inda mais dinheiro, que a
demanda reprimida nunca cessa de crescer.
> Vou te contar algo que vai te deixar bem chateado. A maioria das
> aplicações Java EE usando Hibernate, normalmente, são independentes de
> SGBD. Tendo o driver JDBC correto, elas falam o "dialeto" adequado.
Eu sei, mas a que custo? Esse é o ponto. É sempre o uso dum mínimo
denominador comum, por exemplo excluindo absolutamente o uso de tipos de dados
específicos (mais uma vez, esclarecendo, abstratos, definidos pelo usuário &
coisa & tal).
> Mas aí cai na discussão do ORM de novo e tal...
Na verdade, não especificamente. Digo, não tem nada a ver essencialmente com
o famigerado mapeamento objeto‐SQL, mas com a tentativa de abstrair algo que
já é relativamente abstrato (um modelo quase‐relacional, expresso mais ou
menos declarativamente em SQL) nalgo menos abstrato (programação procedural,
que essa oposição entre objeto e procedural não me convenceu ainda).
> Então, onde é que estamos errando: o Hibernate é tão ruim assim?
Também.
> será que as implementações de bancos de dados é que são completamente
> confusas?
'' IS NULL. DATE == DATETIME. CQD.
> Ou as duas alternativas?
Claro.
> Porque é tão difícil levar para o mundo dos objetos o modelo relacional
Absolutamente falso. Leia o Terceiro manifesto. O modelo relacional dispensa
qualquer mapeamento, desde que ele seja entendido corretamente. Recapitulando
outras e longas discussões, o problema com ORM é que, primeiro, SQL não é
relacional e, segundo, o correto é mapear objeto a tipo, não a relação
(tabela, em SQL).
> o modelo objeto-relacional do PostgreSQL?
A última vez que vi, os ‘objetos’ do PostgreSQL só serviam para gambiarrar
partições, todos os outros usos eram contraproducentes e (ou) redundantes.
> Não chega a ser uma antítese, mas é um dificultador enorme.
> Como tudo pode ser reescrito, então, é possível, com muito esforço e
> dinheiro, fazer uma aplicação escalar. E aqui a Oracle e IBM tem posto
> muito muito dinheiro, que a comunidade PostgreSQL está esforçada em
> atingir com os recursos que tem.
Tenho uma tese: se considerar o projeto total — desde requisitos, custo de
saída, qualidade &c —, já atingimos, pelo menos desde a 8.4. O problema, a
meu ver, é meramente a inércia.
Corolário, exercício proposto: não usar o PostgreSQL no setor público,
a partir da versão nove, é inconstitucional.
> Esta discussão dá uma bela palestra!
Se me convenceres, proponho uma para o PgBr. Mas tem de me explicar qual
seria, que estou mais que devagar…
> Sim, e é aí que alguns de nós tem sobrevivido com consultoria:
> entendendo o contexto, conjunto da obra.
Pena que não tive competência para me estabelecer nessa…
> Aguardo sequência sua!
Aviso: já gastei tempo demais escrevendo hoje; agora, só amanhã… o que ficou
engraçado de dizer, mas espero que tenhais entendido.
--
Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org
+55 (11) 9406 7191 ICQ: AIM:GoIM?screenname=61287803
sip:leand...@iptel.org MSNIM:chat?contact=lean...@dutra.fastmail.fm
_______________________________________________
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
