• Revista PROGRAMAR: Já está disponível a edição #53 da revista programar. Faz já o download aqui!

djthyrax

Qual a query mais eficiente?

26 mensagens neste tópico

O Nazgulled apareceu há um bocado no #p@p com um problema: ir buscar à tabela wp_term_relationships todos os object_id em que term_taxonomy_id = 10 para depois ir buscar à tabela wp_posts as rows em que o campo ID era = aos object_id que fomos buscar à outra tabela.

Chegámos a estas querys:

SELECT p.*
FROM `wp_posts` AS p,
        `wp_term_relationships` AS tr
WHERE p.ID = tr.object_id AND
        tr.term_taxonomy_id = 10; #by Nazgulled

SELECT * 
FROM wp_posts 
WHERE ID IN (
        SELECT object_id 
        FROM wp_term_relationships 
        WHERE term_taxonomy_id = 10
        ); #by me

E eu levantei a questão da possibilidade da minha query ser mais eficiente do que a dele em maiores volumes de dados, já que ele primeiro vai fazer a ligação entre as tabelas e depois é que elimina em vez de ir buscar apenas os IDs e ir buscar o conteúdo correspondente a esse ID. Porque, se o AND é um lazy operator, ganhava-se tempo e espaço mudando a ordem das condições na query do Nazgulled.

Quem é que concorda e quem é que discorda, e porquê? :D

EDIT: O Nazgulled diz que afinal as 2 queries vieram de mim :P

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

O mais provável é que venham a ter ambas a mesma eficiência, pois os actuais SGBDs têm mecanismos bastante avançados de optimização de queries.

Mas a de baixo devia ser mais eficiente, pois o join (que é a operação mais cara), é feita com menos dados (é claro que depende sempre dos dados que existirem).

EDIT: reparei agora que a de baixo nem usa junções... Aquilo funciona? Não devia ter um IN em vez do =?

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Pois.. mas na segunda tem que se percorrer dois índices separadamente.

O primeiro select tem que percorrer sempre a tabela toda, pelo que se for possivel é melhor testares logo as condições que for possivle testar aí.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

EDIT: reparei agora que a de baixo nem usa junções... Aquilo funciona? Não devia ter um IN em vez do =?

Yap, aquela query não funciona, mas com o IN já bomba.

Tive a testar ambas usando o phpMyAdmin e os resultados de duração da query são idênticos para ambas...

E já agora, disseram-me que a primeira query tem um INNER JOIN implícito mas disseram-me que era preferível usa-lo de forma explicita. Só ainda não percebi porquê.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Nem uma nem outra.

SELECT p.*
FROM wp_posts p
INNER JOIN wp_term_relationships tr
ON p.ID = tr.object_id
WHERE tr.term_taxonomy_id = 10;

E já agora, disseram-me que a primeira query tem um INNER JOIN implícito mas disseram-me que era preferível usa-lo de forma explicita. Só ainda não percebi porquê.

A base de dados esta optimizada para fazer uso dos joins :)

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Não devia ter um IN em vez do =?

My bad, fixed.

SELECT p.*
FROM wp_posts p
INNER JOIN wp_term_relationships tr
ON p.ID = tr.object_id
WHERE tr.term_taxonomy_id = 10;

Curioso que tinha pensado em algo como essa query, mas depois quando foi para escrever escrevi mal (é o que dar usar coisas novas). Já posto aqui a query, vou buscar aos logs.

EDIT: Cá está:

Mar 24 03:40:24 <djthyrax> Nazgulled

Mar 24 03:40:24 <djthyrax> http://www.w3schools.com/sql/sql_join.asp

Mar 24 03:40:36 <djthyrax> o INNER JOIN

Mar 24 03:40:39 <djthyrax> não serviria?

Mar 24 03:40:48 <djthyrax> like:

Mar 24 03:41:58 <Nazgulled> n deve ser preciso, acho que o prob ta nos apostrofes

Mar 24 03:42:09 <djthyrax>

