Diseñar una tabla SQL con jerarquía/subcategorías

Question

Tengo una tabla que se parece a esto:

ID | Palabra clave | Categoría | Subcategoría | Sub-subcategoría | Sub-Sub-Subcategoría

¿Tengo que dividirlo en dos tablas (una tabla de palabras clave y una tabla de categorías con el ID padre) si una palabra clave solo puede pertenecer a una categoría, subcategoría ... etc. lo que significa que no hay repetición. ¿Todavía hay una necesidad de dividirlo?

Answer 1

Solo necesita una tabla para representar una asignación de 1-1. Para representar mapeos de 1-muchos o muchos, debe usar varias tablas.

Si una palabra clave solo puede corresponder a una categoría/subcategoría/subcategoría, su diseño actual debería estar bien.

Una advertencia: si desea buscar en base a la palabra clave, podría haber mejoras en el rendimiento para separar las tablas. Es mucho más rápido realizar una búsqueda entera.

La discusión sobre el almacenamiento de los valores de palabras clave en otra tabla corresponde grosso modo a this discussion de almacenamiento de nombres de países (que son principalmente estáticos) en otra tabla. Algunas ventajas clave del uso de otra tabla pueden ser cosas como independencia del lenguaje (hablado), búsqueda rápida y facilidad de actualización más adelante.

Answer 2

Usaría dos mesas como esta.

Categories 
------------------- 
PK,FK1 | CategoryID 
     | Keyword 
     | Category 

    SubCategories 
-------------------- 
PK,FK1 | CategoryID 
PK,FK1 | SubCategoryID 

Answer 3

Podría tener sentido para dividirlo si esperas para cambiar el nombre o reorganizar sus categorías más tarde:

• si lo deja como está, va a tener que hacer eso de cambio de nombre/reorganice el paso (cambiando los campos de categoría/subcategoría/sub-subcategoría/sub-sub-subcategoría) para cada fila de esta tabla que contenga esa ((sub) sub) subcategoría. que da como resultado una consulta más compleja, y si tiene muchas filas en esta tabla de palabras clave, podría ser un problema de rendimiento (= demore un poco para que la base de datos lo haga); por otro lado, las consultas (lectura) serán lo más rápidas posible.
• si lo divide, la actualización ((sub) sub) sub) categoría solo se realizará con menos filas, pero la consulta (lectura) llevará más tiempo porque tiene que trabajar con dos (o más) tablas .

sopesar los pros y los contras de ambos y luego hacer una decision.m

Answer 4

¿Por qué no añadir una columna ParentID y el FK a la PK?

Answer 5

lo haría en dos mesas con cada clave externa procedente de la tabla Categorías:

Keywords 
id (PK) 
keyword 
category_id (FK) 

Categories 
category_id (PK) 
category 
parent_category_id (FK) 

Los datos en la tabla de categorías se vería así:

category_id category parent_category_id 
1    Food  null 
2    meat  1 
3    organic  1 
4    fruit  3 

y que los datos de la tabla de palabras clave se vería así:

id  keyword category_id 
1  grapes  4 
2  chicken 2