Herencia de Tablas? (Que se recomienda para tablas similares?)

[enridp]

Hola a todos!
Que es lo que recomiendas las "reglas de oro del diseño en BD" para tablas muy parecidas?

Supongamos que tenemos distintos tipos de Usuarios, que en un diagrama de herencias representaría mas o menos asi:

usuarios
|---> comerciantes
.........|---> minoristas
.........|---> mayoristas
|---> profesionales


Es decir, hay usuarios que pueden a su vez ser comerciantes, los comerciantes tienen otros campos que no tienen los usuarios, pero comparten todos los campos de usuarios tambien.

Que me recomiendan?
creo una tabla Comerciantes que tenga TODOS los campos (los de los usuarios MAS los propios de comerciantes), o creo una tabla Comerciantes que solo tenga los campos extra de los comerciantes y una clave foranea al usuario asociado?

[Geometra]

Hola, yo separaria usuarios de las demas tablas. respecto a la herencia que comentas no se i el termino cabe pero te recomendaria buscar sobre "Generalizacion y Especializacion" y claro su cardinalidad.

[gnzsoloyo]

Que me recomiendan?
creo una tabla Comerciantes que tenga TODOS los campos (los de los usuarios MAS los propios de comerciantes), o creo una tabla Comerciantes que solo tenga los campos extra de los comerciantes y una clave foranea al usuario asociado?

Respetar el modelado de datos: Si tienes una estructura de herencia, es porque hay datos que no son comunes a las entidades hijas, ergo no puedes hacer un pastiche de campos en una sola tabla.
Cada entidad de la jerarquía es una tabla diferente. Siempre.
Básicamente, si no lo haces así, estarías desnormalizando la estructura de tablas, desperdiciando espacio de disco y creando un modelo de datos ineficiente.

[enridp]

Iniciado por Geometra

Hola, yo separaria usuarios de las demas tablas. respecto a la herencia que comentas no se i el termino cabe pero te recomendaria buscar sobre "Generalizacion y Especializacion" y claro su cardinalidad.

Hola Geometra, estuve leyendo sobre Generalizacion y Esppecializacion pero la verdad no me ayudo mucho, tengo conocimiento de OOP, lo que no se es como implementarlo correctamente en una BD (mas precisamente MySQL), y cuando conviene una u otra situacion, si fuese C++ no lo dudaria un segundo, crearia usuarios y heredaria a comerciantes, etc.

Iniciado por gnzsoloyo;

Básicamente, si no lo haces así, estarías desnormalizando la estructura de tablas, desperdiciando espacio de disco y creando un modelo de datos ineficiente.

Hola gnzsoloyo, para mi lo logico seria aplicar una estructura de herencia, pero eso en un lenguaje OOP, en Base de Datos desconozco que es lo que mas conviene a la larga, incluso no se como implementarlo tampoco.
Lo que se me ocurrio es hacer una Tabla USUARIOS, y otra COMERCIANTES, y en comerciantes poner un UsuarioID (clave foranea que apunte a USUARIOS).
Voy a abrir un tema en el foro de MySQL sobre esto porque me parece estoy haciendo lio.


Ya de entrada me esta dando miedo como me va quedando el diseño por normalizar tanto, te muestro lo que me quedo para agregar una simple direccion:



Asique por ejemplo si quiero obtener los Comercios de cierta ciudad supongo que voy a tener que hacer una consulta donde:
Busca las direcciones de los comercios en Comercios_has_Direcciones
Con esa direccion me fijo si tiene asociada alguna CalleConNumero o CalleConCalle
Con esa CalleConNumero me fijo la calle
Con esa calle me fijo la Localidad

De entrada no se me ocurre como hacerlo en menos de dos consultas (porque CalleConNumero y CalleConCalle me rompen un poco el esquema asique hasta ahi llego con INNER JOINS).

Pero ademas de eso, internamente supongo MySQL o el motor que sea tiene que pasar por 7 tablas. Asique ya ni se si es buena idea armar todo ese esquema o poner un campo CiudadID dentro de Comercios y listo.

[gnzsoloyo]

Bueno, analizando el modelo que propones:

hay algunas observaciones...
- Si tienes diferentes comercios que poseen sucursales y casa central, lo que tienes, en realidad es Dos entidades diferentes: Empresa, que contiene la información de la casa matriz y sus datos generales, y Sucursal, que contiene los atributos propios de ellas. Esa distinción puede que no la hayas visto porque estás planteando el modelo como una cadena de comercios, todos los cuales son iguales en cuanto a atributos por lo que lo único que los distingue es que hay al menos uno que no figura como sucursal en la tabla Comercios_has_comercio.

Pero lo que puede que no estés notando es que una cadena de comercios pertenecientes a la misma firma permite inferir la existencia de una entidad superior que contenga atributos que no son iguales a los de las sucursales, y que definen su existencia como firma comercial. Por ello estos casos se modelan con esas dos tablas mencionadas.

