Tema: Herencia de Tablas? (Que se recomienda para tablas similares?)
Ver Mensaje Individual
  #11 (permalink)  
Antiguo 13/07/2010, 07:04
Avatar de gnzsoloyo
gnzsoloyo
Moderador criollo
  
Fecha de Ingreso: noviembre-2007
Ubicación: Actualmente en Buenos Aires (el enemigo ancestral)
Mensajes: 23.324
Antigüedad: 16 años, 5 meses
Puntos: 2658
Respuesta: Herencia de Tablas? (Que se recomienda para tablas similares?)
Cita:
No entiendo bien lo de la tabla extra que mencionas, para incluir Empresa, Unipersonal, etc. Cual seria el objetivo de la tabla?
Ese sería el caso en que usaras una sola tabla de usuarios, sin herencia. La categoría te permitiría derivar el tipo de consultas a realizar, de la misma forma en que lo harías usando herencia.
Pero sólo sería válido si no vas a usar datos distintos para cada categoría de usuario. No perdamos de vista que si hay diversos tipos de usuario, que poseen atributos comunes y otros que son distintivos, eso es una jerarquía y estamos hablando de herencia...

Cita:
El unico problema es que deberia obligar de alguna forma a que la direccion este completa SIEMPRE, porque "calle" no puede ser null, pero Numero y "Y_Calle" si, asique no se como ponerle la restriccion para que no puedan ser AL MISMO tiempo Y_Calle y Numero NULL.
Esto es algo que en realidad lo manejas en la aplicación. El formulario puede diseñarse para que ante el uso de determinados TextBox otros se desactiven o se activen. Además, incluso puedes hacer que sólo se habilite tras comprobaciones a la base automáticas, etc.
En muchas ocasiones, lo que necesitas es cargar ciertas tablas por default, las que se usan para alimentar los ComboBox donde se coloquen las opciones, y esos combos permitan listar otras tablas donde se seleccionen los datos en forma encadenada.
En cualquier caso, son cosas para la aplicación. Lo importante es ver que cuando los datos vayan a la base, ya estén definidas las validaciones.

Cita:
Leyendo un poco vi que hay patrones de diseño que rompen las reglas, sobre todo de normalización, que era lo que comentaba tambien antes, mi miedo a que para llegar a un simple dato tengo que pasar por 12 tablas antes.
O un JOIN de varias...
No te desesperes anticipadamente; una consulta compleja tarda menos que doce consultas separadas. Y es más optimizable. Ponele fe al diseño de la base... Los DBMS tienen resueltas muchas cosas antes de que las pienses.