SELECT * FROM wp_posts INNER JOIN wp_term_relationships ON wp_posts.ID = wp_term_relationships.object_id AND wp_term_relationships.term_taxonomy_id = 10

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Nem uma nem outra.

SELECT p.*
FROM wp_posts p
INNER JOIN wp_term_relationships tr
ON p.ID = tr.object_id
WHERE tr.term_taxonomy_id = 10;

Sempre pensei que um SGBD tratasse essa query da mesma forma que a primeira...

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Sempre pensei que um SGBD tratasse essa query da mesma forma que a primeira...

As duas queries fazem exactamente a mesma coisa. A forma como esta escrita a primeira query e a minha query da' exactamente a mesma coisa, acontece que as BDs actuais estao dotadas de algoritmos muito poderosos para saber qual e' a melhor maneira de juntar os dados de duas tabelas. Por outras palavras: na primeira query tu escolhes uma maneira (a tua), na minha query eu deixo o servidor escolher a melhor maneira de acordo com aquilo que ele pensa que e' melhor e tambem de acordo com estatisticas de utilizacao. E' muito frequente os DBAs actualizarem as tabelas com dados estatisticos que permitem uma leitura mais rapida. 

A primeira query executa um CROSS JOIN, ou seja, faz um produto cartesiano das duas tabelas e depois devolve os resultados que pretendes. Consegues imaginar isto numa tabela com milhoes de registos? Seria desastroso...

A minha query deixa o servidor escolher livremente qual o melhor metodo.

Uma subquery e' vantajosa apenas quando queres ir buscar um valor agregado muito rapidamente (ie: uma media atraves do AVG()), por isso, o segundo exemplo e' completamente desaconselhado.

Em materias de joins, e' sempre mais vantajoso deixar o SGBD fazer como ele achar melhor dai o uso do JOIN.

Espero que tenha conseguido explicar-me bem, porque neste momento tambem ando a estudar um bocado por conta propria varios meios de usar queries eficientes.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

SELECT * FROM wp_posts 
INNER JOIN wp_term_relationships 
ON wp_posts.ID = wp_term_relationships.object_id 
AND wp_term_relationships.term_taxonomy_id = 10

Presumo que falta o 10 no teu copy paste ;-) vou assumir que sim.

Esta quase certo, mas o 10 nao devia la estar. Devia estar na clausula WHERE e vou-te explicar porque. O numero 10 nao e' um campo indexado (nem sequer e' um campo... e' um numero...) logo vai atrasar o teu JOIN e vai tornar a tua query mais cara. O term_taxonomy_id tambem nao me parece que seja indexado, tem cara de ser Foreign Key.

Seja como for, quando queres comparar valores hard-coded (literal, string...) e' preferivel deixa-los de fora da condicao do JOIN e po-los na query. Os campos presentes no JOIN para uma boa e rapida execucao, devem ser unica e simplesmente chaves primarias o que nao e' o caso do literal '10'.

Eu tambem desaconselho o uso do SELECT *

E' preferivel ir buscar so os campos de que realmente necessitamos. A maior causa das queries serem lentas e' exactamente a ideia de ir buscar tudo o que esta na base de dados e usar so o necessario no codigo. Mas 'as vezes e' preciso mesmo tudo e quando e' assim (e apenas assim) e' que se justifica o *

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Sim, eu apenas usei o * porque não sabia quais os campos que ele queria. :)

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Fazendo esta query no MS SQL Server (usando Northwind)

select *
from customers, orders
where customers.customerid = orders.customerid and
       orders.orderid < 20000

O SGBD conseguiu ver que a operação que eu estava a fazer era um INNER JOIN.

Além disso, em primeiro filtrou os elementos válidos da tabela orders, e só depois fez a junção.

Ou seja, mantenho a minha teoria de que o SGBD é suficientemente inteligente para optimizar as queries, e por isso não há diferenças significativas entre as versões apresentadas no post inicial e a versão com o INNER JOIN.

Mesmo fazendo mais junções, a forma como o SQL Server executa as queries é igual quer se use o INNER JOIN, quer se use o WHERE para indicar a condição do produto das tabelas.

