Denis Courcy

Oi, Guido, Bom dia, Exatamente. Eu uso o ErWin da CA computers. Mas as ferramentas que você tem são bem eficientes.

Oi, 'Guido Gabriel'! Observe o último modelo que te passei, no post #6 deste tópiico, a tabela de relacionamento "pessoa_papel" deverá ser renomeada para pessoa_papel_processo, pois é uma ligação ternária e atende o que você está solicitando aqui. Primeiro, esgote por completo o livro que você comprou. ele tem muitos truques que te serão muito úteis. Sim. Adm de Empresas. Escolhi este curso porque já sabia o suficiente de TI e necessitava saber como pensava o cidadão que ficava do outro lado da mesa, quando eu o entrevistava para desenvolver um sistema.

Oi, 'llsanches'! Verifique, em primeiro lugar, como você organizou os índices e suas consultas. 90% dos problemas de lentidão serão resolvidos analisando estes dois elementos. Quanto aos dados enviados, analisarei amanhã. Não há tempo hábil para fazê-lo hoje.

Substitua sua cláusula WHERE para que fique assim: WHERE [consulta1].[servidor1]=[consulta2].[servidor1] AND ([<sua tabela>].[<sua data periodo>] BETWEEN #01/01/2008# AND #31/01/2008#; onde [<sua tabela>].[<sua data periodo>] é o nome da tabela e do campo que possui a data que será o período avaliado. #01/01/2008# e #31/01/2008# são constantes usadas aqui para efeito de exemplo.

Oi, '4planos' ! Não trabalho com workbench, e, onde estou, não tenho autorização para instalar nenhum programa.

Oi, 'BetoGroo'! Sim, Você está certo. Vou enviar uma errrata para o Site.

Oi, 'Guido Gabriel'! Bom dia, Sim. Sim. Da maneira tradicional, colocando bairro cidade, estado, direto na tabela como campos descritivos. Mas, deste jeito, você estará propiciando erros, abreviações, duplicidades de informação, etc. Espere que ele chegue. Você terá muito o que explorar nele. Eu gosto muito deste livro: Sistemas de Bancos de Dados

Oi,'ForceX'! Não, se já foram aceitos/commited. Neste caso só manualmente, atraves do comando delete ou update ou restauração de backup. Se você ainda estiver em uma transação ue ainda não foi dado um "commit", você poderá realizar um "rollback". No caso de restauração de backup, só será possível recuperar uma falha que tenha ocorrido entre um backup e outro, se você mantier o log-binário ligado.

Movendo MySQL -->> ACCESS

São algumas as diferenças: 1- Forma de grvação dos dados. a) Tabelas MyISAM: Não são transacionais. As gravações não ocorrem em um único bloco. Isto acaba permitindo que os dados e uma tabela (dentro de uma transação com duas tabelas, por exemplo), sejam gravados e comitados antes que a transação esteja completa. Se houver erro na gravação da segunda tabela, então NÃO haverá rollback. Com isto coisas estranhas podem acontecer, tais como "dados de tabelas filhas incluídos antes dos dados da tabela pai", ou pior, "tabela pai sejam excluídos antes dos dados de tabelas filhas". Tornando estes dados órfãos e possibilitando a inconsistência do banco de dados. B) Tabelas InnoDB: São transacionais. Uma transação é ACID, com commit e rollback. Ou seja, ou toda a transação é gravada ou NADA é gravado. Com isto a segurança é melhor. 2) Facilidade de manutenção: As tabelas MyISAM são de manutenção mais fácil que as tabelas InnoDB. 3) Backup: As tabelas InnoDB exigem que o log binário esteja ativado. Em minha opinião, trabalhar com qualquer tipo de tabela sem o log binário ativado é suicídio. Ele é uma garantia de recuperação de dados entre um backup e outro. 4) Forma de armazenamento: a) As tabelas MyISAm possuem 3 arquivos para cada tabela. O primeiro possui extensão .frm e contém a estrutura da tabela. O segundo .mdy, contém os dados da tabela. O terceiro .myi contém os índices. B) As tabelas Innodb usam o arquivos .frm para guardar as estruturas da tabelas e um "tablespace" com o nome default de ibdata0 que contém os dados de todas as tabelas e todos os índices. Para maiores informações leia Capítulo 7. Tipos de Tabela do MySQL

Então crie novos tópicos aqui neste forum. Tópico encerrado.

Poste na área do fórum referente a linguagem que você está programando. Veja: Programação & Desenvolvimento

