¿Cómo diseñar DB con relaciones padre-hijo?

Question

Si tuviera que representar, por ejemplo, ubicaciones (por ejemplo, países, estados/provincias/regiones, ciudades, etc.) en una base de datos, ¿cómo lo haría de modo tal que sería más fácil consultar, escalar el máximo , etc.? Planeo usar esto para una aplicación que permitirá a los usuarios seleccionar múltiples ubicaciones y asociarlas a su perfil.

La solución que viene a la mente es la siguiente:

=========================== 
| Id | ParentId | Name | 
=========================== 
| 1 | 0  | USA  | 
--------------------------- 
| 2 | 1  | Alabama | 
--------------------------- 

Me pregunto si hay cualquier problema potencial con una solución de este tipo. Gracias.

Answer 1

Si conoce los diferentes tipos de artículos (países de estado de la ciudad), debe crear tablas separadas. Ponerlos todos en una sola tabla hará que sea más difícil consultarlos.

Si utiliza diferentes tipos de tablas, puede aplicar integridad referencial para que no quede huérfano.

¡Piensa en los niños!

Answer 2

Esto parece bastante adecuado para la escalabilidad, pero podría incluir una columna adicional para identificar la fila/entrada real (tipo de entidad, si lo desea).

Esto le permitirá realizar consultas fácilmente en función de la selección (país, ciudad, etc.). Sin embargo, puede descubrir que la hiracrchy puede causarle un poco de dolor, ya que toda la estructura estará en una sola mesa, y no conoce la profundidad para comenzar.

Al final, el diseño dependerá de la cantidad de sub secciones conocidas que pueda tener, y si dicha normalización de hecho podría hacer la vida más difícil, en lugar de no hacerlo.

Answer 3

Uso algo similar y he tenido mucho éxito con él. Un reciente Question of mine puede ser útil.

En algunos casos (como este) no quiero estar atado a una estructura de tabla. La autorreferencia puede ser una gran cosa. No entiendo por qué es tan aceptable tener estructuras parecidas a un árbol usando el mismo tipo de objeto en el código, pero los programadores lo evitan cuando se trata de bases de datos.

Answer 4

Dependiendo de su público, también puede considerar separar los valores de nombre por tipo para que puedan ser localizados sin duplicar la estructura jerárquica.