Este caso específico é sobre listas e itens.

O mesmo item pode pertencer a várias listas e cada lista possui muitos itens.

Opção A (da maneira "correta" como eu a entendo): Faça uma tabela de junção, que tenha list_ID e item_ID. Quando eu quero todos os itens em uma consulta de lista para list_ID.

Opção B (quebre a regra de atomicidade): Faça uma tabela de lista. Chave primária e colunas repetidas ou não atômicas. Pelo que entendi, esses dois desvios sofrem exatamente as mesmas desvantagens, que é a incapacidade de consultar ineficientemente os itens.

Pelo que entendi, normalizar um banco de dados para NF-1 seria garantir que cada coluna seja atômica, por isso NÃO devo fazer a opção B. O motivo é que dificultaria a consulta dos itens. Por exemplo, "quantos itens foram vendidos" ou "quantas vezes esse item está em uma lista"

Acho que nunca precisarei desses dados (isso já é um erro / armadilha comum? Existe um meme entre engenheiros de banco de dados experientes como "você sempre desejará poder consultar e não terá tempo para reorganize o banco de dados quando você dimensiona "? Estou superestimando quanto tempo leva o MySQL para verificar uma tabela de junção?

Não consigo encontrar nada para apoiar isso, mas, ao mesmo tempo, considero bom senso aceitar esse formulário não compatível se souber que a desvantagem não é importante para o aplicativo. Mas eu não sou especialista e essas regras foram escritas por especialistas.