PS: Não fiz testes noutros SGBDs, mas pressuponho que também façam optimização de queries de forma semelhante.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

La' esta', e' um JOIN implicito. Nao esta la descrito, mas o servidor assume que seja um por default. Eu nao gosto nem aconselho porque nao e' uma boa pratica.

Podemos entrar aqui num debate de Implicito VS Explicito que em termos de performance nao nos leva a lado nenhum.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

O que me disseram noutros lados é que a m**** é a mesma e só muda o cheiro. Basicamente, tu olhas para uma e vês logo o que ele esta a fazer porque está lá escrito (explicito) e olhas para a outra e podes não perceber à primeira (implicito). Acho que se trata apenas de uma questão de leitura e interpretação da sintaxe, nada mais.

Mas obrigado por todos os esclarecimentos e já agora, quem quiser, essa query serve para seleccionar todos os posts de um blog WordPress que pertençam a determinada categoria, neste caso à categoria com ID 10.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Viva!

Aqui vai a minha opinião:

- é sempre melhor explicitar os joins correctamente! ou seja, separar para a cláusula WHERE os "filtros" de dados e colocar na cláusula FROM as tabelas e a definição dos JOINS.

- é verdade que as bases de dados têm mecanismos de optimização e de avaliação das queries, mas também é verdade que quanto mais correcta e bem definida estiver a query, menos trabalho fica para o motor da base de dados e mais eficientemente pode ser elaborado o plano de execução da query.

- na construção das queries, além de se dever escrever a query da forma mais correcta e o mais completa possível, isso pode não ser suficiente. quero com isto dizer que uma query muito bem definida pode não ser a melhor query para uma determinada situação! depende das tabelas envolvidas, dos índices que as tabelas têm, do volume de dados esperado nas tabelas, que colunas queremos sacar das tabelas, se vamos usar funções na query, etc..

por exemplo, esta query simples:

SELECT a.xpto, a.abc, b.bbb
FROM tbl1 a INNER JOIN tbl2 b ON a.id = b.idp
WHERE b.ccc = 'XTC';

esta query é eficiente. mas se a tabela b tiver um volume de dados na casa dos milhões... já deixa de ser eficiente, apesar de estar correcta!

aí, por exemplo, podemos optimiza-la assim:

SELECT a.xpto, a.abc, v1.bbb
FROM tbl1 a, (SELECT b.idp, b.bbb FROM tbl2 b WHERE b.ccc = 'XTC) v1
WHERE a.id = v1.idp;

Nesta query, é "criada" uma in-line view v1, que filtra dos tais milhões de registos os que interessam e só depois faz o cruzamento com a tabela a.

Portanto, nem sempre é fácil afirmar qual a query mais eficiente, porque isso não depende só da forma como a query está implementada. Isso ainda se pode complicar mais em tabelas de volumes de dados muito voláteis. porque se a tabela tem 1000 registo e depois passar para milhões e depois para 0 registos... nestes casos, ainda é mais tramado! .. Depois.. há pessoas que se espantam de um simples SELECT demorar alguns segundos, quando as tabelas até têm poucos registos... pois.. mas as estatísticas podem não estar ainda actualizadas e a base de dados está a usar planos de execução menos eficientes para a situação actual das tabelas. enfim.. há muito por onde optimizar e muitas situações a contemplar.

Se acham isto interessante, recomendo a leitura de alguns bons livros de SQL tuning.

Por exemplo, um bom livro (para Oracle): http://www.amazon.com/Oracle-Tuning-Definitive-Reference-Focus/dp/0974448621/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1207238540&sr=1-1

Inté!

(as queries que escrevi são baseadas na minha experiência em Oracle.. não garanto que funcionem em MS SQL Server ou mySQL..)

aahh.. já me esquecia.. mais uma recomendação!

nunca escrevam as queries nas páginas web.. em ASP, ASP.NET, PHP ou seja lá o que for! coloquem as queries com bind variables em procedimentos na bd!! assim ficam compilados e as queries ficam com a sintaxe validada e depois nas páginas chamem esses procedimentos que devolvem os dados!! isto é muito importante! é muito mais correcto e eficiente!!

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

aahh.. já me esquecia.. mais uma recomendação!

nunca escrevam as queries nas páginas web.. em ASP, ASP.NET, PHP ou seja lá o que for! coloquem as queries com bind variables em procedimentos na bd!! assim ficam compilados e as queries ficam com a sintaxe validada e depois nas páginas chamem esses procedimentos que devolvem os dados!! isto é muito importante! é muito mais correcto e eficiente!!

Não percebi o que queres dizer. Não queres dar um exemplo prático do que não se deve fazer e do que se deve fazer?

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Façam "EXPLAIN query" em ambos sff. Mas com uma quantidade de dados razoável. O SGDB vai mostrar quantas linhas teve de analizar em cada tabela.

É por ai que se percebe a efeciencia do query :D

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

ora bem..

se tivesse tempo.. até gostava de escrever um artigo sobre o tema.. era bem interessante.. mas não consigo mesmo arranjar tempo para escrever um artigo em condições.. por isso mais vale estar quieto.

Mas, Nazgulled, o que eu quiz dizer é o seguinte:

imagina que estás a programar uma aplicação web seja lá em que plataforma ou linguagem for.. quando tems de interagir com uma base de dados não deves ter o código SQL junto com o código da web, ou seja.. não deves ter disto:

...
   query = "SELECT col1, col2 FROM tbl1 WHERE col3 = '" + v1 + "'";  //qualquer coisa como isto
   // e depois executas esta query por RS e CONN ADO ou outro provider qualquer..
...

deves sim ter na base de dados um procedimento tipo isto:

procedure listXPTO(pID IN number, pRS OUT ref cursor) as
begin

   open pRS for
         SELECT col1, col2 FROM tbl1 WHERE col3 = pID;

   exception
   when others then
        raise;
end listXPTO;

e depois de ter este procedimento na bd, devidamente compilado (isto quer dizer que a query já foi validada, e não vai ser mais validada), chamas então na web o procedimento (usando um command ADO, por exemplo, e passando o parâmetro pID e recebendo resultado da query.

esta técnica, tem as seguintes vantagens (entre outras que me posso estar a esquecer..):

- a query está na bd compilada e validada.

- não é possivel tentar injectar código para alterar a query (tipo, colocar no valor do parâmetro "ola" or 1 = 1)

- o motor da base de dados vai colocar na cache o plano de execução para a query.. porque estamos a usar bind variables, enquanto que no primeiro caso nunca fica em cache, e portanto vai ser sempre considerada pela base de dados como sendo uma query nova e por isso vai ser validada a sintaxe, vao ser criados planos de execução, vai ser escolhido o melhor plano e depois vai ser executada a query.

- se algo não estiver a funcionar como esperado na base de dados podes sempre pedir ajuda a um DBA.. e ele vai olhar para a base de dados e ver o que se passa.. agora não vais pedir a um DBA que ande às voltas pela aplicação web a ver o código SQL espanhado por todo o lado.. ele manda-te logo dar uma voltinha!! :D

- ficas com o código web mais limpo

- em caso de crash nunca vai parar ao utilizador final a query nem algo do género.. como se vê ai por muitos lados

- ... e há muitas mais razões.. mas estas já deverão ser suficientes.. confia em mim.. é mesmo melhor ter todo o código relacionado com a base de dados na própria base de dados... seja ela qual for!

espero ter ajudado.. isto foi escrito assim um bocado sobre o joelho.. mas não tenho tempo agora para mais.

Inté

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Só não percebi a parte de ter o "procedimento na bd", nem faço ideia de como faria isso... Mas por exemplo, PHP que é aquilo em que eu programo. Basicamente estas a dizer para todo o código que faz queries a bd não deve ser feito em qualquer tipo de código em PHP. É isso?

Se for, como já disse, não faço ideia como fazer. E depois, não sei se me agrada a ideia... Pode ter muitas vantagens como as que acabaste de anunciar, mas estou tão habituado ao fluxo de trabalho que tenho neste momento, que não me apetece mudar e é um fluxo usado pela maioria, portanto não deve ser assim tão mau para eu pensar se quer em fazer as coisas de forma diferente como falas.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites
Basicamente estas a dizer para todo o código que faz queries a bd não deve ser feito em qualquer tipo de código em PHP.
É isso mesmo!!

todo o código da bd, seja selects, inserts, updates, deletes... deve ser feito em procedures na bd, e depois então, no php devem ser chamadas essas procedures com os parâmetros necessários. Esta é a maneira mais correcta e eficiente de o fazer.

se a maioria do povo mete o código SQL no meio do código web.. estão a fazer mal.  por exemplo, quando defines o estilo das tuas páginas não colocas as class em ficheiros CSS à parte? Todo o desenvolvimento deveria ser feito assim. cada tipo de código no seu lugar devido.

Já agora, não sei que bases de dados costumas usar, mas aqui ficam uns links para documentação para desenvolvimento de procedimentos na base de dados... se experimentares, vais ver que é simples e depois não queres outra coisa! :P

http://www.oracle.com/pls/db111/homepage

http://msdn2.microsoft.com/en-us/library/aa174792(SQL.80).aspx

http://dev.mysql.com/doc/refman/5.0/en/stored-procedures.html

Inté

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Costumo usar MySQL.

Basicamente estas a dizer que toda a gente está a fazer mal? 90% se não mais do pessoal, deve programar assim, e qualquer tutorial na net que se encontra sobre PHP + MySQL ensina a fazer dessa forma e não procedimentos na base de dados.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Costumo usar MySQL.

Basicamente estas a dizer que toda a gente está a fazer mal? 90% se não mais do pessoal, deve programar assim, e qualquer tutorial na net que se encontra sobre PHP + MySQL ensina a fazer dessa forma e não procedimentos na base de dados.

Isto é completamente verdade...

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

e possivel que muitas pessoas estejam "enganadas" na forma como programam, quando ves tutorials e afins na net, nem sempre ou quase nunca se ve algo para ser feito de forma muito eficiente, ou talvez de forma segura.

Sem ter noção completa da realidade, talvez em muitos dos casos de service providers onde o pessoal tem conta não disponibiliza acesso na base de dados para fazer "stored procedures" ou a criação de vista, e talvez devido a isto não seja muito visivel situações as maiores preocupacoes sejam a nivel de eficiencia mas sim de que se não se tem acesso a manipular os dados desta maneira então que se faca de outra maneira.

boas programacoes

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

jsWizard, sabes que um dos principais defeitos de guardar procedures é que a portabilidade da BD fica completamente eliminada.

imagina que estás a programar uma aplicação web seja lá em que plataforma ou linguagem for.. quando tems de interagir com uma base de dados não deves ter o código SQL junto com o código da web, ou seja.. não deves ter disto:

Primeiro misturar SQL e PHP é mesmo só para quem não sabe programar. Existem padrões que tornam independente as Queries do resto do código PHP.

- não é possivel tentar injectar código para alterar a query (tipo, colocar no valor do parâmetro "ola" or 1 = 1)

- o motor da base de dados vai colocar na cache o plano de execução para a query.. porque estamos a usar bind variables, enquanto que no primeiro caso nunca fica em cache, e portanto vai ser sempre considerada pela base de dados como sendo uma query nova e por isso vai ser validada a sintaxe, vao ser criados planos de execução, vai ser escolhido o melhor plano e depois vai ser executada a query.

Um bom programa em PHP tem ferramentas que previnem a 100% a SQL Injection. Além disso os SGDB (Bases-de-Dados) teem dos sistemas de cahce mais avançados que existem. E sim fazem cache das queries.

- se algo não estiver a funcionar como esperado na base de dados podes sempre pedir ajuda a um DBA.. e ele vai olhar para a base de dados e ver o que se passa.. agora não vais pedir a um DBA que ande às voltas pela aplicação web a ver o código SQL espanhado por todo o lado.. ele manda-te logo dar uma voltinha!! :P

- ficas com o código web mais limpo

Igual ao que está lá em cima. Existem padrões que separam toda a lógica da parte dos dados (MVC).

- em caso de crash nunca vai parar ao utilizador final a query nem algo do género.. como se vê ai por muitos lados

Uma boa layer de Base-de-Dados permite fazer o log dos erros, e faz acções para que o utilizador não se aperceba que houveram erros.

As procedures devem ter as suas vantagens mas acho que não é correcto afirmarmes categóricamente que aquela forma de programar é errada.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Ora bem.. vamos lá ver se me explico e se respondo a toda a gente.. de caminho o povo do PHP + MySQL junta-se para me dar uma carga de porrada!! hehehe  :eek:

Basicamente estas a dizer que toda a gente está a fazer mal? 90% se não mais do pessoal, deve programar assim, e qualquer tutorial na net que se encontra sobre PHP + MySQL ensina a fazer dessa forma e não procedimentos na base de dados.

Nazgulled, os tutoriais não podem ser vistos com manuais de referência e muito menos como manuais de referência no que toca a fazer as coisas da melhor maneira, da forma mais optimizada e eficiente. Os tutoriais são bons para quem está a dar os primeiros passos numa determinada tecnologia e precisa de ajuda para arrancar. Agora, quando falamos em eficiencia e optimização, não nos podemos guiar por um qualquer tutorial. Foi isto que eu quis dizer..

Agora.. a forma de programar também está directamente relacionada com aquilo que estamos a programar.. se estou a fazer um pequeno site sem nada critico.. é pá aí.. se calhar até admito SQL no meio do código. Agora se estou a desenvolver uma aplicação complexa, grande, muitos milhares de linhas de código, várias tecnologias, várias pessoas envolvidas no desenvolvimento... ai já não consigo admitir cenários em que há misturadas de código e SQL dentro da programação.. isso é que não. comigo não!!

MX+, em relação à cache de "queries", usando queries do lado da web, estas não ficam na cache:

por exemplo:

SELECT abc FROM xpto WHERE id = 2;

e

SELECT abc FROM xpto WHERE id = 1;

estas duas queries na base de dados são "interpretadas" como sendo diferentes, logo é feito o parse, os planos de execução, ..., e só depois é que a query é executada. e uma query nunca serve de cache para a outra.

MAS, se a query estiver num procedimento na base de dados, e definida com bind variables, assim:

SELECT abc FROM xpto WHERE id = :pID;

depois, o que é passado para o procedimento é o valor de pID, e ai sim, o plano de execução vai ficar na cache da base de dados, e qualquer que seja o valor do pID essa cache do melhor plano de execução vai ser usada. e já não existe parse e validação da query, porque esta já está na bd e já está validada e compilada.

jsWizard, sabes que um dos principais defeitos de guardar procedures é que a portabilidade da BD fica completamente eliminada.

É totalmente verdade! Mas não vejo isto como uma grande desvantagem.. não é todos os dias que num projecto se muda de base de dados. (nunca me aconteceu.. mas eu trabalho só com Oracle)

As procedures devem ter as suas vantagens mas acho que não é correcto afirmarmes categóricamente que aquela forma de programar é errada.

Eu acho não é a melhor maneira, só isso. E não é a mais eficiente.. e neste tópico estavamos a falar de eficiencia.

e possivel que muitas pessoas estejam "enganadas" na forma como programam, quando ves tutorials e afins na net, nem sempre ou quase nunca se ve algo para ser feito de forma muito eficiente, ou talvez de forma segura.

Sem ter noção completa da realidade, talvez em muitos dos casos de service providers onde o pessoal tem conta não disponibiliza acesso na base de dados para fazer "stored procedures" ou a criação de vista, e talvez devido a isto não seja muito visivel situações as maiores preocupacoes sejam a nivel de eficiencia mas sim de que se não se tem acesso a manipular os dados desta maneira então que se faca de outra maneira.

Concordo com o falk0n.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Crie uma conta ou ligue-se para comentar

Só membros podem comentar

Criar nova conta

Registe para ter uma conta na nossa comunidade. É fácil!


Registar nova conta

Entra

Já tem conta? Inicie sessão aqui.


Entrar Agora