Ir para conteúdo

POWERED BY:

Arquivado

Este tópico foi arquivado e está fechado para novas respostas.

Michel Kuguio

views, routine e routinegroups

Recommended Posts

eu comecei a usar o mysql workbench e descobri varias coisas nele.. ja fiz os relacionamento entre as tabelas, e vi que tem varias coisas que nao conhecia.

 

essas: views, routines e groups;

pelo q pesquisei a view seria uma consulta seria isso mesmo?

se sim essa consulta é estática ou tem como ser dinâmica?

 

essas configurações diferente vale pra sites?

tipo tem como eu usar isso junto com minha query php.. tentando trazer um desempenho maior para minhas consultas?

 

só gostaria de saber o q é cda item e como seria recomendado fazer para quem desenvolve sites?

e é claro links de lugares q encima usar cada parte da melhor maneira possível.

Compartilhar este post


Link para o post
Compartilhar em outros sites

Boa tarde amigo,

 

Uma VIEW é nada mais que uma consulta (SELECT) que fica "armazenado" no banco. Imagine que você tem um SELECT gigante, com vários JOINs ou algo assim. Ao invés de você executar ele sempre de dentro da aplicação, você faz isto:

 

CREATE VIEW minhaView AS
SELECT ... FROM ...

Depois na aplicação você só faz um SELECT * FROM minhaView, passando filtros se desejar e etc.

 

Todas essas funcionalidades são independentes da tua aplicação, elas fazem parte do banco. Ou seja, você modela no Workbench, cria no banco, e a tua aplicação, independente que seja um site ou qualquer coisa, que utilize esse banco, estará apta para usar todas as funcionalidades.

 

Veja aqui um bom material sobre VIEWs aqui do iMasters.

 

Espero que seja útil, precisando estamos aí, abraços.

Compartilhar este post


Link para o post
Compartilhar em outros sites

Uma view funciona como um facilitador.

 

- Se você utiliza uma mesma consulta em várias partes do sistema, você pode criar uma view para isso, diminui retrabalho;

- Views funcionam de forma similar as tabelas, logo, se você tem um resultado é possível usar filtros sobre os resultados desta;

- Uma das maiores vantagens da view é o permissionamento, exemplo, você tem um SELECT que acessa 20 tabelas, se esta tabela estiver num sistema de CRM, o usuário deste sistema deve ter acesso de leitura nas 20 tabelas, se você cria uma view, basta dar a permissão para este usuário na view;

- Alguns sgbds permitem views compiladas/materializadas, isto da um ganho de permormance no momento que o sistema vai interpretar a query; (não no MySQL)

- Alguns sgbds permitem views indexadas; (não no MySQL)

Compartilhar este post


Link para o post
Compartilhar em outros sites

Boa tarde amigo,

 

Uma VIEW é nada mais que uma consulta (SELECT) que fica "armazenado" no banco. Imagine que você tem um SELECT gigante, com vários JOINs ou algo assim. Ao invés de você executar ele sempre de dentro da aplicação, você faz isto:

 

CREATE VIEW minhaView AS
SELECT ... FROM ...

Depois na aplicação você só faz um SELECT * FROM minhaView, passando filtros se desejar e etc.

 

Todas essas funcionalidades são independentes da tua aplicação, elas fazem parte do banco. Ou seja, você modela no Workbench, cria no banco, e a tua aplicação, independente que seja um site ou qualquer coisa, que utilize esse banco, estará apta para usar todas as funcionalidades.

 

Veja aqui um bom material sobre VIEWs aqui do iMasters.

 

Espero que seja útil, precisando estamos aí, abraços.

pelo você falou é o q eu tinha imagindo sobre ela.... cara isso deve almentar bastante o desenpenho né ou é so impressão?

 

quanto a group e routine tem alguma relaçao com as views?

Compartilhar este post


Link para o post
Compartilhar em outros sites

Uma view funciona como um facilitador.

 

- Se você utiliza uma mesma consulta em várias partes do sistema, você pode criar uma view para isso, diminui retrabalho;

- Views funcionam de forma similar as tabelas, logo, se você tem um resultado é possível usar filtros sobre os resultados desta;

- Uma das maiores vantagens da view é o permissionamento, exemplo, você tem um SELECT que acessa 20 tabelas, se esta tabela estiver num sistema de CRM, o usuário deste sistema deve ter acesso de leitura nas 20 tabelas, se você cria uma view, basta dar a permissão para este usuário na view;

- Alguns sgbds permitem views compiladas/materializadas, isto da um ganho de permormance no momento que o sistema vai interpretar a query; (não no MySQL)

