É errado ter preços em tabela diferente dos produtos? Claro que não, vou te explicar.

Não é necessariamente errado ter uma tabela de produtos e outra de preços, mas é importante avaliar se isso é a melhor abordagem para o seu projeto de banco de dados.

Normalmente quando iniciava um projeto já usava essa abordagem, pois é normal lá na frente encontrarmos clientes que necessitam de preços diferentes para o mesmo produto, então para evitar esse cenário ou ter que lidar com mais esse problema recorrente, em meus projetos sempre inicio com produtos em uma tabela, preços em outras e uma terceira tabela chamada "Tabelas".

Vantagens de ter tabelas separadas:

Flexibilidade

Se o seu sistema precisa de diferentes tipos de preços (por exemplo, preço de atacado, preço de varejo, promoções, etc.), uma tabela separada facilita a gestão desses cenários.

Para gerenciar isso crio uma tabela chamada "Tabelas".

id_tabela (chave estrangeira para a tabela de produtos)
nome da tabela (para saber que tipo de preços são esses a tabela ex: atacado, varejo, promocional, natal)
data_inicio (opcional, caso queira ter uma data para tornar a tabela em uso)
data_fim (opcional, caso queira registrar quando o preço deixou de ser válido)
ativa (aqui coloco em uso ou não a tabela)

Histórico de Preços

Se você deseja manter um histórico de variação de preços ao longo do tempo, ter uma tabela separada é uma prática comum. Cada mudança de preço seria registrada com data de início e fim da validade. Sempre que for existir alterações no preço, você pode criar uma nova tabela e então aplicar o aumento, assim você fica com o histórico dos preços anteriores para eventuais pesquisas.

Exemplo de tabela "Preços":

id_tabela ( chave para referenciar na tabela "Tabelas"
id_produto (chave para referenciar na tabela de produtos)
preco

Quando não é necessário ter uma tabela separada

Se o preço de um produto raramente muda ou se você não precisa manter o histórico, pode ser mais simples manter o preço como uma coluna dentro da tabela produtos, essa é uma abordagem que apesar de não ser errada, não costumo utilizar para evitar um grande retrabalho no futuro, quase sempre, para não dizer sempre os clientes precisam de múltiplas tabelas de preços, tive problemas com isso diversas vezes.

Exemplo de tabela de Produtos:

id_produto
nome_produto
preco

As afirmações são corretas

Use tabelas separadas quando precisar de histórico de preços, diferentes tipos de preços, ou se houver uma frequente variação de preços.
Use uma única tabela quando o preço for estático e não precisa de histórico.

Conselho do Bom

Sei que conselho bom não existe, mas minha vida de programador foi facilitada e ganhei muito mais tempo ao trabalhar com meus projetos com múltiplas tabela, normalmente os clientes precisam e já está lá disponível para eles, às vezes eles nem precisavam, mas isso foi um diferencial que os fizeram adotar essa política de preços.

Existem outras abordagens para preços que são bem legais e garantem muito mais liberdade para o cliente, quem sabe em outro artigo abordo esse assunto.

Boa programação!