Esta bien consultar tablas heredadas asi?

[enridp]

Hola!!!

Pongo un ejemplo que no es mío pero que igual sirve:



En el ejemplo de arriba, supongamos que queremos obtener los 10 primeros productos (con los datos de Food y Drink segun corresponda)?

En principio se me ocurre que podríamos hacer algo como esto:

SELECT p.*, f.*, d.*
FROM Products p
LEFT JOIN Food f ON p.product_id = f.product_id
LEFT JOIN Drink d ON p.product_id = d.product_id
WHERE p.product_id < 11

Pero en ese caso estamos recorriendo siempre la tabla Food y Drink por cada Producto (aunque solo necesitamos una de las dos ya que son exclusivas), esto supongo hace la consulta un poco más lenta. Y ademas me va a devolver muchos valores NULL en cada fila.

Hay una mejor forma?
Me convendría agragar un campo "tipoDeProducto" a Products para primero detectar si es Food o Drink y hacer una consulta de acuerdo a si es Food o Drink?

[gnzsoloyo]

Me convendría agragar un campo "tipoDeProducto" a Products para primero detectar si es Food o Drink y hacer una consulta de acuerdo a si es Food o Drink?

No.
Eso sería innecesario porque el hecho de que sea uno u otro lo determina la tabla que estás consultando.
El hecho de usar una herencia no implica que vayas a usar las tres (o más) tablas al mismo tiempo. Se hace para resolver problemas de normalización y evitar redundancias e inconsistencias de datos.

La respuesta es:
Si quieres listar las comidas usas un par de tablas. Si quieres las bebidas, usas otro par.
¿En qué contexto necesitarías una sola consulta que te devuelva todo?

Muy probablemente en ninguno.

[enridp]

¿En qué contexto necesitarías una sola consulta que te devuelva todo?

En el contexto de una busqueda, tal vez está mal planteada la solución de raiz entonces, pero supongamos este caso con el ejemplo de arriba:

La web tiene un buscador de productos, el usuario busca supongamos por algun atributo que se encuentra en "Products" o algun otro que se encuentra tanto en Food como en Drinks. Entonces necesitamos mostrar los resultados de los dos, de Food y de Drinks.

En mi caso particular, estoy creando una tabla: "PublicacionesComerciales" (padre) que pueden ser a su vez "Productos" o "Servicios", y quiero que cuando el usuario busque algo me deuvelva todos los productos y servicios que concuerdan con la busqueda.

Justamente como tu dices, decidí agrupar los campos comunes de Productos y Servicios para normalizar, y tener tambien menos relaciones.
Está mal?

[gnzsoloyo]

La web tiene un buscador de productos, el usuario busca supongamos por algun atributo que se encuentra en "Products" o algun otro que se encuentra tanto en Food como en Drinks. Entonces necesitamos mostrar los resultados de los dos, de Food y de Drinks.

Este tipo de búsqueda sólo puede hacerse sobre los campos comunes, y allí se puede resoler el problema sin necesidad de recurrir a agregar campos adicionales a las tablas:

Código MySQL:

SELECT P.*, F.ingredients, F.price, 'Food' `TipoDetalle`
FROM Products p
INNER JOIN Food f USING(product_id)
WHERE p.product_id < 11UNION 
SELECT P.*, F.ingredients, F.price, 'Drink' `TipoDetalle`
FROM Products p
INNER JOIN Food f USING(product_id)
WHERE p.product_id < 11;
 

Cualquier campo agregado hará que devuelva NULL en esa columna.

[enridp]

Iniciado por gnzsoloyo

Este tipo de búsqueda sólo puede hacerse sobre los campos comunes, y allí se puede resoler el problema sin necesidad de recurrir a agregar campos adicionales a las tablas:

Y si necesito tambien buscar y obtener los campos que no son comunes?
Por ej. la tabla Productos podria tener un campo "stock" que no lo tiene la tabla Servicios, y esta ultima podría tener un campo "aDomicilio" o "duración".
Como haríamos en caso de necesitar esos campos tambien?


Por otro lado aprovecho para hacerte otra consulta que tal vez te haz encontrado alguna vez con un problema similar:
Estaba pensando agregar un campo "PRECIO", pero me gustaría que el precio pueda ser:
* Un Numero fijo
* Un rango (entre $200 y $300 por ej.)
* A Convenir
De modo que el usuario pueda elegir como poner el precio a su producto o servicio.
Este es un problema que me encuentro muy a menudo y no se como resolverlo.
Es decir, cuando tenemos un campo que representa un mismo "dato" pero puede representarlo de muchas formas.
Para el caso del precio se me ocurrio poner 2 campos:
PrecioMinimo (INT)
PrecioMaximo (INT)
Asi para un precio fijo ambos tendrian el mismo valor, para un rango serian distintos y para "A Convenir" definiria los definiria como -1
Es una solucion muy mala?
Como armarías tu la tabla en ese caso?

[matanga]

Solo un pequeño comentario, la herencia en las bases de datos relacionales (teniendo en cuenta el modelo que planteas) tiene 3 alternativas en el modelo físico, una, dos o tres tablas.

1. Una tabla Products con un campo TipoProducto para diferenciar Food y Drink
2. Dos tablas, Food y Drink.
3. Tres tablas, Products con los campos de la clase padre y la primary key, la tabla Food y la tabla Drink con las Foreign Key Identifying.

Hay varios factores para elegir un modelo u otro, normalización, volumen de datos, etc, en cualquier caso, te recomiendo evaluar cada uno, ya que en función de esto, serán las diferentes consultas SQL.

Saludos

[gnzsoloyo]

En el modelo propuesto la primera opción no aplica, porque generará campos vacíos alternativamente en el producto que no los usa. Eso simplemente redundará en desperdicio de espacio, de buffer de consulta y datos, y además la necesidad de controlar constantemente los NULL en la salida.
Quedan sólo dos opcciones: La segunda y la tercera.
Las dos son más o menos equivalentes; ocupan el mismo espacio en disco y tienen las mismas restricciones, por lo cual se puede optar por cualquier. De estas la última es la mas "ortodoxa", pero no necesariamente excluye e la otra.

[enridp]

Creo que la mejor opcion es la tercera, no solo parece más elegante sino que deja bien explicita la herencia y ahorra muchas relaciones (ademas de estar mas normalizada).

El problema es cuando necesito datos de los dos hijos. Hay una solución para eso?
Se me ocurre lo siguiente:

Armar un VIEW donde esten todos los datos del padre, mas una columna TIPO (que indica el tipo de hijo), y otra columna datos_hijo que sea TEXT y adentro esten los datos del hijo serializados.
Aunque a simple vista me parece que andaria incluso mas lento que los LEFT JOIN.

Por otro lado, existe algún design pattern para el segundo problema? es decir, cuando un mismo dato puede ser representado de formas diferentes:
Un precio puede ser a convenir, un numero, un rango, etc.
Una direccion puede ser una calle y un numero, 2 calles, etc.