- Alguns sgbds permitem views indixadas; (não no MySQL)

tenho uma duvida digamos q eu tenho q fazer uma pesquisa parecida porem com wherer diferente..

exempostenho q pesquisar clients usando join com a tabela cidades e profisao.

porem sempre vou mudar a profissao,

se eu fizer uma consulta predefinitar de cliente,cidade e profissao, ea fica como se fosse uma tabela em cache ou toda vez q executa a view ela pesquisa denovo?

pq se elfa ficar como uma possivel tabela, epois eu poderia da uma select na view com o wherer diferente.

ai acho q teria um dezempenho maior... ou nao?

pq no meu site seria uma situacao parecida com essa.. eu tenho q usar JOIN e UNION em todos porem com condições diferentes.

 

Routine são para o MySQL Stored Procedures e Functions.

Group não estou entendendo o contexto.

é q no MySQL aparece essas opções:views, routine e routinegroups, e relationship.

relationship eu ja sei, views fiquei sabendo agora...

fiquei curioso para saber.. vai q tem algo q possa melhorar no desempenho do sistema né.. é bom aprender. xD

Compartilhar este post


Link para o post
Compartilhar em outros sites

pelo você falou é o q eu tinha imagindo sobre ela.... cara isso deve almentar bastante o desenpenho né ou é so impressão?

 

quanto a group e routine tem alguma relaçao com as views?

Sim, o Prog listou as vantagens que temos ao utilizar VIEWs.

 

Routines são Procedures e Functions, já ouviu falar?

 

Ao invés de você fazer procedimentos ou funções que rodam consultas dentro da aplicação (na tua linguagem de programação - PHP por exemplo), você as cria dentro do banco e desta forma todo o processamento é feito pelo mesmo.

 

Exemplo:

 

Digamos que você tenha um campo chamado sexo numa tabela usuario, este campo armazena M ou F (Masculino ou Feminino). No seu site você tem os seguintes arquivos:

 

/* Arquivo Funcoes.php */

function retornaSexo($sexo)
{
   if ($sexo = "M") return "Masculino";
   if ($sexo = "F") return "Feminino";
}

/* Arquivo Consulta.php */

include("Funcoes.php");

$consulta = mysql_query("SELECT sexo FROM usuario");

while ($result = mysql_fetch_array($consulta)){
   echo retornaSexo( $result["sexo"] )."<br />";
}

Ou seja, você seleciona o sexo em forma "F" ou "M" do banco e o PHP se encarrega de "traduzir" a informação pra você.

 

- Como seria se você tivesse uma Function no banco -

 

No caso abaixo, você tem uma função no seu banco de dados que serve para retornar pra aplicação o sexo já "formatado" como você deseja.

 

CREATE FUNCTION retornaSexo ( sexo char(1) ) RETURNS varchar(15)
BEGIN
   IF (sexo = 'M') THEN RETURN 'Masculino' ; END IF ;
   IF (sexo = 'F') THEN RETURN 'Feminino'  ; END IF ;
END;

/* Arquivo Consulta.php */
$consulta = mysql_query("SELECT retornaSexo(sexo) AS sexo FROM usuario");

while ($result = mysql_fetch_array($consulta)){
   echo $result["sexo"]."<br />";
}

Note que nesse segundo exemplo o arquivo Funcoes.php não existe mais, pois a sua função está no banco agora. Este é um exemplo super simples, tanto que você não precisa nem de uma função para ele, basta usar o DECODE, função nativa já do MySQL para casos assim:

 

SELECT (DECODE(sexo, 'M', 'Masculino', 'F', 'Feminino')) AS sexo FROM usuario

Perdão se houver algum erro de sintaxe nos códigos, é que fiz estes exemplos aqui direto só pra te mostrar.

 

Espero que seja útil, abraço.

 

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

 

As Routines como já dito são Procedures e Functions.

 

Group Routines servem apenas para digamos, separar as rotinas em grupos. Por exemplo, você tem um ERP com módulos de Contabilidade, Escrita Fiscal, dentre outros. As Procedures A, B e C são de processos contábeis, sendo assim você separa elas num grupo chamado routinesContabeis (ou qualquer nome que desejar).

 

Lendo na internet descobri que você não pode adicionar uma routine ao diagrama ER, apenas group routines.

 

Quanto a tua pergunta para o Prog, você pode criar a sua VIEW sem usar WHERE nenhum. E depois na aplicação você faz:

 

SELECT * FROM minhaView WHERE profissao = 'profissao que deseja'

Entende? Um cuidado importante pra se ter com VIEWs é que é bom que você dê nomes a todas as colunas. Por exemplo:

 