- Por otro lado, estás poniendo la dirección como una tabla relacionada, cosa que sólo tiene sentido si la vigencia de una dirección para una sucursal puede variar en el tiempo, de lo contrario, los atributos de esa tabla pertenecen en realidad a la tabla Sucursal, porque serían atributos propios de la instancia de Sucursal. Técnicamente, desde el punto de vista impositivo en mi país, cuando trasladas una sucursal a una distancia mayor a 500 metros (5 cuadras), se considera que estás abriendo una nueva, por lo que en esos casos hay que crear una intsancia diferente y por consecuencia los atributos de dirección no varían con el tiempo...

Como verás, depende de la realidad que estás modelando.

- Además de esto último, estás separando direcciones con calle y número de direcciones dadas por calle y calle (intersecciones o encuadramientos), y eso es una distinción irrelevante, porque toda dirección puede cumplir con ambas situaciones. No es necesario atomizar de esa forma los datos porque estás complicando demasiado la búsqueda y las consultas.

De hecho, es habitual que las direcciones en las bases de datos se almacenen con ambas cosas, para dar mayor certeza en la localización, así pues, deberías fusionar esos datos en la misma tabla .

- Una cosa que sí es un error manifiesto es poner a la localidad como atributo de una calle. Eso es irreal porque puede darse que una calle aparezca con los mismos números y mismas intersecciones en varias ciudades de un mismo país. Eso no lo puedes descartar.
En el caso de mi país, por ejemplo, Avenida Gral. San Martín, es una denominación de calle que aparece en casi todas las ciudades... por lo que no es discriminante de la ciudad. La ciudad o localidad es en realidad un atributo de la dirección, no de la calle.

Respecto al asunto de las herencias, te recomiendo ver algunos modelos que las manejan, para ver cómo se implementan:

[enridp]

Iniciado por gnzsoloyo

Bueno, analizando el modelo que propones:
hay algunas observaciones...
- Si tienes diferentes comercios que poseen sucursales y casa central, lo que tienes, en realidad es Dos entidades diferentes: Empresa, que contiene la información de la casa matriz y sus datos generales, y Sucursal, que contiene los atributos propios de ellas. Esa distinción puede que no la hayas visto porque estás planteando el modelo como una cadena de comercios, todos los cuales son iguales en cuanto a atributos por lo que lo único que los distingue es que hay al menos uno que no figura como sucursal en la tabla Comercios_has_comercio.

Pero lo que puede que no estés notando es que una cadena de comercios pertenecientes a la misma firma permite inferir la existencia de una entidad superior que contenga atributos que no son iguales a los de las sucursales, y que definen su existencia como firma comercial. Por ello estos casos se modelan con esas dos tablas mencionadas.

Si habia pensado en algo asi tambien pero se me ocurrió que ese modelo funcionaria bien para empresas "organizadas" como tal, muchas veces tengo comercios que son emppresas familiares o pymes muy chicas donde tienen 2 locales y a lo mejor no lo distinguen como Empresa y Sucursal...
Se me ocurrió que asi sería mas general, pero creo que tenes razon de ultima que elijan a alguno como Empresa y listo supongo.
Podrias mostrarme mejor como lo plantearias? armarias dos entidades? una Empresa y la otra Sucursal con los mismos atributos en cada una?
Porque en principio no se me ocurre que atributo diferencia a una casa central de una sucursal.

Iniciado por gnzsoloyo

- Por otro lado, estás poniendo la dirección como una tabla relacionada, cosa que sólo tiene sentido si la vigencia de una dirección para una sucursal puede variar en el tiempo, de lo contrario, los atributos de esa tabla pertenecen en realidad a la tabla Sucursal, porque serían atributos propios de la instancia de Sucursal. Técnicamente, desde el punto de vista impositivo en mi país, cuando trasladas una sucursal a una distancia mayor a 500 metros (5 cuadras), se considera que estás abriendo una nueva, por lo que en esos casos hay que crear una intsancia diferente y por consecuencia los atributos de dirección no varían con el tiempo...

Eso tambien lo hice por miedo a "quedarme corto". Se me ocurrió por ej. que un comercio podría tener mas de una dirección (tal vez si se puede acceder desde dos calles por ej. los supermercados con estacionamiento atras, o por ahi alguien que quiere aclarar que la direccion para hacer una consulta u otro tramite es en otro lado, o alguien que quiere poner una direccion alternativa, por ej. un profesional, no se).
Por otro lado, la direccion me quedaba con MUCHOS atributos como pudiste ver, y meterlos en la tabla "Comercios" a todos esos atributos me parecia una exageracion.
Lo estaré planteando mal?

