Cita:
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 :(
Cita:
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.
Cita:
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.
Cita:
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...
Cita:
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?