CREATE VIEW minhaView AS
SELECT id AS idUsuario, nome AS nomeUsuario, profissao AS profissaoUsuario FROM usuario

Dessa forma na tua aplicação você faria:

 

SELECT * FROM minhaView WHERE profissaoUsuario = 'programador'

Mais uma vez um exemplo simples, você pode rechear sua VIEW de JOINs como citou.

 

Abraço.

Compartilhar este post


Link para o post
Compartilhar em outros sites

Sim, o Prog listou as vantagens que temos ao utilizar VIEWs.

 

Routines são Procedures e Functions, já ouviu falar?

 

Ao invés de você fazer procedimentos ou funções que rodam consultas dentro da aplicação (na tua linguagem de programação - PHP por exemplo), você as cria dentro do banco e desta forma todo o processamento é feito pelo mesmo.

 

Exemplo:

 

Digamos que você tenha um campo chamado sexo numa tabela usuario, este campo armazena M ou F (Masculino ou Feminino). No seu site você tem os seguintes arquivos:

 

/* Arquivo Funcoes.php */

function retornaSexo($sexo)
{
   if ($sexo = "M") return "Masculino";
   if ($sexo = "F") return "Feminino";
}

/* Arquivo Consulta.php */

include("Funcoes.php");

$consulta = mysql_query("SELECT sexo FROM usuario");

while ($result = mysql_fetch_array($consulta)){
   echo retornaSexo( $result["sexo"] )."<br />";
}

Ou seja, você seleciona o sexo em forma "F" ou "M" do banco e o PHP se encarrega de "traduzir" a informação pra você.

 

- Como seria se você tivesse uma Function no banco -

 

No caso abaixo, você tem uma função no seu banco de dados que serve para retornar pra aplicação o sexo já "formatado" como você deseja.

 

CREATE FUNCTION retornaSexo ( sexo char(1) ) RETURNS varchar(15)
BEGIN
   IF (sexo = 'M') THEN RETURN 'Masculino' ; END IF ;
   IF (sexo = 'F') THEN RETURN 'Feminino'  ; END IF ;
END;

/* Arquivo Consulta.php */
$consulta = mysql_query("SELECT retornaSexo(sexo) AS sexo FROM usuario");

while ($result = mysql_fetch_array($consulta)){
   echo $result["sexo"]."<br />";
}

Note que nesse segundo exemplo o arquivo Funcoes.php não existe mais, pois a sua função está no banco agora. Este é um exemplo super simples, tanto que você não precisa nem de uma função para ele, basta usar o DECODE, função nativa já do MySQL para casos assim:

 

SELECT (DECODE(sexo, 'M', 'Masculino', 'F', 'Feminino')) AS sexo FROM usuario

Perdão se houver algum erro de sintaxe nos códigos, é que fiz estes exemplos aqui direto só pra te mostrar.

 

Espero que seja útil, abraço.

 

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

 

As Routines como já dito são Procedures e Functions.

 

Group Routines servem apenas para digamos, separar as rotinas em grupos. Por exemplo, você tem um ERP com módulos de Contabilidade, Escrita Fiscal, dentre outros. As Procedures A, B e C são de processos contábeis, sendo assim você separa elas num grupo chamado routinesContabeis (ou qualquer nome que desejar).

 

Lendo na internet descobri que você não pode adicionar uma routine ao diagrama ER, apenas group routines.

 

Quanto a tua pergunta para o Prog, você pode criar a sua VIEW sem usar WHERE nenhum. E depois na aplicação você faz:

 

SELECT * FROM minhaView WHERE profissao = 'profissao que deseja'

Entende? Um cuidado importante pra se ter com VIEWs é que é bom que você dê nomes a todas as colunas. Por exemplo:

 

CREATE VIEW minhaView AS
SELECT id AS idUsuario, nome AS nomeUsuario, profissao AS profissaoUsuario FROM usuario

Dessa forma na tua aplicação você faria:

 

SELECT * FROM minhaView WHERE profissaoUsuario = 'programador'

Mais uma vez um exemplo simples, você pode rechear sua VIEW de JOINs como citou.

 

Abraço.

 

nossa valeu mesmo.. tirou todas minhas duvidas... eu meio q aprendi tudo como autodidata...

aí as duvidas dependo de fóruns...

acho q vou usar só as views que alem de parecer ser fácil de fazer creio q vai dar um Up legal no rendimento do site.

ja as rountines vou estudar mais, achei um pouco elas um pouco complicado.

 

você que ja tem mais prática o ganho na performance pra ser notado?

Compartilhar este post


Link para o post
Compartilhar em outros sites