Iniciado por gnzsoloyo

- Además de esto último, estás separando direcciones con calle y número de direcciones dadas por calle y calle (intersecciones o encuadramientos), y eso es una distinción irrelevante, porque toda dirección puede cumplir con ambas situaciones. No es necesario atomizar de esa forma los datos porque estás complicando demasiado la búsqueda y las consultas.

De hecho, es habitual que las direcciones en las bases de datos se almacenen con ambas cosas, para dar mayor certeza en la localización, así pues, deberías fusionar esos datos en la misma tabla .

Esto la verdad que me tuvo varias horas hasta que llegue a esa solucion horrible ya se :(
Esto fue lo que me imaginé:
El usuario (comerciante) entra, registra su comercio y cuando se le pide la direccion, le voy a mostrar las calles en una lista asi no escribe cualquier cosa.
Pero hay mucha gente que no pone Calle y Nro, sino que pone la interseccion, y hay mucha gente que pone las dos versiones, y otros que incluso ponen San Martin 123 (casi Alvear), esta situacion la contemple agregandole un campo "descripcion" a la tabla Direcciones (para que puedan poner mas texto, por ej: "es la puerta roja", "casi peatonal", etc.)
Pero como hago para permitir que pongan la Calle y el Numero y/o las dos calles?
Inicialmente se me habia ocurrido poner DENTRO de direcciones estos campos:
Calle1
Numero1
Calle2
Pero corria riesgo de que calle2 (o Numero1) me quede vacio muchas veces.
Podrias explicarme como fusionar los datos? yo no pude hacerlo :(

Iniciado por gnzsoloyo

- Una cosa que sí es un error manifiesto es poner a la localidad como atributo de una calle. Eso es irreal porque puede darse que una calle aparezca con los mismos números y mismas intersecciones en varias ciudades de un mismo país. Eso no lo puedes descartar.
En el caso de mi país, por ejemplo, Avenida Gral. San Martín, es una denominación de calle que aparece en casi todas las ciudades... por lo que no es discriminante de la ciudad. La ciudad o localidad es en realidad un atributo de la dirección, no de la calle.

Si yo tambien soy de Argentina, San Martin es infaltable ^_^
Yo lo pense al atributo que ppuse en la tabla Calles como: "Esta calle pertenece a la Localidad X"
Porque aunque San Martin esta en muchos lados, en algunos es Bvd, en otros Av. en otros solo calle.
Y aunque este en varias localidades, me interesaba que este repetido el nombre y distinguido con la Localidad. Mi objetivo es que el usuario elija su Localidad y en una lista le aparezcan TODAS las calles de esa localidad.
Está mal igual?

Iniciado por gnzsoloyo

Respecto al asunto de las herencias, te recomiendo ver algunos modelos que las manejan, para ver cómo se implementan:

Bueno esos estan mas completos que los que encontré. Pero mi duda no es en el diagrama, sino en la implementacion. Por lo que puedo verr en esos diagramas, y lo que encontre en internet (de hecho habia una respuesta tuya en este mismo foro sobre el tema ^_^), MySQL no soporta herencia (asique en el MySQL workbench tampoco hay como dibujarla), pero se implemente con claves foraneas como una relacion uno a uno y listo no?

[gnzsoloyo]

Podrias mostrarme mejor como lo plantearias? armarias dos entidades? una Empresa y la otra Sucursal con los mismos atributos en cada una?
Porque en principio no se me ocurre que atributo diferencia a una casa central de una sucursal.

Por empezar, una empresa, aunque posea como atributo solamente un nombre o razón social, requiere existencia como tabla independiente en la base de datos por el sólo hecho de estar representando una entidad del sistema completamente distinta a una sucursal.
Ese sólo hecho ya justifica su presencia, ya que no existe una sucursal que dependa de otra sucursal, pero si existen sucursales que dependen o pertenecen a una empresa. En ese contexto no importa si una instancia de empresa posee mas atributos qu eel nombre, la dirección y su ID... Es necesaria para el modelado del sistema y de la base.
En el mundo real hay muchos atributos que pertenecen a una empresa y que son heredados por la sucursal, tales como CUIT, inscripción a los Ingresos Brutos, Razón Social, etc., y muchos otros que parecen repetirse, como la dirección. La diferencia fundamental entre la dirección de una Empresa y una Sucursal es que en la Empresa dirección jurídica y física pueden no coincidir, pero en la sucursal si.
Como tienen forzosamente atributos distintivos, son tablas distintas y entidades del modelo diferentes. El que no puedas recordar puntualmente de memoria qué atributos las diferencia, no quiere decir que no existan, sino que no están relevados en el análisis del sistema.

Resumiendo: Son dos tablas diferentes con una cardinalidad 1:N, por lo cual la sucursal hereda la ID de la Empresa.

Se me ocurrió por ej. que un comercio podría tener mas de una dirección (tal vez si se puede acceder desde dos calles por ej. los supermercados con estacionamiento atras, o por ahi alguien que quiere aclarar que la direccion para hacer una consulta u otro tramite es en otro lado, o alguien que quiere poner una direccion alternativa, por ej. un profesional, no se).

Eso es un tema irrelevante. Los puntos de acceso físicos de una sucursal no componen direcciones de la misma. La dirección de una sucursal esta definida por su declaración ante el fisco y su habilitación ante el municipio. El resto son como mucho "oficinas" o "puntos de acceso " con habilitación, pero no son la dirección de la sucursal, y su registración puede coresponder a otro tipo de documentación que tiene que ver con la estructura física del bien mueble, no con la entidad Sucursal.

Por otro lado, la direccion me quedaba con MUCHOS atributos como pudiste ver, y meterlos en la tabla "Comercios" a todos esos atributos me parecia una exageracion.
Lo estaré planteando mal?

Trata de llegar a los atributos mínimos necesarios: Calle, Numero, Barrio, Entre_Calle Altura_C1, Y_Calle, Altura_C2, Localidad, Provincia, Pais, etc.
Si tuviese muchos accesos, y esa situación fuese una constante de las sucursales, podrías analizar si necesitas una tabla de Accesos_A_Sucursal.

El usuario (comerciante) entra, registra su comercio y cuando se le pide la direccion, le voy a mostrar las calles en una lista asi no escribe cualquier cosa.
Pero hay mucha gente que no pone Calle y Nro, sino que pone la interseccion, y hay mucha gente que pone las dos versiones, y otros que incluso ponen San Martin 123 (casi Alvear), esta situacion la contemple agregandole un campo "descripcion" a la tabla Direcciones (para que puedan poner mas texto, por ej: "es la puerta roja", "casi peatonal", etc.)
Pero como hago para permitir que pongan la Calle y el Numero y/o las dos calles?
Inicialmente se me habia ocurrido poner DENTRO de direcciones estos campos:

No mezcles las cosas: Esto no es un problema de la base de datos, sino de la aplicación. Es allí donde se resuelve, aunque para ello necesites consultar a la base de datos, por ejemplo, para poner listados de Ciudad, desde la cual puedes hacer un listado de calles, etc. El ehcho de obligar a los usuarios a poner las cosas en un cierto orden y en una forma precisa, es asunto de la aplicación.

Porque aunque San Martin esta en muchos lados, en algunos es Bvd, en otros Av. en otros solo calle.
Y aunque este en varias localidades, me interesaba que este repetido el nombre y distinguido con la Localidad. Mi objetivo es que el usuario elija su Localidad y en una lista le aparezcan TODAS las calles de esa localidad.
Está mal igual?

Eso lo tienes que resolver, como dije, en la aplicación. La base sólo guarda datos ya validados. No tiene por qué hacer validaciones. Los lenguajes de programación tienen mñas capacidades para esa tarea.

Respecto de la implementación de la herencia, los gráficos que te pasé ya te lo expresan.
Una entidad hereda a otra cuando no tiene PK propia, sino que usa la de la entidad superior.
Si tuviesen un ID propio, o necesitasen otro atributo para definir su PK, sería una relación y no herencia...

[enridp]

Iniciado por gnzsoloyo

Resumiendo: Son dos tablas diferentes con una cardinalidad 1:N, por lo cual la sucursal hereda la ID de la Empresa.

Si, te entiendo y estoy de acuerdo pero no se si se aplica bien a mi modelo entonces, o tal vez la aplicación está mal encarada :S
Me explico un poco mejor a ver si podes ver donde estoy haciendo lio (o tal vez para este caso si esta bien asi).
Mi idea es que la tabla guarde información util para el usuario, por eso desde ese punto de vista decidí saltearme algunos aspectos "técnicos o legales".
Supongamos un servicio similar al de las Páginas Amarillas. Me gustaría que si alguien (un profesional o comercio) desea poner varias direcciones (por ej. un albañil que señala dos posibles lugares donde encontrarlo, etc), pueda hacerlo, lo mismo un comercio, más allá del domicilio que figure en la AFIP.
Todo el sistema está orientado a la consulta del usuario y a brindarle información a este.
Con respecto a las sucursales, mi idea era que si un usuario por ej. busca una Heladeria, y esa heladería tiene otros locales en otros lugares (tal vez incluso con diferentes dueños si por ej. es una franquicia), que pueda figurar como "sucursal" esas otras heladerías. Lo mismo tal vez con las diferentes agencias de Movistar, etc.
No se que tan bien va a resultar, se me ocurrió en principio que si dos comercios tienen diferentes "dueños" entonces antes se deberia enviar una solicitud de permiso para poder colocarlo como "sucursal". En esos casos incluso tal vez ni siquiera habría "casa central".
No se si me estoy explicando bien :(
Mi objetivo es simplemente que si un usuario entra una heladeria, pueda ver las sucursales de esa heladeria tambien, y desde el punto de vista de un comercio, el comerciante que publica, que pueda indicar tambien todos sus otros locales si tiene mas de uno (o si tiene algun convenio o acuerdo con otros...)

Iniciado por gnzsoloyo

Trata de llegar a los atributos mínimos necesarios: Calle, Numero, Barrio, Entre_Calle Altura_C1, Y_Calle, Altura_C2, Localidad, Provincia, Pais, etc.

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)


Originalmente como te comentaba yo habia hecho un planteo similar, no tenia las tablas CalleConCalle ni CalleConNumero, y dentro de Direcciones tenia
Calle
Numero
Y_Calle
El problema era que con ese diseño probablemente me hubiese quedado en muchas filas el atributo "Y_Calle" como NULL, y tambien 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?

Iniciado por gnzsoloyo

Eso lo tienes que resolver, como dije, en la aplicación. La base sólo guarda datos ya validados. No tiene por qué hacer validaciones. Los lenguajes de programación tienen mñas capacidades para esa tarea.

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.
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.
Asique dentro de la tabla Calles le pongo a que Localidad pertenece.
Pero bueno, es la primera vez que armo una BD tan grande y de este tipo asique no tengo ni idea, si pudieses indicarme como ordenarlo mejor me sería de gran ayuda.

Iniciado por gnzsoloyo

Una entidad hereda a otra cuando no tiene PK propia, sino que usa la de la entidad superior.

Perfecto! mas claro imposible, gracias!

[gnzsoloyo]

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.

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.

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.

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).

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.

[enridp]

Iniciado por gnzsoloyo

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.

si, los rubros tengo pensado agragarlos, pero no lo habia planteado como herencia, mi idea con los rubros era la siguiente:
Crear una tabla rubros (que a su vez se relaciona con si misma porque un rubro puede tener muchos subrubros). Y despues Crear una relacion N:M con los comercios (porque un rubro puede estar en muchos comercios y un comercio puede tener muchos rubros).

Con el tema de los usuarios, si habia pensado una herencia, como la que puse en el primer post de este tema.
O sea hay usuarios, comerciantes (que a su vez son usuarios), profesionales, etc.

No entiendo bien lo de la tabla extra que mencionas, para incluir Empresa, Unipersonal, etc. Cual seria el objetivo de la tabla?
Mi objetivo principal es que el usuario pueda encontrar lo que busca de la forma mas eficaz y eficiente posible. Por eso pensaba que si busca "hamburguesas" que busque tanto empresas como McDonalds y carritos de venta ambulante en la calle.
Igual tengo un cagazo terrible de meter la pata y que despues me complique la vida, porque nunca hice algo asi. Por eso es que pregunto tanto :(

Iniciado por gnzsoloyo

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.

Ah esta bien, ya entendí. Pero me parece que excede mis necesidades, esto va a enfocado a una ciudad mas bien chica, pero el mayor inconveniente que vi yo con eso es que estaría saturando al comerciante que quiere registrar su comercio (todos sabemos lo molesto que es rellenar formularios) y tal vez tamben al usuario brindando demasiado información. La dirección va acompañada ademas de las coordenadas de google, asique va a haber un mapa. Y cada direccion tiene un campo de texto para poder aclarar mas detalles (por ej. si es una casa del fondo, o bien eso que decis, la ubicacion de las dos calles adyacentes).
Mi problema con el diseño es la ambigüedad que hay en una misma dirección.
Porque un comerciante puede decidir poner como direccion:
"San Martin y Belgrano"
Otro puede poner:
"San Martín 103"
Otro tal vez incluso:
"Belgrano 709"
y otro tal vez quiera las 3 versiones.
Todas son la misma dirección pero se pueden poner de distinta forma. Y el problema esta SOBRE TODO en que son campos distintos, asique no puedo armar la misma tabla para los 2 tipos de calle, es decir uno es VARCHAR+INT y el otro es VARCHAR+VARCHAR, por eso me quedaron las tablas CalleConCalle y CalleConNumero.
Si me podes guiar para arreglar mejor ese despelote me seria de gran ayuda porque en todos los "patrones de diseño" que encontré lo hacen MUY simple, ponen un campo de texto con "calle" y listo, incluso permiten que el usuario escriba la calle, y tambien la ciudad etc.
Yo voy a usar los campos de direccion para busquedas, asique no puedo permitir que alguno escriba Bvd San Martin, otro Boulevard San Martín, que algun burro o descuidado escriba Velgrano, etc.
Y necesito poder buscar las dos versiones de la direccion, porque el usuario que busca puede poner: San Martin 103 o puede poner San Martin y Belgrano, y en los dos casos debe encontrar el comercio.

Iniciado por gnzsoloyo

Decir que dejar un atributo como NULL es malo, es en la realidad una exageración de la ortodoxia.

Si estoy de acuerdo, la verdad que creo me quedaria mucho mas simple el modelo si pongo algo como esto:
Calle (no puede ser null)
Numero (puede ser null)
Y_Calle (puede ser null)
En lugar de dos tablas separadas.
Que te parece? estara bien asi o ves algun problema en ese diseño? o sea quedaria:
ANTES:

AHORA:


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.

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.

Iniciado por gnzsoloyo

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.

Pero por que dices que es una relacion N:N la que tengo con las calles y las localidades? yo lo plantee como una relacion 1:N
Cada calle puede tener solo una localidad, y cada localidad puede tener muchas calles. Está mal planteado asi? me podria generar problemas tu dices?
A mi ya de entrada me asusta un poco en que va a terminar esa tabla "calles"
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...

Iniciado por gnzsoloyo

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.

Claro, estuve viendo algunos modelos de datos geográficos, no son nada faciles y hay que cargarlos MUY bien. Tienen eso que mencionas, las alturas de inicio y fin de la calle.
Pero creo que me explota la cabeza si hago algo asi. Por eso yo pensé hacer esto:
Tengo mi propia tabla Calles, donde solo guardo el nombre de la calle y una FK a la localidad que pertenece (estaba pensando tambien guardar sinonimos de la calle, o errores ortograficos comunes, para la busqueda).
Esa tabla calles no la uso para una referencia geográfica sino para una búsqueda del usuario.
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?

[gnzsoloyo]

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...

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.

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:

mysql> SELECT ID, NOM_CALLE, FROMLEFT, TOLEFT, FROMRIGHT, TORIGHT, CODIGO, CFCC
    -> FROM calle c
    -> WHERE NOM_CALLE LIKE '%O DIAZ%';
+------+--------------+----------+--------+-----------+---------+--------+------+
| ID   | NOM_CALLE    | FROMLEFT | TOLEFT | FROMRIGHT | TORIGHT | CODIGO | CFCC |
+------+--------------+----------+--------+-----------+---------+--------+------+
| 1817 | AVELINO DIAZ |      400 |    498 |       401 |     499 |  70491 | A41  |
| 1818 | AVELINO DIAZ |      500 |    598 |       501 |     599 |  70491 | A41  |
| 1819 | AVELINO DIAZ |      600 |    698 |       601 |     699 |  70491 | A41  |
| 1820 | AVELINO DIAZ |      700 |    798 |       701 |     799 |  70491 | A41  |
| 1821 | AVELINO DIAZ |      800 |    898 |       801 |     899 |  70491 | A41  |
| 1822 | AVELINO DIAZ |      900 |    998 |       901 |     999 |  70491 | A41  |
| 1823 | AVELINO DIAZ |     1000 |   1098 |      1001 |    1099 |  70491 | A41  |
| 1824 | AVELINO DIAZ |     1100 |   1148 |      1101 |    1149 |  70491 | A41  |
| 1825 | AVELINO DIAZ |     1150 |   1198 |      1151 |    1199 |  70491 | A41  |
| 1826 | AVELINO DIAZ |     1200 |   1298 |      1201 |    1299 |  70491 | A41  |
| 1827 | AVELINO DIAZ |     1300 |   1358 |      1301 |    1359 |  70491 | A41  |
| 1828 | AVELINO DIAZ |     1360 |   1398 |      1361 |    1399 |  70491 | A41  |
| 1829 | AVELINO DIAZ |     1400 |   1428 |      1401 |    1429 |  70491 | A41  |
| 1830 | AVELINO DIAZ |     1430 |   1448 |      1431 |    1449 |  70491 | A41  |
| 1831 | AVELINO DIAZ |     1450 |   1468 |      1451 |    1469 |  70491 | A41  |
| 1832 | AVELINO DIAZ |     1470 |   1498 |      1471 |    1499 |  70491 | A41  |
| 1833 | AVELINO DIAZ |     1500 |   1548 |      1501 |    1549 |  70491 | A41  |
| 1834 | AVELINO DIAZ |     1550 |   1598 |      1551 |    1599 |  70491 | A41  |
| 1835 | AVELINO DIAZ |     1600 |   1698 |      1601 |    1699 |  70491 | A41  |
| 1836 | AVELINO DIAZ |     1700 |   1798 |      1701 |    1799 |  70491 | A41  |
| 1837 | AVELINO DIAZ |     1800 |   1898 |      1801 |    1899 |  70491 | A41  |
| 1838 | AVELINO DIAZ |     1900 |   1998 |      1901 |    1999 |  70491 | A41  |
| 1839 | AVELINO DIAZ |     2000 |   2098 |      2001 |    2099 |  70491 | A41  |
| 1840 | AVELINO DIAZ |     2100 |   2198 |      2101 |    2199 |  70491 | A41  |
| 1841 | AVELINO DIAZ |     2200 |   2298 |      2201 |    2299 |  70491 | A41  |
| 1842 | AVELINO DIAZ |     2300 |   2398 |      2301 |    2399 |  70491 | A41  |
| 1843 | AVELINO DIAZ |     2400 |   2498 |      2401 |    2499 |  70491 | A41  |
| 1844 | AVELINO DIAZ |     2500 |   2598 |      2501 |    2599 |  70491 | A41  |
| 1845 | AVELINO DIAZ |      300 |    398 |       301 |     399 |  70491 | A41  |
+------+--------------+----------+--------+-----------+---------+--------+------+
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:

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.

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.

[enridp]

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.

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 :(

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.

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?

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.

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?

[gnzsoloyo]

¿Desnormalizar o JOINs?
La desnormalización se usa en OLAP, pero desnormalizar para evitar JOINs tiene un costo adicional: Hay que mantener consistencia por programación... Con lo que solamente es recomendable estudiarla si la base es estable y no sufrirá modificaciones ulteriores.

¿Registros diferentes para cada calle de cada ciudad?
Si, perfectamente, siempre que tengas en cuenta que debe abarcar la totalidad de la información necesaria, como por ejemplo, las alturas de todos los segmentos que lo componen, en ambas veredas, como mínimo. De lo contrario te podrán direcciones inexistentes (trata de encontrar Avenida Santa Fe 1256 en Córdoba... Queda debajo del puente, en medio del río Suquía).
SI no va a tener un mínimo de detalle necesario, es mejor implementar un mapeo desde Google que te devuelva el punto que el usuario te señale.

¿Usarla solamente para las calles por el usuario?
A mi entender eso sería más sencillo con una simple consulta a GoogleMap con el nombre de la calle. Usando un HttpRequest se obtiene la información perfectamente.
Por otro lado, si sólo invocas las direcciones de la Capital Federal tienes 2144 nombres, entre calles y avenidas. Intenta imaginar cuántas sería entre las calles y avenidas de las cinco principales ciudades, nada más.
Personalmente me parece poco funcional si no es en localidades pequeñas, o a través de un prefiltrado.

¿Latitud y Longitud irrelevantes?
SI. Porque cuando aplicas a un campo geometrico que guarda un POINT las funciones X() e Y(), te devuelve esos mismos valores, así que en realidad los estás guardando dos veces. Y cualquier cosa que guardes dos veces, también tienes que mantenerla dos veces...

¿POINT o GEOMETRY?
GEOMETRY te permite poner cualquier cosa adentro, no solamente puntos, y en cuanto a uso en disco no hacen mucha diferencia en el tipo de datos..
Por otro lado, si no usas indices SPATIAL, en realidad se desperdicia bastante la capacidad otorgada a los GEOMETRY.

¿Hacer un "scan" a google maps?
Si encuentras el modo...
Google no te da acceso a la base de datos, solamente responde consultas puntuales, y en todo caso puede que logres ir construyendo tu inteligencia de negocios por medio de sucesivas consultas, pero no vas a poder escanear las tablas...
A ellos les lleva tiempo crear los mapas. Tampoco te regalan el paquete completo.

[enridp]

Iniciado por gnzsoloyo

¿Registros diferentes para cada calle de cada ciudad?
Si, perfectamente, siempre que tengas en cuenta que debe abarcar la totalidad de la información necesaria, como por ejemplo, las alturas de todos los segmentos que lo componen, en ambas veredas, como mínimo. De lo contrario te podrán direcciones inexistentes (trata de encontrar Avenida Santa Fe 1256 en Córdoba... Queda debajo del puente, en medio del río Suquía).
SI no va a tener un mínimo de detalle necesario, es mejor implementar un mapeo desde Google que te devuelva el punto que el usuario te señale.

Si es cierto, el sistema planteado solo guarda los nombres no las alturas asique no puede controlar ese dato de por si, y es susceptible a que introduzcan mal una altura.
Pero eso ya corre por cuenta del que registra la dirección, si cuando mandas una carta por correo pones mal la direccion tambien llega mal.
Tal vez sería util para el usuario una advertencia en todo caso si se equivoca al colocar el numero pero creo que el beneficio no alcanza a cubrir el costo en ese caso.

Iniciado por gnzsoloyo

¿Usarla solamente para las calles por el usuario?
A mi entender eso sería más sencillo con una simple consulta a GoogleMap con el nombre de la calle. Usando un HttpRequest se obtiene la información perfectamente.

Pero un HTTpRequest de google andaria muchisimo mas lento que una consulta directa a la BD, ademas de que no tengo tanto control, incluso algunos pueblos chiquitos no estan en Google.
Buscando en mi tabla calles puedo por ej. poner sinonimos o errores comunes de las calles, a veces hay nombres raros que la gente escribe mal, a veces hay calles que cambiaron de nombre y la gente la sigue llamando con el nombre viejo, etc. Tener mi propia tabla tiene miles de ventajas respecto a Google.
Solo que Google tiene informacion geografica imposible de armar para mi, asique para eso si no me queda otra me parece.

Iniciado por gnzsoloyo

Por otro lado, si sólo invocas las direcciones de la Capital Federal tienes 2144 nombres, entre calles y avenidas. Intenta imaginar cuántas sería entre las calles y avenidas de las cinco principales ciudades, nada más.

Si, eso es lo que te comentaba que me austaba un poco, el tamaño que tendría la tabla, pero tal vez me asombro yo porque nunca trabaje con tantos datos, Facebook trabaja con 400millones de usuarios, no creo que llegue a 400millones de calles. Y el filtrado sería por localidad, la columna nombre es un indice asique supongo que filtrando la FK por localidad y usando el indice en 2144 no deberia ser un problema para la BD.
El problema es cargar esos 2144 nombres... pero supongo las municipalidades tienen una base de datos con las calles que podria pedir.

Iniciado por gnzsoloyo

Personalmente me parece poco funcional si no es en localidades pequeñas, o a través de un prefiltrado.

En principio si es para localidades pequeñas, pero la idea es que sea escalable.
Como implementarias el sistema entonces?
La idea de las direcciones es la siguiente:
1) Informar al usuario la direccion, o direcciones si tiene varias de un comercio, profesional, etc.
2) Permitir que un usuario busque comercios por dirección, esto incluye que ponga una calle, una calle y un numero, o 2 calles q se intersectan.

Iniciado por gnzsoloyo

¿Latitud y Longitud irrelevantes?
SI. Porque cuando aplicas a un campo geometrico que guarda un POINT las funciones X() e Y(), te devuelve esos mismos valores, así que en realidad los estás guardando dos veces. Y cualquier cosa que guardes dos veces, también tienes que mantenerla dos veces...

Si, fue intencional la doble entrada, porque quiero probar si me conviene tener POINT o el valor decimal y listo.

Iniciado por gnzsoloyo

¿POINT o GEOMETRY?
GEOMETRY te permite poner cualquier cosa adentro, no solamente puntos, y en cuanto a uso en disco no hacen mucha diferencia en el tipo de datos..
Por otro lado, si no usas indices SPATIAL, en realidad se desperdicia bastante la capacidad otorgada a los GEOMETRY.

Si eso lei, por eso no estoy seguro bien que hacer, la otra alternativa era crear la tabla esa como MyISAM, pero necesito las FK, podria controlarlas a mano en esa tabla, supongo es una opcion si usar POINT se vuelve trascendental.
La otra opción que pensé es que podria crear una COPIA de la tabla en MyISAM, asi tendria dos tablas iguales una con InnoDB que controla la FK y la otra que le copia todo a la de InnoDB pero esta en MyISAM para hacer las busquedas ahi.
Es muy loca la idea?
De todas formas los indices SPATIAL aceleran las busquedas es cierto, pero tener un valor POINT puede resultar util mas alla de las busquedas, ya que permite por ejemplo hacer calculos de distancias entre puntos, o reconocer si un punto esta dentro de una zona, etc. las funciones siguen andando...

Iniciado por gnzsoloyo

¿Hacer un "scan" a google maps?
Si encuentras el modo...
Google no te da acceso a la base de datos, solamente responde consultas puntuales, y en todo caso puede que logres ir construyendo tu inteligencia de negocios por medio de sucesivas consultas, pero no vas a poder escanear las tablas...
A ellos les lleva tiempo crear los mapas. Tampoco te regalan el paquete completo.

La verdad no tengo ni idea, fue solo algo que se me cruzó, me imaginé que si tenemos los nombres de las calles podemos recorrer cada calle con todas las alturas posibles mediante consultas a Google y ver que coordenadas nos da en cada caso.
Pero sea como sea, Google tiene la ventaja que para este caso si buscaría mas rapido que mi tabla, incluso aunque se tenga que hacer otro HTTPRequest.

[cheloc]

Hola gnzsoloyo, eso que decís es un disparate, la mayoría de las bases de datos son relacionales y se manejan con criterios de normalización según el Modelo entidad relación (MER), cuando trabajas con POO, se usan técnicas ORM(te recomiendo leer un poco) para compatibilizar un BD relacional por ejemplo MySql con un sistema orientado a objetos en donde la normalización no es un factor preponderante y todo se basa según que criterio de bajada de jerarquía utilices.

Sds.