Consulta Filtrado resultados PHP mYSQL

[gnzsoloyo]

Es un tema más relacionado con Análisis de Sistemas (AS) que con otra cosa. La necesidad de la existencia de la herencia en Usuarios, Clientes y Proveedores surge de la definición de las entidades que intervienen en el sistema, y entre las razones de su diferenciación están ciertos conceptos que van más allá de simplemente los atributos que tienen.
El tema es que Cliente y Proveedor son entidades con atributos similares en algunas cosas, y diferentes en otras. Pero por sobre todas las cosas son entidades que tienen relaciones, cardinalidades y responsabilidades diferentes. Desde ese punto de vista no deben compartir la misma representación en el sistema, ni a nivel de aplicación y muy especialmente a nivel de datos.
Lo que si podrían ser es usuarios, siempre y cuando un Proveedor pueda ser un usuario con acceso al sistema. Eso es un tema a definir por el cliente que solicita el desarrollo, y no algo que se asume per se. Si el proveedor no realiza gestiones en la aplciación, pasa a ser una enitidad y no un usuario.
No perdamos de vista que en un sistema un usuario es alguien que en algún momento hace uso de alguna interfaz de forma directa. Si el Proveedor provee datos que alimentan la sistema, pero no los inserta él, el Proveedor pasa a ser una entidad, pero no un usuario.
¿Se entiende la idea?

Ahora bien, supongamos que el proveedor si realiza gestiones allí. En ese contexto el usuario tiene dos grupos de propiedades: 1) Es persona (física o jurídica), y 2) es usuario del sistema. Aunque lo parezcan, desde el punto de vista del AS, no son la misma cosa. Un usuario lo es con sólo un grupo de atributos: username, password, perfil y rol, pero no necesita ser una persona física ni jurídica.
La persona, por su lado, es una entidad identificada por nombre (o razon social), numero de documento (no interno a la organización), domicilio, condición impositiva, teléfono., etc. Es decir, es persona en tanto se lo pueda identificar en el entorno, en lo externo al sistema.
En ese sentido un Proveedor es persona, y un Cliente también, pero con atributos diferentes, porque las acciones, las relaciones y la identificación de sus responsabilidades en el sistema son diferentes. Son esas relaciones y responsabilidades las que ayduan a determinar la jerarquía de la herencia.
Para describirlo:
- Persona es una clase o entidad padre.
- Cliente y Proveedor heredan a Persona.
- Cliente y Proveedor se relacionan con Usuario (a nivel de POO eso se expresa como una relación o asociación de agregción)..

¿Va siendo un poco más claro?

Lo que tiene que entenderse también es que el modelo de clases no es convertible en forma directa a un modelo de datos físicos. La base de datos no es un reflejo de espejo de las clases de la aplicación, sino que tiene sus propias reglas para mantener consistencia e integridad de los datos, lo que hace que el mismo esquema en uno u otro modelo contengan diferencias muy grandes.
Para ejemplificarlo, un modelo de 12 clases en la aplicación puede requierir 57 tablas para implementarlo en la BBDD. Porque desde la arquitectura de datos no se miran procesos sino datos.
De hecho, a nivel de BBDD, lo que define si se deben crear una o dos tablas para los datos de Usuario y Persona, es una decisión de diseño: ¿Una persona tiene un único usuario o muchos?
Si la cardinalidad es 1:1 ó 1:N cambia la cosa, pero para la aplicación la diferencia podría ser entre tener un atributo string o un array, nada más.

¿Se va acercando la cosa a tu pregunta?

PD: Como siempre digo, en cuato a "la forma correcta", ese es un concepto que no existe en desarrollo. Puede ser lo "adecuado", lo "requerido", lo "conveniente", pero no existe lo correcto.
El mismo sistema, diseñado por dos analistas diferentes, puede desarrollarse con modelados totalmente diferentes y hasta contradictorios, y ambos ser correctos.
Eso es algo que me dijeron en la primera clase de Análisis de Sistemas I, y la experiencia me ha demostrado que los profesores tenían razón.