Ver Mensaje Individual
  #9 (permalink)  
Antiguo 12/07/2010, 06:12
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?)

Vamos por parte de lo que me planeas.
- El modelo que estabas pensando originalmente podría funcionar, aunque no muy eficientemente, para en caso como el que planteas. Digo no muy eficientemente, porque deberás incluir alguna tabla de categorías de Empresa, para determinar si son unipersonales, sociedades de hecho, o registradas en AFIP, o algo así. De ese modo podrías separar por tipos los inscriptos y no mezclar a la sucursal de Burger King con Carlos Fuentes, medio oficial albañil, por dar un ejemplo.
Pero lo mejor sería crear una estructura de herencia de usuarios registrados que separe mejor todo, incluyendo no sólo categorizaciones, sino también rubros en el caso tanto de comercios como de servicios, empresas, etc. Ya que muchos de ellos no tendrán sucursales, sino direcciones, tal como lo planteabas originalmente.
A mi entender, ese sería el mejor enfoque para tu caso.
Cita:
Entonces tu propones que borre las tablas "CalleConCalle" y "CalleConNumero" y que dentro de Direcciones ponga:
Calle
Numer
Entre_Calle (esto que es? :S)
Altura_C1 (no seria esto igual a "Numero"?)
Y_Calle
Altura_C2 (dos alturas? se puede dar este caso? yo no lo tuve en cuenta)
Altura_C1 y AlturaC_2, lo puse para que pusieras la altura de la calle 1 y la altura de la calle 2, considerando que son las alturas correspondientes a la manzana inmediata adyacente a la dirección donde está el comercio o sucursal en cuestión.
Sería decir: Bv. San Juan 158, entre Bv. Chacabuco alt. 400 y Obispo Salguero alt. 400, Ciuda de Córdoba.
Cita:
El problema era que con ese diseño probablemente me hubiese quedado en muchas filas el atributo "Y_Calle" como NULL, y también en muchas otras el atributo "Numero" como NULL. Y como en las reglas de diseño que lei decia que eso era malo trate de buscar una alternativa.
En este caso tu convienes no obviar las reglas y aceptar esos atributos como NULL?
Decir que dejar un atributo como NULL es malo, es en la realidad una exageración de la ortodoxia. En la práctica descubres que ciertos valores necesitas que se puedan definir como NULL para facilitar ciertas búsquedas; el NULL, en ese sentido, es un no-valor de mucha utilidad.
En tu caso, el hecho que esa tabla contenga valores NULL en la calle te te define que la búsqueda sea de una u otra forma. Te puede permitir presentarle advertencias al suscriptor que sus datos están incompletos, etc. Además, el hecho de que sea DEFAULT NULL facilita la carga de datos en las cargas masivas, porque hay una restricción menos que verificar...
La ortodoxia es buena, pero tampoco hay que exagerar, y de todos modos, no hay nada que impida, en el modelo E-R que un atributo pueda ser o no NULL. Incluso, de esa forma ecitas duplicidad de estructuras y simplificas todas las consultas que se te hubiesen complicado al tener que resolver el discriminante de si tiene o no dirección con calle y numero.

Cita:
Es que tengo miedo de abstraerme demasiado de la aplicación y que a la hora de necesitar los datos sea todo un infierno y pierda eficiencia por no haber hecho las cosas más compatibles.
En realidad, si no haces una buena abstracción harás que la base sólo pueda funcionar con una única aplicación, y que toda modificación en la aplicación pueda requerir modificaciones en la base.
Eso sí es un error.
Una de las primeras cosas que te dicen cuando se empieza a estudiar en profundidad el modelado de bases, en la facultad es precisamente que la base de datos debe ser completamente independiente de la aplicación, para permitir, precisamente, migrar la aplicación sin necesidad de tener que modificar la base. Eso no sólo le dará continuidad a la base, sino que además le otorga flexibilidad, ya que en ese caso se vueve capaz de responder cualquier consulta que se le haga (dentro de los límites de la información almacenada).


Cita:
De todas formas sigo sin entender como relacionarías las Localidades con las Calles.
Yo la pensé así la relación:
Las Localidades tienen muchas Calles.
Las calles pertenecen a una Localidad.
Acabas de responderte a ti mismo, sin darte cuenta: Eso es lo que se denomina "relación N:N", y por definición, también, una relación N:N genera una tabla en el modelo de datos.
O sea: Tienes una tabla adicional con las PK de la localidad y del nombre de la calle, cuyos atributos pueden ser, por ejemplo, las alturas que tienen vigencia (AltInicio, AltFinal), por ejemplo.
En los hechos eso es una base de datos geográfica, y se trata de algo mucho más extenso y complejo para usar. Puede que resulte demasiado complicado, aunque se puede lograr. ERl problema lo tendrás para obtener las tablas de datos que alimenten esas dos, por lo que es un tema que hay que estudiar.
Y creo que tal vez se pueda resolver interactuando con GoogleMaps para visualizar las localizaciones y obtener los datos, o bien con algún otro servicio 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)