E só complementando : CASO o cenário proposto fosse uma situação aonde o
RDBMS devesse atuar já no front-end por qquer necessidade, imho em termos de
otimização/preparação nós teríamos que :
a) não seria um cenário para RAC, imho, pois as n sessões estariam
interessadas nos mesmos objetos, e provavelmente nos mesmos blocos, aí veríamos
um festival de global cache access e de pinging de blocos entre a máquina aonde
o bloco está e os nós remotos interessados em acessar esse bloco... Muito
melhor, imho, seria colocar o poder computacional representado pelos n nós num
único servidor parrudo
b) logicamente não é viável se ter milhares de sessões dedicadas
permanentemente usadas, então algum tipo de pool de conexão seria inevitável, E
a sessão de database NÃO ficaria alocada o tempo todo para o usuário
c) as transações TERIAM que ser muito curtas, com SQLs e modelo tunados ao
máximo, com SQLs rodando em sub-segundo, opções físicas (como
INITRANS/FREELISTS/opções de storage, etc, etc) muito bem afinadas, NUNCA uma
conversão implícita de datatype, NUNCA um SQL sendo reparseado à toa, com
ARQUIVAMENTO dos dados para evitar piora de tempo de resposta degradado por
crescimento de dados
A nível de database, seriam coisas do tipo que eu focaria num ambiente que
demandasse altíssima performance com o menor tempo de resposta, como é típico
de um sistema que atende à usuários finais diretamente e em grande qtdade de
usuários...
d) embora RAC não seja indicado, com certeza algum tipo de COMUNICAÇÂO entre
servidores vai haver : por exemplo, se não é Exigida a identificação completa
do comprador, não faz sentido algum manter essa informação neste database : o
que a gente quer é ACESSAR os servidores da instituição bancária e/ou do cartão
de crédito (via webservice, certamente) e receber uma RESPOSTA , uma garantia,
um número de confirmação deles, dizendo que o valor em grana necessário foi
autorizado pelo CPF tal no banco tal conta tal
OU seja, é como eu falei, se o sistema é de vendas, o que ele precisa é
recebir os dados do pagamento, quem o faz é alguém DE FORA, especializado
nisso, e assim para muitas outras demandas... É VITAL que o sistema que se está
desenvolvendo para ser de alta-performance seja ESPECIALIZADO, só faça o que
REALMENTE tem que fazer, o que entre outros fatores divide a carga total, sim
???
[]s
Chiappa
--- Em oracle_br@yahoogrupos.com.br, J. Laurindo Chiappa jlchiappa@...
escreveu
Veja bem : é quase que Absolutamente Obrigatório vc usar um banco de dados
(provavelmente um RDBMS, por já ser uma tecnologia madura, previsível e
conhecida) já na entrada de dados e processamento correlato , quando ACID **
TEM ** que ser respeitado (não pode haver NADA de diferença entre o real e o
processado) E se múltiplas transações para a mesma fonte podem acontecer -
pense num sistema bancário, é ABSOLUTAMENTE possível que ao mesmo tempo a
mesma conta em processamento num terminal A seja enquanto isso acessada num
terminal B (pelo segundo titular, pelo cônjuge em conta-conjunta, etc) , é é
INADMISSÍVEL que haja um centavo qualquer de diferença (vc não imagina o Rolo
imenso que algo do tipo causaria), nem que uma transação leia dados
sujos/não efetuados, nem que uma transação qquer seja perdida de qualquer
forma Num caso desses, os RDBMSs (e Oracle em particular) são sim MUITO
PROVÁVEIS de serem usados.
Já no caso de venda de ingressos, pode muito bem ser que NÂO se esteja
usando um RDBMS, pois :
a) o total de ingressos disponíveis é ** CONHECIDO ** a priori (acho que
era de 30 mil, se não me engano, mas é um número CONHECIDO), e a Transação
que representa uma venda é MUITO SIMPLES, é basicamente é DIMINUIR UM desse
total (depois de ter recebido a info de pagamento do site bancário ou onde
for) , e absolutamente NÂO deve haver INSERTs nisso, só atualização desse
total...
b) por definição Não Há uma conta-corrente, um log lógico que deve ser
mantido, ou seja, não há uma INTEGRIDADE complexa de operações que deve ser
mantida (TOTALMENTE ao contrário do caso da aplicação bancária, onde os
débitos e créditos são múltiplos e TEM que baterem absolutamente Certinho)
c) em princípio Não há múltiplas transações, já que cada usuário é
considerado uma venda independente
Então, a integridade em tese pode ser mantida por um lock simples no
recurso (arquivo, tabela, whatever) que representa a quantidade de
ingressos, e como a transação é simpes ao extremo (apenas um UPDATE, uma
alteração no recurso) , uma lógica tão simples não Necessariamente demandaria
um database, ou pelo menos não um database RDBMS full mega-poderoso, sim ??
Os recursos de ACID , de controle de transações múltiplas, de integridade de
dados complexa, etc, etc, de um RDBMS full imho Não Seriam Justificados aqui,
sim ??
Então, é MUITO provável
