01/03/2005, 03:00
| ||||
| ||||
| buscar en varias tablas no relacionadas Hola a todos. Tengo una BD con varias tablas. Algunas de estas tablas son: "pisos", "aticos" y "chalets". Basicamente tienen los mismos campos, pero estan en tablas distintas porque cada una de ellas tiene sus particularidades. Por ejemplo, un campo comun a todas es "precio". Mi pregunta es: ¿como puedo hacer un unico SELECT en el que me devuelva todos los pisos, aticos y chalets que valgan menos de 150000 (por ejemplo)? Las tablas no estan relacionadas. Muchas gracias. |
|
01/03/2005, 09:17
| ||||
| ||||
| muy simple, no puedes. Para hacer lo que quieres vas a tener que hacer 3 select, una a cada tabla
__________________ Cuando creas que no hay solución posible, busca en los foros, siempre en mejor tener a la red mundial de tu parte |
|
01/03/2005, 11:13
| ||||
| ||||
| En ms sql server podrías hacer el siguiente procedimiento almacenado que te devolvería lo que pides: ALTER PROCEDURE Procedimiento1 (@precio int) as select campo1,campo2 ... from chalets where precio< @precio union select campo1,campo2 ... from pisos where precio< @precio union select campo1,campo2 ... from aticos where precio< @precio Teniendo en cuenta que la relación de campos de las select tiene que ser la misma para todas las tablas y del mismo tipo. Si no trabajas con ms sql server supongo que se podrá hacer de una forma similar. Espero que te sirva de algo. Salu2. |
|
01/03/2005, 13:01
| |||
| |||
| A mí esto me interesa, pues tengo la misma situación que el que abre el tópic, sedinho, en mi base de datos: tablas diferentes para ciertos elementos "comunes", pero con características distintas. ¿Alguien recomienda alguna forma distinta de diseñarlo? ¿O no es tan grave el tener tablas separadas para elementos distintos, pero que tienen un denominador común (en el caso de sendinho, podrían englobarse como "construcciones" o "casas")? Es decir, qué recomendáis: tablas separadas y programar las consultas y las introducciones de datos como sea, o diseño distinto de la base de datos (en este caso, cuál). |
|
02/03/2005, 02:08
| ||||
| ||||
| yo lo que haria seria crear dos tablas detalle (que unan dos tablas) es decir crear una tabla paraunir 2 de tus 3 tablas y luego crear otra tabla para unir la tabla ue te queda con otra cualquiera de las dos. O puede crear una sola tabla q una a tus 3 tablas
__________________ Cuando creas que no hay solución posible, busca en los foros, siempre en mejor tener a la red mundial de tu parte |
|
02/03/2005, 03:34
| ||||
| ||||
| Vamos a ver. Como veo que el post da más de si de lo que pensaba os comento la situación entera (a ver si asi ayudo en algo a un_tio y damos más respuestas). En la BD tengo una tabla "propietarios" y las tres tablas que puse en el primer post: "pisos", "aticos" y "chalets". Estas tablas entre otros campos tienen los siguientes comunes: - "id_piso", "id_atico", "id_chalet" --> en funcion de que tabla sea - "codigo" --> es una cadena formada por "letra"-"id". Es decir, cuando guardo un piso meto en el campo "codigo" la letra "p"+"-"+"id_piso". Ejemplos: codigo= "p-130" ó "a-50" ó "c-122"... Asi si quiero puedo buscar directamente un inmueble a través de su codigo independientemente de si es un piso, chalet o ático, ya que me creo un formulario en el que el usuario introduce el codigo y en php separo la cadena y se en que tabla he de buscar (p-130 he de buscar en la tabla pisos el id_piso=130) Para poder llevar un control de los inmuebles que tiene cada propietario en vez de meter un campo mas en cada tabla con el "id_propietario" decidí crear una tabla intermedia llamada posesiones, con los siguientes campos: id_posesion id_propietario cod_inmueble Así si quiero ver que inmuebes tiene un propietario no he de buscar en las tres tablas (pisos, aticos y chalets), basta con buscar en esta. Bien, esta es mi propuesta de diseño. No se si es correcto, pero es la forma mas optima que se me ha ocurrido (si ha alguien se le ocurre otra estoy abierto a todas las posibilidades). Espero que esta idea le valga a un_tio. El problema de este diseño es el siguiente. Si alguien quiere buscar cualquier inmueble (piso, chalet o atico) por un criterio especifico (precio, localidad...) deberia hacer una consulta a cada tabla. Hasta aqui no hay problema. El problema es que si quiero paginar estos resultados. Hasta ahora usaba el fantastico script PAGINATOR de jpinedo para paginar, pero como para conseguir los resultados de esta busqueda he de hacer 3 SELECT, el PAGINATOR no me sirve. De ahí que preguntase en mi primer post si se puede hacer un SELECT a tres tablas no relacionadas, a lo que el amigo yeti respondio rapidamente que no (gracias por destrozar mi moral   )Ahora mismo voy a escribir a jpinedo (se ha ofrecido a ayudarme en su pagina) a ver que me dice de usar PAGINATOR con 3 SELECT. Cuando tenga una respuesta suya os lo comento. Si alguien cree que puede aportar algo mientras tanto bienvenido sea. Bueno gente, esto es todo por ahora. Gracias por seguir este ladrillo de post hasta el final.  |
|
02/03/2005, 04:43
| ||||
| ||||
| Mi opinión es que hay un error de diseño de base. ¿Para qué tres tablas (piso, chalet, ático)?, ¿tan diferentes son que no se pueden poner en una única tabla?. inmueble: id, descripción, tipo, ... donde el campo tipo indica si es piso, chalet, ático, adosado, pareado, ... de esta forma no tienes que romperte la cabeza para hacer la consulta pues está todo en una tabla y no pierdes ninguna información ni posibilidad de uso. Cuando se hace un diseño, hay que hacer también un ejercicio de abstracción. Un saludo.
__________________ Estoy contagiado de Generación-I Última edición por Vice; 02/03/2005 a las 04:44 |
|
02/03/2005, 06:37
| ||||
| ||||
| La base de datos es un poco más compleja de lo que se describe aquí. De hecho tambien hay otro tipo de inmuebles (locales, naves industriales, solares...) y creeme, tienen suficientes diferencias como para tener que crear tablas distintas. Cuando empece a realizar el diseño me plantee usar una sola tabla con todos los campos necesarios para cubrir las necesidades de cada inmueble, pero me di cuenta que asi se desaprovechaba muchos recursos ya que salia una tabla con unos 60 campos de los caules habia muchos que no se utilizaban mas que para un tipo concreto de inmueble. Se que esto es enrevesar un poco el diseño, pero creo que es la forma mas limpia: cada tipo de inmueble su tabla con sus caracteristicas. Asi no se usa mas de lo que se necesita. Esta es mi opinion (que puede estar equivocada). Agradeceria tambien que la gente opinase sobre este planteamiento: ¿que es mejor varias tablas con los campos justos o una tabla con todos los campos necesarios para cubrir las necesidades de cada tipo de inmueble? |
|
02/03/2005, 11:17
| ||||
| ||||
| Lo que dice Vice es cierto... hay que tratar de abstraer lo más posible... En bases de datos existe un tema llamado "especialización-generalización" que es análogo a la herencia entre clases (en orientación a objetos). En este caso, las tres tablas sí pueden tener una relación (indirecta) a través de un padre común. Un tabla "Inmueble" que tiene todos los campos comunes de todos los inmuebles: ******************************* + INMUEBLE: ---------- - id_inmueble (PK) (FK) - tipo_inmueble (PK) - provincia (campo común a todos) - precio (campo común) - más campos comunes. ***************************** el id_imueble es una clave foránea (FK) que es primaria en la tabla específica ( id_piso, id_atico, etc). el tipo_inmueble es un indicador del tipo de inmueble y sirve para discriminar registros. (también para acelerar las búsquedas) (¿piso?, ¿atico?, etc). Ambos campos componen la clave primaria. Luego, ya haces las otras tablas específicas, que serán hijas de INMUEBLE: ***************************** + PISO: ----- - id_piso (PK) - campo propio 1 - Más campos propios ************************ + ATICO: ----- - id_atico (PK) - campo propio 1 - Más campos propios ***************** Ahora ya tienes las tablas relacionadas. Las lecturas son más fáciles y rápidas, pero las escrituras son un poco más lentas. ¿Por qué? - Antes tenías que hacer tres consultas a tres tablas para poder resolver tu problema. Ahora sólo harás una consulta a una tabla. Ganas muchísimo al leer! - Antes para registrar un nuevo inmueble simplemente lo agregabas a una tabla. Ahora vasa a tener que escribir en dos tablas, en una, registras el inmueble específico y en otra los campos comunes. Pierdes un poco. Esto SIEMPRE va a pasar, si quieres ganar velocidad de lectura, perderás de escritura y viceversa). ****************************** Y ahora puedes tener la información común en una solo resultset, con lo que podrás utilizar cualquier script de paginación. saludos  Última edición por jpinedo; 02/03/2005 a las 11:19 |
|
02/03/2005, 11:32
| |||
| |||
| yeti, tu solución no me parece nada óptima. sedinho, dos cosas sobre tu diseño: -No tiene sentido crear una id_posesiones, ya que la clave primaria puede ser el conjunto de id_propietario y cod_inmueble. -No les pones un denominador común. ¿Cómo harías para buscar entre "todas" las tablas? Haciendo buscar en las tres que sabes, quizá eso es aplicable en tu caso porque sabes que no van a haber más, pero no en el mío, en el que puede crecer (y lo que hago es nombrar a las tablas con un código delante del nombre). jpinedo: tu forma de hacerlo es la que pensé. Una duda: ¿el id de inmueble no podría ser común para todos los pisos, y que por tanto sus ids fueran claves foráneas de esta otra? (te ahorrarías el campo "tipo_inmueble"). |
|
02/03/2005, 11:35
| ||||
| ||||
| Cita: Yo con esto haría un ejercicio aún mayor de abstracción y no haría una tabla más para cada uno con los datos adicionales, sino una única tabla que tenga una fila por cada característica adicional
Iniciado por jpinedo Luego, ya haces las otras tablas específicas, que serán hijas de INMUEBLE: ***************************** + PISO: ----- - id_piso (PK) - campo propio 1 - Más campos propios ************************ + ATICO: ----- - id_atico (PK) - campo propio 1 - Más campos propios ***************** inmuebles_plus (id_inmueble, caracteristica, valor). Ventajas: siempre obtendrás los datos exactamente de la misma manera. Si aparece una nuevo tipo de inmueble no tienes que hacer nada, sólo registrarlo. Desventajas: en lugar de una fila para todas las características adicionales, te devolvera tantas filas como adicionales tengas. Un saludo.
__________________ Estoy contagiado de Generación-I Última edición por Vice; 02/03/2005 a las 11:39 |
|
02/03/2005, 11:47
| ||||
| ||||
| Cita: No entiendo muy bien... ¿podrías poner un ejemplo?
Iniciado por un_tio Una duda: ¿el id de inmueble no podría ser común para todos los pisos, y que por tanto sus ids fueran claves foráneas de esta otra? (te ahorrarías el campo "tipo_inmueble"). Cita: Yo no estoy de acurdo con ese nivel pues se perdería mucho sentido semántico de los campos. Y te planteo una duda :¿Qué tipo de dato le pondrías al campo 'valor'?.
Iniciado por vice Yo con esto haría un ejercicio aún mayor de abstracción y no haría una tabla más para cada uno con los datos adicionales, sino una única tabla que tenga una fila por cada característica adicional inmuebles_plus (id_inmueble, caracteristica, valor). Saludos |
|
02/03/2005, 11:50
| ||||
| ||||
| Me alegra que haya tanta participación. La idea de jpinedo era otra de las que estaba valorando. Ahora que veo que hay gente que la apoya la estudiare mas detenidamente a ver que sale. Gracias a todos por vuestra colaboracion  |
|
02/03/2005, 20:35
| |||
| |||
| A mi también me gusta la de jpinedo; una tabla con los campos camunes a todas ej id_inmueble, precio, localidad, provincia, foto, descripcion, titulo, tipo_inmueble; y luego si las tablas particulares de cada tipo con su correspondiente clave foranea que sería id_inmueble. |
|
02/03/2005, 21:59
| |||
| |||
| Cita: Quedaría esto, modificando la tabla que tú pusiste:
Iniciado por jpinedo No entiendo muy bien... ¿podrías poner un ejemplo? + INMUEBLE: ---------- - id_inmueble (PK) - provincia (campo común a todos) - precio (campo común) - más campos comunes. Y luego, para un caso concreto como PISO: + PISO: ----- - id_piso (PK) (FK) - campo propio 1 - Más campos propios ¿Se entiende? PISO, ÁTICO, etc., compartirían el mismo "autonumérico". Te ahorras el campo de "tipo_inmueble", pues poniendo la id, ya sabes si es piso, ático, etc., pues no hay dos id's iguales entre estas tablas. Yo creo que la esencia de las clases (subclases, etc.) es así, aunque la verdad es que puede resultar más complicado de programar. __________________________________________________ ____________ Cambiando a otra cosa: Otra opción, usando tu forma, podría ser: (SEGUNDA FORMA DE HACERLO) + INMUEBLE: ---------- - id_inmueble (PK) (FK) - tipo_inmueble (PK) - provincia (campo común a todos) - precio (campo común) - más campos comunes. Y en "tipo_inmueble", poner el nombre de la tabla del inmueble (por ejemplo: "piso", etc. Me gustaría saber si existe algo parecido a "Foreign key" pero que apunte no hacia un campo, sino hacia el título de otra tabla). La verdad es que esta segunda forma puede resultar liosa si se intenta lo del foreign key (si no no, es simplemente coger un nombre, da igual que sea eltítulo de otra tabla o no). __________________________________________________ ____________ Otra cosa, TERCERA FORMA: Esto me lo aconsejó Vice: consistiría en hacer "los prototipos" de las tablas, con características comunes, por un lado, y por el otro, la serialización (o poner id's de elementos concretos). Sería algo así como definir las características de un PISO_MODELO1, tener una tabla con estas características definidas, y después que cada piso concreto apuntara a ello (se supone que ahorraríamos memoria). Lo otro que dice Vice, que ya me lo dijo en otro tópic, de crear una tabla donde se van añadiendo nuevas características, no creo que sea la mejor opción... la verdad es que puede resultar, pero no parece para nada una base de datos bien estructurada, y no sé si más adelante podría resultar lioso. |
|
02/03/2005, 22:38
| ||||
| ||||
| Hola: Siempre que diseñas una base de datos tienes que pensar en el tipo de consultas a las que se va a someter en su vida útil. O sea, si la operación de lectura(consulta) es la que va a primar y muy pocas veces (o muy pocos usuarios) van a actualizar/insertar datos... entonces no importará redundar porque lo que se intenta es ganar velocidad de acceso de lectura... aunque se pierda rendimiento a la hora de escribir. En el primer caso que plantes... si tú hicieras una consulta como la que sedinho quiere hacer (y que dio origen a este tema), no habría mayor problema... Una lista de todos los inmuebles y sus características (las comunes, claro). Simplemente haces la consulta a la tabla "INMUEBLE" y listo. ¿Pero si en lugar de ver todos los inmuebles sólo quieres los áticos y los pisos?... Aquí se complica porque desde la tabla "INMUEBLE" no sabemos quiés es quién. Hay que acceder a tres tablas (inmueble, piso y ático), relacionarlas y discriminar registros... Si ponemos un campo "tipo_inmueble" esas consultas son tan sencillas como la primera. Saludos |
|
03/03/2005, 01:42
| ||||
| ||||
| Cita: En eso tienes razón, pero hay casos en los que eso no tiene mucha importancia y es una opción a valorar.
Iniciado por jpinedo Yo no estoy de acurdo con ese nivel pues se perdería mucho sentido semántico de los campos. Y te planteo una duda :¿Qué tipo de dato le pondrías al campo 'valor'?. Esta propuesta ya la he visto implementada y yo mismo la he implementado en algún caso. ¿Tipo que le pones?: evidentemente tiene que ser un char/varchar, no puedes poner otra cosa por la variabilidad de los datos que puede contener. Está claro que esta forma no se puede implementar siempre, pues pierdes funcionalidades según el tipo de datos (fechas, números, sobre todo). Pero en un caso en lo que sólo metes datos descriptivos sobre los que no vas a hacer más operaciones, que tienes mucha variabilidad en el número de datos y/o muchas características no obligatorias, esta forma de ponerlo es totalmente válida. También he implementado la otra forma, con las tablas adicionales por tipo de elemento, pero tiene el problema que por cada tipo de elemento nuevo que añades, tienes que crear una nueva tabla. Por último, también he implementado una única tabla con todas las características de todos los tipos de elementos. Hay que pensar que hablamos de una tabla maestra y el espacio desprovechado es mínimo, salvo que tengas miles de registros en esta tabla. Para mi la decisión de que forma implementar, siempre que me encuentro este problema, viene dada por el uso que se le van a dar a los datos a más. Y, personalmente, no me gusta estar sujeto a que a alguien, después de un tiempo se le ocurra que se le ha quedado un tipo de elemento en el tintero y por culpa de eso tener que andar tocando el código, que es lo que sucedería con las tablas a mayores por cada tipo de elemento. Un saludo.
__________________ Estoy contagiado de Generación-I |
|
07/03/2005, 21:41
| |||
| |||
| ¿Y qué os parece esta forma que se me olvidó plantear? Cargarse (eliminar) la tabla INMUEBLE, e incluir la información que queríamos que fuera ahí, en cada tabla por separado. Por ejemplo, el campo Provincia: pues incluir la provincia, directamente dentro de cada tabla (PISO, ÁTICO...). |
|
07/03/2005, 22:33
| ||||
| ||||
| En el caso que planteé yo (una tabla "padre" y otras "hijas") hay una gran ventaja adicional y es la de centralizar las relaciones con todas las otras tablas a través de ese padre. En el caso que planteas un_tio, si revisas es el caso que dio origen a este tema. El problema es que las tablas así por separado no estarían relacionadas entre sí. Saludos |
|
08/03/2005, 13:34
| |||
| |||
| Cita: Bueno, pero como ya dije, la unión entre tablas puedes ponerla en el nombre de la tabla.
Iniciado por jpinedo En el caso que planteé yo (una tabla "padre" y otras "hijas") hay una gran ventaja adicional y es la de centralizar las relaciones con todas las otras tablas a través de ese padre. En el caso que planteas un_tio, si revisas es el caso que dio origen a este tema. El problema es que las tablas así por separado no estarían relacionadas entre sí. Saludos Es decir, usando mi forma, podrías o que el título de las tablas existentes tuviera un denominador común (por ejemplo, que el nombre de cada tabla fuese el que es, precedido de la palabra "pisoss_") o, en todo caso, si a alguien no le termina de convencer esta forma, usar una tabla padre que simplemente contuviera las otras tablas existentes (sus nombres, y si acaso formas abreviadas de referirse a ellas). ¿Qué os parece así? Decidme qué os parece esta manera, y las dos formas de relacionar a las tablas que he puesto (las repito: una tabla que contiene el nombre de las otras tablas, o poner títulos de tabla "comunes"). Saludos |
|
08/03/2005, 16:38
| ||||
| ||||
| Cuando digo relaciones me refiero a las relaciones desde el punto de vista del modelo relacional... no entiendo cómo poniendo nombres comunes estableces la relación. Tampoco entiendo cómo haciendo una tabla con los nombres de las otras tablas vas a relacionarlas eficientemente. Saludos |
|
08/03/2005, 18:35
| |||
| |||
| Ah, ok. Hombre, pero tampoco es plan de crear relaciones "porque sí". Y lo de relacionarlas, es simplemente porque imagínate que en la empresa hay tablas de muchas cosas... y que quieres hacer una consulta genérica que sea la de "inmuebles"... ¿tendrá el programa que saber de algún modo cuáles son "inmuebles" y cuáles no? (suponiendo que se puedan crear tablas nuevas y que no puedas dejar prefijado). Saludos |
|
31/03/2005, 12:17
| |||
| |||
| Buenas, he llegado a este post mediante Google puesto que tengo el mismo problema y creo que no entiendo bien las distintas opciones. ¿Cuál sería la más óptima? Creo que la que mejor se adapta a mis necesidades es la de jpinedo pero no se si la he entendido bien. Se trata de crear una tabla común a todos los tipos de entidades y con todos sus atributos comunes. En el caso del inmueble: INMUEBLE --------- id_Inmueble tipo_Inmueble datos_comunes Y luego tablas con los tipos de tabla general. En este caso, los tipos de inmuebles: PISO ----- id_Piso datos_piso ATICO ------ id_Atico datos_Atico Creo que esa es la idea básica, pero luego hay variantes que no se si serán del todo óptimas. Por ejemplo, recojo la idea de usar un único id para pisos y áticos, por ejemplo, y así obviar el campo 'tipo_inmueble'. Así al hacer referencia a un id, obtendríamos unos campos determinados. Aunque según voy escribiendo esto, creo que noes del todo óptimo puesto que generaría una tabla intermedia con todos los datos para luego descartar los innecesarios. Otra idea que se me ocurre, y creo que esto si es más útil, es tener una tabla auxiliar con los tipos de inmuebles existentes, por si en un futuro se desea añadir alguno. Creo que esto también se comentó, pero por si acaso. Espero la opinión de alguien, aunque esté todo ya más que dicho. Así podré aclarar mis dudas. Gracias por adelantado. P.D.: ¿sería esta una consulta válida en el primer caso de jpinedo? SELECT * FROM inmueble INNERJOIN inmueble.tipo_inmueble ON inmueble.id_inmueble = piso.id_piso WHERE id_inmueble = 1234; La verdad es que si funcionara así, sería bastante potente  Última edición por SiNiESTrO; 31/03/2005 a las 13:02 |
|
31/03/2005, 20:26
| ||||
| ||||
| Hola... no, la consulta no sería válida. Tienes que especificar la tabla. Ahora yo te pregunto... ¿para qué te serviría la consulta tal como está? Si quieres una lista de todos, lo mejor es que sólo tomes sus campos comunes, con lo que harías la consulta a una sola tabla. Si tienes un script que va "juntar" los datos de la tabla padre con la de uno de sus hijos, pues se supone que sabes cuál es el hijo que se quiere consultar. Desde PHP podrías dejarlo así: $sql ="SELECT * FROM inmueble INNERJOIN $table_var ON inmueble.id_inmueble = $table_var.id_$table_var WHERE id_inmueble = $var_id"; Y claro, tendrías que definir las variable: $table_var y $var_id Saludos |
|
01/04/2005, 04:51
| |||
| |||
| Relacionado con esto, he abierto un tópic hace poco. En él, pongo 3 modelos distintos de diseño, ya "definitivos", en el que sólo me falta decidirme por uno de los tres: Enlace al tópic |
|
01/04/2005, 04:59
| |||
| |||
| Cita: ¿El único inconveniente que le ves es que haya una tabla intermedia? Piensa que eso también puede ser una ventaja, si tienes que relacionar los inmuebles con datos de otra tabla (por ejemplo, propietario), así pones el "propietario" en esa tabla intermedia, y para ver los inmuebles que tiene los ves en esa tabla y no te toca buscar en todas las tablas.
Iniciado por SiNiESTrO Por ejemplo, recojo la idea de usar un único id para pisos y áticos, por ejemplo, y así obviar el campo 'tipo_inmueble'. Así al hacer referencia a un id, obtendríamos unos campos determinados. Aunque según voy escribiendo esto, creo que noes del todo óptimo puesto que generaría una tabla intermedia con todos los datos para luego descartar los innecesarios. Y por supuesto, también puedes, aunque hagas una id separada para cada tabla (una para pisos, otra para áticos, etc.), crear una tabla intermedia. Cómo referenciar luego a cada elemento (si es piso, si es ático, etc.), es otro cantar, y es lo que yo proponía como introduciendo en un campo el nombre de la tabla a la que se referencia (pero esto tiene la desventaja de que no tiene garantías de seguridad y comprobación de errores de los datos, no puedes crear una restricción de tipo clave foránea). |
|
01/04/2005, 11:08
| ||||
| ||||
| Cita: de acuerdo con jpinedo, aparte de que cada cuando se crea o inventa un nuevo inmueble, no ha habido nuevos inmuebles en muchos años, asi que la creacion de una tabla asi haria todo innecesariamente mas trabajoso para realizar las consultas
Iniciado por jpinedo Cita: SaludosOriginalmente Escrito por vice Yo con esto haría un ejercicio aún mayor de abstracción y no haría una tabla más para cada uno con los datos adicionales, sino una única tabla que tenga una fila por cada característica adicional inmuebles_plus (id_inmueble, caracteristica, valor). Yo no estoy de acurdo con ese nivel pues se perdería mucho sentido semántico de los campos. Y te planteo una duda :¿Qué tipo de dato le pondrías al campo 'valor'?.
__________________ hola :adios: |