Bom, eu nunca trabalhei com MySQL comercialmente, apenas didaticamente e pessoalmente. Mas nesses quesitos sempre procurei fazer o necessário pra melhorar meus bancos. As VIEWs podem ser muito úteis em alguns casos, em outro podem ser dispensáveis, assim como os índices por exemplo. Ou seja, o ganho é relativo.

 

Agora sobre Stored Procedures e Functions eu garanto que é muito bom ter a prática de utilizá-las. Não é complicado, basta você aprender alguns comandos SQL, que não são diferentes da maioria das linguagens de programação (IF, CASE, WHILE, REPEAT, com esses tu já pode dar uma boa "programada em SQL"). Essas rotinas, como disse antes, livram a aplicação de processamentos pesados, jogando tudo para o banco. Além delas, se você não tiver costume ainda, use e aprenda sobre as funções nativas do MySQL, como o DECODE que citei, dentre outras que quebram bastante o galho de vez em quando.

 

E havendo dúvidas e problemas é só chegar aí no fórum que estamos a disposição :thumbsup:

 

Abraço.

Compartilhar este post


Link para o post
Compartilhar em outros sites

Bom, eu nunca trabalhei com MySQL comercialmente, apenas didaticamente e pessoalmente. Mas nesses quesitos sempre procurei fazer o necessário pra melhorar meus bancos. As VIEWs podem ser muito úteis em alguns casos, em outro podem ser dispensáveis, assim como os índices por exemplo. Ou seja, o ganho é relativo.

 

Agora sobre Stored Procedures e Functions eu garanto que é muito bom ter a prática de utilizá-las. Não é complicado, basta você aprender alguns comandos SQL, que não são diferentes da maioria das linguagens de programação (IF, CASE, WHILE, REPEAT, com esses tu já pode dar uma boa "programada em SQL"). Essas rotinas, como disse antes, livram a aplicação de processamentos pesados, jogando tudo para o banco. Além delas, se você não tiver costume ainda, use e aprenda sobre as funções nativas do MySQL, como o DECODE que citei, dentre outras que quebram bastante o galho de vez em quando.

 

E havendo dúvidas e problemas é só chegar aí no fórum que estamos a disposição :thumbsup:

 

Abraço.

Sabe algum Material bom, site, ou tutorial na internet legal para eu estudar mais sobre Stored Procedures e Functions?

Compartilhar este post


Link para o post
Compartilhar em outros sites

Bah deve ter tantos por aí, aqui no iMasters mesmo tu pode achar muitas coisas:

 

Portal de artigos de MySQL

 

Além de outros sites bons como devmedia, oficinadanet, alguns blogs particulares por aí, fóruns de PHP como o phpbrasil, além é claro da própria documentação do MySQL.

 

Joga Stored Procedures e Functions no Google que tu se diverte bastante :D Dá pra achar muitos materiais pra ir começando, e o resto você vai tirando de letra. A melhor maneira de aprender é fuçar! Autodidata como você disse, a gente pode aprender muitas coisas sozinhos só com boa vontade e disposição =]

 

Precisando estamos aí, abraço.

Compartilhar este post


Link para o post
Compartilhar em outros sites

Bah deve ter tantos por aí, aqui no iMasters mesmo tu pode achar muitas coisas:

 

Portal de artigos de MySQL

 

Além de outros sites bons como devmedia, oficinadanet, alguns blogs particulares por aí, fóruns de PHP como o phpbrasil, além é claro da própria documentação do MySQL.

 

Joga Stored Procedures e Functions no Google que tu se diverte bastante :D Dá pra achar muitos materiais pra ir começando, e o resto você vai tirando de letra. A melhor maneira de aprender é fuçar! Autodidata como você disse, a gente pode aprender muitas coisas sozinhos só com boa vontade e disposição =]

 

Precisando estamos aí, abraço.

 

valeu,

Moderadores pode marcar como resolvido

Compartilhar este post


Link para o post
Compartilhar em outros sites

Satisfação em ajudar :D Abraço e até a próxima!

Bom vou aproveitar q o tópico aina esta aberto e e postar uma duvide sobre um problema q estou tendo com view, aki ta flando q a view ta sem chave primaria, fala isso quando eu coloco um order by... pq ta acontecendo isso? e como q faço pra definir essa chave primaria?

Compartilhar este post


Link para o post
Compartilhar em outros sites

Boa noite amigo,

 

Você está tentando colocar um ORDER BY num SELECT ... FROM view ou num CREATE VIEW AS SELECT ... FROM ... ORDER BY ... ?

 

A princípio não é pra haver problema em nenhum dos dois, poste o código da sua VIEW aqui e o SELECT que você está tentando fazer.

 

