Cita:
Iniciado por gnzsoloyo 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.
Si esa es una duda que tengo la verdad, y parece que es un debate generalizado.
Algunos dicen que conviene denormalizar para no hacer 12 JOINs, otros dicen que no es necesario ya que los JOINs no tardan nada, la verdad desconozco la realidad sobre la performance.
Cuando esté lista la BD voy a ver si puedo hacer algunos tests de los dos.
Cita:
Iniciado por gnzsoloyo 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.
Claro, pero mi idea es que entonces sean registros DIFERENTES. Es decir, si hay dos localidades con la calle Juan José Paso, entonces hay dos registros diferentes, que tienen el MISMO nombre de calle, pero que tienen una FK_Localidad diferente.
En esa situacion no veo un N:N, porque Juan José Paso va a tener una sola localidad, aunque haya 20 Juan José Paso, me parecio incluso que eso me daba mas libertad respecto a la calle, por ej. si algun dia en una localidad deja de llamarse Juan Jose Paso, yo cambio solo ese registro y no me modifica todas las otras localidades. Me permite ademas agregar información personalizada sobre cada calle, por ej. si en una ciudad Juan Jose Paso es avenida, y en otra Boulevard, o si en una localidad Juan Jose Paso es doble mano y en otra no, etc.
Yo lo pienso como cada calle tiene UNA localidad, si hay calles que se llaman igual es otro tema y creo no me perjudica en nada la tabla.
Pero a lo mejor no te estoy entendiendo bien. Si ves algún problema, por favor avisame asi no me explota todo mas tarde :(
Cita:
Iniciado por gnzsoloyo 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.
Ah pero eso para que sea geográfica no? como comentaba mas abajo la informacion geográfica la voy a tomar de Google. Mi tabla calles es solo para busquedas del usuario.
Es decir, si un usuario desea buscar alguna panaderia que esta en calle Belgrano, busco en mi tabla calles. Pero cuando tenga que mostrar la ubicacion en el mapa, busco con la API de Google.
Cita:
Iniciado por gnzsoloyo 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
Si? por qué? :S ahi me descolocaste por completo, los ejemplos que vi definen siempre POINT si van a usar POINT, que ventaja tendría usar el tipo padre?
Cita:
Iniciado por gnzsoloyo 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.
Si, me había fijado en eso, pero desde la version 5.0.16 MySQL soporta Geometry en InnoDB tambien:
http://dev.mysql.com/doc/refman/5.0/...xtensions.html
El tema esta con los indices, MySQL a los Geometry les mete un indice "SPATIAL", en InnoDB no puede, asique en InnoDB los campos GEOMETRY estan en mucha desventaja, porque muchos dicen que la real ventaja de tener un campo GEOMETRY es el indice SPATIAL, que permite hacer busquedas MUY rapidas en esos campos, y sobre todo con rangos (algo que los indices comunes no pueden cuando se usan rangos ni se por que).
De todas formas el campo POINT lo agregué medio por las dudas ni se si lo voy a usar todavia, fijate que incluso puse dos veces las coordenas, una en un campo POINT y tmb cree 2 campos, Decimal(12,8) para guardar las coordenadas por separado.
Cita:
Iniciado por gnzsoloyo 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.
Va a estar complicado, igual en principio prefiero dejarle el trabajo a Google que se lo va a hacer mejor que yo. Pero ahora que lo mencionas, no sería posible hacer un "scan" (mediante consultas) de la base de datos de Google?