Oi, 'hippy'! Seus índices estão errados. Qual tabela é o lado 1 do relacionamento 1:N entre compra e compra_venda? Este lado deverá "emprestar" seu atributo, que é chave primária, para a outra tabela. Nesta outra tabela (o lado N do relacionamento o atributo vindo da primeira tabela será a foreign key. Exemplo: Supondo que compra é o lado 1 do relacionamento, então id_compra deverá ser a chave primária desta tabela. Na tabela compra_venda você colocará o atributo id_compra e criará a foreign key com esta chave referenciando a tabela compra. Entendeu?

Oi, 'BetoGroo' ! Leia o artigo que escrevi para o site DVMedia, que publica a revista SQL Magazine, em 12/05/2008. Como fazer auto_increment em atributo em chave primária múltipla

Use DOUBLE ou CHAR. o MySQl converte dados CHAR para numericos, mas eu prefiro DOUBLE.

Oi, 'edersonnves' ! A melhor solução para isto não passa por um trigger. Passa por uma SP(Storage Procedure) ou por seu código na linguagem de programação que você usa.

Oi, 'Antonella'! Verifique se o atributo em questão (campo da tabela) ou a própria tabela foram criados usando a palavra reservada BINARY. Pois por default a pesquisa no MySQl é caso-insensitivo.Leia: 6.2.3.1. Os Tipos CHAR e VARCHAR 6.5.3. Sintaxe CREATE TABLE 1.8.3. Extensões do MySQL para o Padrão SQL-92 Não há erro na construção de seu SQL. Por padrão o ORDER BY é sempre ASC. Então, experimente retirar esta cláusula.

Oi, 'Guido Gabriel' Lembrando que uma pessoa pode ter quaisquer dos três papéis(Cliente, Adverso, paceiro) e um papel pode ser representado por qualquer pessoa, temos, então, um relacionamento muitos para muitos entre a tabela de domínio papel e pessoa. Um atributo que poderá entrar na tabela de relacionamento pessoa_papel é o da data ou número do processo em que a pessoa passou a representar aquele papel. Veja a modificação no DER em anexo: Pessoa.pdf

Oi, Guido Gabriel 1 - Sim, não vão ser sequenciais.2 - Não há nenhum problema quanto a isso. Você deve se lembrar que a sequencia estará na tebela pessoa, que é uma generalização, e as tabelas Pessoa_Fisica e Pessoa_Juridica, por serem filhas da tabela pessoa (especialização dela) estão ligadas por um relacionamento 1:1 e não tem necessidade de terem suas chaves sequenciais. O endereço foi colocado em tabela separada pois o relacionamento é muitos para muitos com pessoa. Uma pessoa pode ter endereço comercial, residencial, de faturamento, de entrega, etc. Assim como um endereço pode pertencer a mais de uma pessoa.

Tente isto SELECT CURRENT_DATE - INTERVAL 45 DAY; Ou istoSELECT DATE_SUB(CURRENT_DATE, INTERVAL 45 DAY);

Oi, 'Guido Gabriel' Você pensou correto quando quis colocar as tabelas em forma de generalização especialização. Mas errou na criação delas. Veja o modelo em anexo e dê sua opinião. Pessoa.pdf

'blood', Esta solução também é possível em MySQL.

'blood', Então o que você precisa é uma resposta parecida com a que dei para o 'BetoGroo'. Veja se assim funciona, pois eu não testei. SELECT P.Produtos_CDProduto AS CODIGO, PR.NMproduto AS PRODUTO, sum(IF(V.DTEmissao = (CURRENT_DATE-45), P.Produtos_NRQtd, 0) AS CONSUMO45, sum(IF(V.DTEmissao = (CURRENT_DATE-90), P.Produtos_NRQtd, 0) AS CONSUMO90 FROM SQLUser.CESproduto PR LEFT OUTER JOIN VENVenda_Produtos P ON P.Produtos_CDProduto = PR.Cdproduto LEFT OUTER JOIN SQLUser.VENVenda V ON V.ID = P.VENVenda GROUP BY P.Produtos_CDProduto ORDER BY PR.NMPRODUTO

Oi, 'blood'! Vamos corrigir o conceito. Você disse: O correto é "Joins ligam duas tabelas" O erro estava no uso incorreto da comparação do join. Veja se assim funciona: SELECT P.Produtos_CDProduto AS CODIGO, PR.NMproduto AS PRODUTO, sum(P.Produtos_NRQtd) AS CONSUMO45 FROM SQLUser.CESproduto PR LEFT OUTER JOIN VENVenda_Produtos P ON P.Produtos_CDProduto = PR.Cdproduto LEFT OUTER JOIN SQLUser.VENVenda V ON V.ID = P.VENVenda WHERE V.DTEmissao = (CURRENT_DATE-45) GROUP BY P.Produtos_CDProduto ORDER BY PR.NMPRODUTO

Oi, 'carlos12' ! Use a função TIMEDIFF Veja o manual do MySQL