Veja uma VIEW que tenho aqui de exemplo:

 

CREATE OR REPLACE VIEW vwDisciplinaXProfessor AS
SELECT 
   d.nome AS nomeDisciplina,
   p.nome AS nomeProfessor
FROM prf_dis pd
JOIN disciplina d ON d.idDisciplina = pd.idDisciplina
JOIN professor  p ON p.idProfessor  = pd.idProfessor
ORDER BY d.nome, p.nome ASC

No aguardo, abraço.

Compartilhar este post


Link para o post
Compartilhar em outros sites

Boa noite amigo,

 

Você está tentando colocar um ORDER BY num SELECT ... FROM view ou num CREATE VIEW AS SELECT ... FROM ... ORDER BY ... ?

 

A princípio não é pra haver problema em nenhum dos dois, poste o código da sua VIEW aqui e o SELECT que você está tentando fazer.

 

Veja uma VIEW que tenho aqui de exemplo:

 

CREATE OR REPLACE VIEW vwDisciplinaXProfessor AS
SELECT 
   d.nome AS nomeDisciplina,
   p.nome AS nomeProfessor
FROM prf_dis pd
JOIN disciplina d ON d.idDisciplina = pd.idDisciplina
JOIN professor  p ON p.idProfessor  = pd.idProfessor
ORDER BY d.nome, p.nome ASC

No aguardo, abraço.

eu coloquei assim

CREATE VIEW `perfeito`.`er_cid_est_reg` AS

SELECT
er_estados.Id AS IdEstado,
er_estados.Estado AS NomeEstado,
er_estados.Sigla AS SiglaEstado,
er_regiao.Id AS IdRegiao,
er_regiao.Regiao AS NomeRegiao,
er_cidades.Id AS IdCidade,
er_cidades.Cidade AS NomeCidade 

FROM
er_estados 

INNER JOIN er_regiao ON er_estados.Id = er_regiao.Estado 
INNER JOIN er_cidades ON er_regiao.Id = er_cidades.Regiao 

ORDER BY er_cidades.Id ASC

 

eu coloquei assim

CREATE VIEW `perfeito`.`er_cid_est_reg` AS

SELECT
er_estados.Id AS IdEstado,
er_estados.Estado AS NomeEstado,
er_estados.Sigla AS SiglaEstado,
er_regiao.Id AS IdRegiao,
er_regiao.Regiao AS NomeRegiao,
er_cidades.Id AS IdCidade,
er_cidades.Cidade AS NomeCidade 

FROM
er_estados 

INNER JOIN er_regiao ON er_estados.Id = er_regiao.Estado 
INNER JOIN er_cidades ON er_regiao.Id = er_cidades.Regiao 

ORDER BY er_cidades.Id ASC

engraçado q se eu tiro o ORDER BY e usar o order em uma query nao da erro.

mas fiquei com receio de aprecer isso.

tem q declarar chave primaria?

Compartilhar este post


Link para o post
Compartilhar em outros sites

Que eu saiba não.

 

Tente dar o ORDER BY por outro campo qualquer, ele pode estar implicando com esse campo ser chave primária de uma das tabelas que você pesquisou. Tente um campo VARCHAR por exemplo. E tente um ORDER BY IdCidade, que é o alias dessa coluna que tu deseja.

 

Se possível poste o erro que dá aqui.

Compartilhar este post


Link para o post
Compartilhar em outros sites

Que eu saiba não.

 

Tente dar o ORDER BY por outro campo qualquer, ele pode estar implicando com esse campo ser chave primária de uma das tabelas que você pesquisou. Tente um campo VARCHAR por exemplo. E tente um ORDER BY IdCidade, que é o alias dessa coluna que tu deseja.

 

Se possível poste o erro que dá aqui.

ja tentei:

ORDER BY IdCidade

e ja mudei as ordem dos Join e do select.

engraçado q o ID da cidade é unico o resto na junção no fica.. pq tem cidades em estados diferente com mesmo nome,

e ja estado e região repete a unica coisa q nao repete é o id.

 

mas deve ser algum bug do programa intão.. pq na query q faço em seguida sobre a view com orderby nao da nenhuma msg de erro. mas achei melhor confirmar aki pra nao fazer cagada xD

Compartilhar este post


Link para o post
Compartilhar em outros sites

Estranho. Bug não deve ser pois eu também uso o Workbench, v. 5.2.42 só pra constar.

 

Os outros campos não dá esse erro? Então ele implicou com esse campo em específico mesmo.

Compartilhar este post


Link para o post
Compartilhar em outros sites

×

Informação importante

Ao usar o fórum, você concorda com nossos Termos e condições.