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

[IMAC/]

Buenas

Es una cuestión meramente de concepto.

Que es mejor desde un punto de vista relacional en bases de datos. Crear 2 tablas con los mismos campos a excepción de uno, o crear una sola tabla y diferenciar los 2 conceptos mediante ese campo.

Me explico:
Tengo una tabla "Menus" y otra tabla "Categorias".
Toda categoria tiene asignado un menú.

La duda es, si crear 2 tablas:

Menu: (id, nombre, posicion);
Categorias: (id, nombre, posicion, idPadre, idMenu); //donde idPadre es la categoria padre, o 0 si no tiene padre e idMenu la relación con su menu.



O bien una sola:
Categorias_y_menus(id, nombre, posicion, idPadre)

//Donde idPadre haría referencia al id de la misma tabla, que puede que sea un menú o una categoria. Diferenciando ambos porque todo menú tendría idPadre a 0 o a null.


Gracias.

[gnzsoloyo]

Que tenga los mismos campos no implica que tenga los mismos datos.
Esto significa que por más que dos objetos distintos contengan conjuntos de datos del mismo tipo en cuanto a columnas de tabla, no significa que sean objetos iguales si los datos, a nivel de información, son diferentes.
Sería mejor que primero nos dijeses qué es una Categoría y qué es un Menú, y qué información contiene cada uno.

[IMAC/]

Bueno, pensé que se podía sobreentender con los campos.
La información que almacenan en campos iguales es la misma en este caso.

El id, es el id.
El nombre, es un texto varchar de similares longitudes.
El campo posicion, un numero.
El campo idPadre un id haciendo refernecia a otra tabla.


Saludos.

[gnzsoloyo]

Bueno, pensé que se podía sobreentender con los campos.
La información que almacenan en campos iguales es la misma en este caso.

El id, es el id.
El nombre, es un texto varchar de similares longitudes.
El campo posicion, un numero.
El campo idPadre un id haciendo refernecia a otra tabla.

No me estás entendiendo. Eso son los tipos de columna. Lo que te pregunto es qué es un Menu y qué es una Categoría en cuanto a objetos, cosas, información.

Si un Menú contiene ID, Denominación, Ubicación, una Categoría podría tener ID, Jerarquía y Rango. En ese contexto, estaríamos ante tipos de columna iguales y datos totalmente incompatibles...
A eso me refiero. Para relacionar dos conceptos diferentes, deben tener puntos de relación y no me queda claro solamente con los nombres, de qué estás hablando. Necesito entender un poco qué es lo que estás haciendo para saber qué te conviene hacer. Sino estamos hablando en el aire, al menos en tu caso.

¿Se comprende la idea?

[IMAC/]

Iniciado por gnzsoloyo

No me estás entendiendo. Eso son los tipos de columna. Lo que te pregunto es qué es un Menu y qué es una Categoría en cuanto a objetos, cosas, información.

Si un Menú contiene ID, Denominación, Ubicación, una Categoría podría tener ID, Jerarquía y Rango. En ese contexto, estaríamos ante tipos de columna iguales y datos totalmente incompatibles...
A eso me refiero. Para relacionar dos conceptos diferentes, deben tener puntos de relación y no me queda claro solamente con los nombres, de qué estás hablando. Necesito entender un poco qué es lo que estás haciendo para saber qué te conviene hacer. Sino estamos hablando en el aire, al menos en tu caso.

¿Se comprende la idea?

Ok.

Un menú acabaría plasmándose de manera que fuera un menú horizontal en un página y que permitira acceder a las categorias de cada menú tras un link en cada elemento del menú.
Cada registro en la tabla menu sería un elemento en el menú, con su nombre, su posición con respecto a los demás elementos del menú (1º, 2º...etc)
Demo:
-------------------------------------------------------------
|Elemento1 | Elemento2| Elemento3| Elemento4 |
-------------------------------------------------------------

En la tabla categorias se guardaría todas las categorias de todos los menús.
Cada categoria (cada registo en la BD) con la información necesaria para mostrar un menú de categorias verticalmente (tipo lista).

Demo del Elemento1 del anterior menu:
-Categoria1
---Categoria 1.1
---Categoria 1.2
-Cateogria2
---Cateogoria 2.1
------Categoria 2.1.1
------Categoria 2.1.2
---Categoria 2.2
-Categoria 3

No se si me he explicado bien.
Saludos.

[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.