Claro que vai escalar. Isso funcionará muito bem, é uma estrutura comumente usada.

Incluir um level_no . Isso ajudará no código, mas, mais importante, é necessário excluir duplicatas.

Se você quer uma estrutura realmente rígida, você precisa de algo como o conceito Unix de inodes.

Você pode ter dificuldade em entender o código necessário para produzir a hierarquia, digamos, de um product , mas isso é uma questão separada.

E por favor mude

• (product_category )) id para product_category_id
• (product id para product_id
• parent_id para parent_product_category_id

Respostas a comentários

1. 
   level_no . Dê uma olhada neste modelo de dados, é para uma estrutura de árvore de diretórios (por exemplo, a janela do FlieManager Explorer):
   
   Modelo de dados do diretório
   
   Veja se você pode entender isso, esse é o conceito de inode do Unix. Os FileNames devem ser exclusivos dentro do Node, daí o segundo Index. Isso está realmente completo, mas alguns desenvolvedores hoje em dia terão um chilique escrevendo o código necessário para navegar na hierarquia, nos níveis. Esses desenvolvedores precisam de um level_no para identificar em que nível na hierarquia eles estão lidando.
   
2. 
   Alterações recomendadas. Sim, é chamado de boas convenções de nomenclatura. Sou rígido em relação a isso e o publico, portanto, é um padrão de nomenclatura. Existem razões para isso, que ficarão claras para você quando você escrever algum SQL com 3 ou 4 níveis de junções; especialmente quando você vai para o mesmo pai de duas maneiras diferentes. Se você pesquisar SO, encontrará muitas perguntas para isso; sempre a mesma resposta. Também será destaque no próximo modelo que escrevo para você.