Tengo una aplicación donde un Usuario puede ser Proveedor o Tienda. Ahora estos 2 roles tienen campos específicos de roles muy diferentes.
Básicamente, una Tienda puede hacer Pedidos a Proveedores. Por lo tanto, una Tienda puede hacer Pedidos y un Proveedor recibirá esos Pedidos.
¿Dónde colocaría estos campos para una buena práctica?
Ninguno de estos parece ser el camino a seguir. ¿Algunas ideas? ¡Gracias!
No tienes que quedarte con una sola tabla de users . Puede tener un modelo de proveedor y un modelo de tienda (con tablas de suppliers y shops ).
Luego, en el archivo config/auth.php , puede configurar un nuevo proveedor de autenticación usando el controlador Eloquent pero con un modelo diferente. Luego puede asignar esos proveedores a cualquier guardia nuevo que cree.
Puede leer más sobre autenticación y autorización aquí: https://laravel.com/docs/5.4/authentication
https://laravel.com/docs/5.4/autorización
Editar
Después de que se mencionara en los comentarios sobre las relaciones polimórficas, creo que se aplicaría mejor a este tipo de relación (múltiples tipos de usuarios, cada uno con su propio conjunto de campos).
Leer más aquí:
https://laravel.com/docs/5.4/eloquent-relationships#polymorphic-relations
¿Puede un usuario tener varias tiendas o suministrar múltiplos? Me parece bien tu segunda opción.
Usuario hasMany: proveedor, tienda
- identificación
- nombre
El proveedor pertenece a, tiene uno: usuario
- identificación
- id_usuario
- campos_proveedor
La tienda pertenece a, hasOne: usuario
- identificación
- id_usuario
- campos_tienda
$user->supplier->fields_supplier;
$user->shop->fields_shop;
$supplier->user->name;
$shop->user->name;
-- Si tuvieras más información sobre cómo quieres que funcione, sería de ayuda.
"Proveedor" es un papel desempeñado por una "Parte" ("Individuo" u "Organización")
Su tienda puede obtener un catálogo de un proveedor y puede solicitar cotizaciones de ellos.
Su tienda crea "Órdenes de Compra" y las envía al Proveedor, y él le envía "Respuestas a las Órdenes"
Un Proveedor no es un usuario. Sin embargo, podría crear "Usuarios" para sus empleados.
¿Por qué no usar simplemente un ERP existente como Odoo?