Está mejor, pero yo sigo insistiendo que no puedes plantearte una tabla calles de esa forma sin una relación N:N con localidad, porque si bien una calle física pertenece a una única localidad, una calle Juan José Paso, sin más datos puede pertenecer a unas 1.000 localidades diferentes. Para que sea una relación N:1 con Localidad, la tabla debería ser capaz de entregar esta info:
Código MySQL: 
Ver original
  1. mysql> SELECT ID, NOM_CALLE, FROMLEFT, TOLEFT, FROMRIGHT, TORIGHT, CODIGO, CFCC
  2.     -> FROM calle c
  3.     -> WHERE NOM_CALLE LIKE '%O DIAZ%';
  4. +------+--------------+----------+--------+-----------+---------+--------+------+
  5. | ID   | NOM_CALLE    | FROMLEFT | TOLEFT | FROMRIGHT | TORIGHT | CODIGO | CFCC |
  6. +------+--------------+----------+--------+-----------+---------+--------+------+
  7. | 1817 | AVELINO DIAZ |      400 |    498 |       401 |     499 |  70491 | A41  |
  8. | 1818 | AVELINO DIAZ |      500 |    598 |       501 |     599 |  70491 | A41  |
  9. | 1819 | AVELINO DIAZ |      600 |    698 |       601 |     699 |  70491 | A41  |
  10. | 1820 | AVELINO DIAZ |      700 |    798 |       701 |     799 |  70491 | A41  |
  11. | 1821 | AVELINO DIAZ |      800 |    898 |       801 |     899 |  70491 | A41  |
  12. | 1822 | AVELINO DIAZ |      900 |    998 |       901 |     999 |  70491 | A41  |
  13. | 1823 | AVELINO DIAZ |     1000 |   1098 |      1001 |    1099 |  70491 | A41  |
  14. | 1824 | AVELINO DIAZ |     1100 |   1148 |      1101 |    1149 |  70491 | A41  |
  15. | 1825 | AVELINO DIAZ |     1150 |   1198 |      1151 |    1199 |  70491 | A41  |
  16. | 1826 | AVELINO DIAZ |     1200 |   1298 |      1201 |    1299 |  70491 | A41  |
  17. | 1827 | AVELINO DIAZ |     1300 |   1358 |      1301 |    1359 |  70491 | A41  |
  18. | 1828 | AVELINO DIAZ |     1360 |   1398 |      1361 |    1399 |  70491 | A41  |
  19. | 1829 | AVELINO DIAZ |     1400 |   1428 |      1401 |    1429 |  70491 | A41  |
  20. | 1830 | AVELINO DIAZ |     1430 |   1448 |      1431 |    1449 |  70491 | A41  |
  21. | 1831 | AVELINO DIAZ |     1450 |   1468 |      1451 |    1469 |  70491 | A41  |
  22. | 1832 | AVELINO DIAZ |     1470 |   1498 |      1471 |    1499 |  70491 | A41  |
  23. | 1833 | AVELINO DIAZ |     1500 |   1548 |      1501 |    1549 |  70491 | A41  |
  24. | 1834 | AVELINO DIAZ |     1550 |   1598 |      1551 |    1599 |  70491 | A41  |
  25. | 1835 | AVELINO DIAZ |     1600 |   1698 |      1601 |    1699 |  70491 | A41  |
  26. | 1836 | AVELINO DIAZ |     1700 |   1798 |      1701 |    1799 |  70491 | A41  |
  27. | 1837 | AVELINO DIAZ |     1800 |   1898 |      1801 |    1899 |  70491 | A41  |
  28. | 1838 | AVELINO DIAZ |     1900 |   1998 |      1901 |    1999 |  70491 | A41  |
  29. | 1839 | AVELINO DIAZ |     2000 |   2098 |      2001 |    2099 |  70491 | A41  |
  30. | 1840 | AVELINO DIAZ |     2100 |   2198 |      2101 |    2199 |  70491 | A41  |
  31. | 1841 | AVELINO DIAZ |     2200 |   2298 |      2201 |    2299 |  70491 | A41  |
  32. | 1842 | AVELINO DIAZ |     2300 |   2398 |      2301 |    2399 |  70491 | A41  |
  33. | 1843 | AVELINO DIAZ |     2400 |   2498 |      2401 |    2499 |  70491 | A41  |
  34. | 1844 | AVELINO DIAZ |     2500 |   2598 |      2501 |    2599 |  70491 | A41  |
  35. | 1845 | AVELINO DIAZ |      300 |    398 |       301 |     399 |  70491 | A41  |
  36. +------+--------------+----------+--------+-----------+---------+--------+------+
  37. 29 rows in set (0.02 sec)
Esto está tomado de una base de datos geográfica. Cada registro es una calle, pero como verás, en este caso no hay altura 0 - 300, simplemente porque no existe en esa localidad (70491 es el ID de la localidad).
Es decir, para que sea funcional debe tener al menos esa info; por eso decía que meterse con esos detalles puede volverse algo complicado.

Detalle: Latitud y longitud, así como coordenadas, son irrelevantes si pones un campo geométrico. Por otro lado, el campo defínelo como GEOMETRY. Es lo que corresponde. El que le pongas adentro un POINT es tema aparte
Pero te advierto que si lo pones en esa tabla no podrás luego ponerle FK, porque los campos geométricos sólo existen en las tablas MyISAM.

Detalle 2:
Cita:
Porque en la tabla "Calles" voy a guardar TODAS las calles de TODAS las localidades, y cada calle tendra su FK a la localidad que pertenece. Pero me asusta que quede un chorizo enorme esa tabla, aunque tal vez es normal no se...
SI consigues eso gratis (incluyendo el campo GEOMETRY de cada una), por favor publícalo... Todos lo necesitamos, y la inmensa mayoría de esa información no se consigue sin pagarla.


Cita:
La referencia Geográfica (para mostrar la ubicacion en mapa por ej, o calcular distancias etc.) la voy a sacar de las coordenadas de Google, y que la API de google maps haga el trabajo dificil.
Tu crees que funcionara asi?
Es la mejor forma.
Yo utilizo mucho Google Maps, y es una de las mejores y más eficientes formas de resolver los problemas de georeferenciación.
__________________
¿A quién le enseñan sus aciertos?, si yo aprendo de mis errores constantemente...
"El problema es la interfase silla-teclado." (Gillermo Luque)