Hacer 2 tablas, o mantenerlo en una con un campo indicador

[gnzsoloyo]

Bueno, ahora recién se entiende de qué estabas hablando.
Personalmente nunca le encontré sentido a crear una tabla para almacenar los componentes de un menú de una aplicación, pero eso es algo que los programadores sabrán por qué lo hacen. No importa.

En este contexto, cualquiera de las dos opciones puede ser válida: Usar una tabla a la que convendría poner un nombre más mnemotécnico como Componentes_Menues; o bien usar dos tablas, una para menúes y otra para SubMenúes (que eso es lo que son, "categorías" lleva a la confusión porque suena a otra cosa).
El tema es así:

- Si usas una tabla para menúes, la tabla de categorías debe llevar dos campos importantes: Un ID propio y un campo FK referido a la tabla de menúes.
- Si usas una sola tabla, debe llevar sólo un FK apuntando a la misma tabla, a la PK del registro del menú (no lo veo práctico).

En cualquiera de los dos casos, por tu ejemplo, tienes un problema adicional: Tienes que poner tantos FK como niveles para resolver las subcategorías en árbol que estás planeando, o bien crear una lógica recursiva que te permita administrar la secuencia de lectura del conjunto entre Menú>CategoriaNivel1>CategoriaNivel2>CategoriaNive l3.
Desde ya te digo, ese tipo de consulta será bastante complicada y no sé que tan bien podrás crear una que te devuelva en una tabla, el esquema completo de ese árbol.

En esencia: A pesar de la complejidad de lo que planteas, yo te sugiero que uses una sola tabla y que pongas sólo dos campos importantes: PK de tabla y FK apuntando a la raiz del nivel.
Usar dos tablas solamente hará que la lógica recursiva se aplique a una de las tablas, pero no evitará tener que usarla.
No le veo otra alternativa.

Suerte con tu proyecto.