10/08/2017, 12:50
|
| Colaborador | | Fecha de Ingreso: septiembre-2009 Ubicación: mortuoria
Mensajes: 3.805
Antigüedad: 15 años, 2 meses Puntos: 214 | |
Respuesta: Mejorar MER Saludo
Bueno, para analizar muchisimo mejor el tema, lo mejor sería tener el documento de requerimientos.
Sin embargo, basado en el MER opino lo siguiente
1. Se habla de las tablas user_type y state, las cuales no tendrían razón de ser si se va a hacer uso de las constantes.
Sin embargo, teniendo en cuenta la optimización, hablemos de la optimización de consultas.
Es decir, si en algún momento se necesita sacar un informe por ejemplo de los usuarios con su respectivo tipo y estado,
manejandolo con el tema de las constantes, necesariamente este informe se sacaría usando las constantes también,
es decir, que por base de datos no sería posible hacer algo 'directo' consultando tablas, a menos que se conserven las mismas.
Otra solución sería crear una vista en la base de datos, y lo que serían las constantes en php,
aquí serían ifs para revisar si el estado es 1 entonces que salga estado1, y así sucesivamente.
Entonces, retomando la idea de optimización, yo creería que es más optimo no manejar las constantes, sino hacer uso de las tablas ya diagramadas.
Esto hace que las consultas sean más limpias, y a su vez si se necesitan realizar consultas directamente a la bd
sin necesidad de hacer uso de la aplicación en algún momento, también se puede hacer sin complicaciones.
2. Productos que siempre tienen una categoría, y no siempre una subcategoría.
Aquí pregunto, hay productos que puedan tener varias categorías?
Y hay categorías que puedan tener varias subcategorías? (Este me imagino que si es posible)
Además, imagino que lo que si estaría relacionado es justamente categorías con subcategorías,
en cuyo caso, yo propondría que las tablas de category y subcategory sean quienes se relacionen (a menos que haya subcategorías que apliquen a varias categorías)
siendo necesaria una tercera tabla de category_subcategory donde se relacionen categorías con subcategorías.
Y claramente, esto también haría que existiese una de product_category_subcategory para que allí reposen solamente
las categorías con sus respectivas subcategorías de un determinado producto.
3. En cuanto a las características de cada product, como no son iguales en todos los casos, yo optaría por alguna de estas dos soluciones:
- Crear un campo tipo json, y allí guardar una estructura correspondiente a cada uno.
- Usar una tabla product_info y allí guardar con el id de cada producto sus respectivas características.
En cualquiera de los dos casos, se evita manejar N tablas nuevas por cada nuevo tipo de producto que pueda crearse en cierto momento con distintos atributos.
__________________ "Si consigues ser algo más que un hombre, si te entregas a un ideal, si nadie puede detenerte, te conviertes en algo muy diferente."
Visita piggypon.com |