Una consulta sobre BD

Publicado en 'Programación' por iRoot, 5 Nov 2018.





  1. iRoot

    iRoot Miembro frecuente

    Registro:
    12 Jul 2016
    Mensajes:
    209
    Likes:
    8
    Temas:
    90




    Buenos días, tengo una base de datos con clientes y vendedores

    La idea es la siguiente: tengo una pagina web donde va ver 3 tipos de usuarios: Gerente(tienes acceso total de la pagina), Vendedor(tiene acceso a ciertos requisitos), Cliente(tiene acceso a ciertos requisitos).

    Bueno el negocio funciona de la siguiente manera, el cliente tiene 2 formas de hacer la compra, lo hace directamente acercándose a la tienda y pidiendo lo que necesita y todo la compra y registro del cliente queda registrado en la paginas web mediante el vendedor, la otra manera es que desde la comodidad de su casa el cliente se loguee, antes debe haberse registrado y cuando accede a la web como usuario entonces podrá realizar las compras que desee.

    Ahora no se como realizar lo siguiente: Va ver una tabla usuarios con 3 tipos de usuarios, cuando el cliente
    se registre mediante la web, sera un usuario y cliente a la vez, ademas el vendedor tiene la posibilidad de realizar el registro del cliente cuando este venga a la tienda, pensaba realizar un procedimiento que lo guarde en la tabla usuarios y cliente a la vez, sin embargo como harria con los vendedores, ya los registro en la tabla de usuarios por defecto?? osea previamente ya tienen que estar registrados? o al momento de hacer un registro de la tabla vendedores hago un procedimiento que registre en vendedores y usaurios??
    Y como harria con el gerente se supone que solo sera un persona con el acceso total, creo una tabla mas de gerente o solamente la ingreso por interno a la tabla de usuario.

    Espero se haya entendido, salu3!
     


  2. San Diablo

    San Diablo Miembro de bronce

    Registro:
    1 Feb 2008
    Mensajes:
    1,902
    Likes:
    796
    Temas:
    77
    No entiendo el "va ver"

    Te refieres a "va a haber"?
     
    A iRoot le gustó este mensaje.
  3. jlscbustamante

    jlscbustamante Miembro frecuente

    Registro:
    8 Oct 2015
    Mensajes:
    198
    Likes:
    36
    Temas:
    10
    Todo aquel que tenga que ser registrado como usuario, lo tiene que estar.
    Las categorías que has mencionado se llaman roles y es necesaria 4 tablas más : Roles, permisos, roles_permisos, roles_usuarios.

    Así un usuario puede ser a la vez usuario web y usuario "físico".

    Luego en cada página o pantalla validas si un usuario tiene permiso o no de acceder a dicho recurso.

    Lo importante y que más trabajo necesita es la asignación de roles,permisos a las respectivas tablas intermedias.
     
    A iRoot y edrg31 les gustó este mensaje.
  4. edrg31

    edrg31 Miembro de bronce

    Registro:
    23 Dic 2014
    Mensajes:
    1,270
    Likes:
    208
    Temas:
    39
    Es cierto lo de roles, @San Diablo en Internet hay ejemplo de usuarios y roles, en inclusive el diagrama de tablas de usuarios y roles.
     
    A iRoot le gustó este mensaje.
  5. gnox

    gnox Miembro de bronce

    Registro:
    3 Ene 2013
    Mensajes:
    2,348
    Likes:
    946
    Temas:
    82
    Tu duda es con pre-poblar la tabla con data, si no hay pantalla donde se de mantenimiento (Altas/Bajas/Cambios) de esos tipos de usuarios (Gerente/Vendedor) tienes que hacerlo via script.

    Normalmente para algo pequeño que empieza de 0, se crea un usuario admin via script que permite crear a otros usuarios y asignar sus roles y permisos en su correspondiente pantalla (ABC Usuarios) el campo/rol/permiso tipo de usuario es donde aplicas tus condiciones de quien puede crear a quien (admin->gerente/vendedor, gerente->vendedor, vendedor->cliente).
     
    A iRoot le gustó este mensaje.
  6. H0unter

    H0unter Miembro de bronce

    Registro:
    1 Jun 2010
    Mensajes:
    1,735
    Likes:
    237
    Temas:
    200
    Como recomendacion que los roles sean numericos, donde 0 puede ser admin , 1 gerente, etc.
     
    A iRoot le gustó este mensaje.
  7. TheRoot

    TheRoot Miembro maestro

    Registro:
    8 Ene 2015
    Mensajes:
    331
    Likes:
    30
    Temas:
    38
    Yo no lo recomendaria, puedes poder un codigo numerico pero los roles deben ser descriptivos, todo en los programas actuales deben ser descriptivos, los nombres de las variables, las clases, los objetos, metodos, tablas, store, columnas, etc. etc.

    Por otro lado, la primera carga siempre es por script, o en ultimo caso crea la tabla o tablas de tu modelo y crea via INSERTs al gerente, el se encargará de crear al resto de la jerarquia.
     
    A iRoot y Aedo les gustó este mensaje.
  8. H0unter

    H0unter Miembro de bronce

    Registro:
    1 Jun 2010
    Mensajes:
    1,735
    Likes:
    237
    Temas:
    200
    no es seguro tener roles descriptivos en una tabla, cada variable puede ser definida en la documentacion del proyecto.
     
    A iRoot le gustó este mensaje.
  9. TheRoot

    TheRoot Miembro maestro

    Registro:
    8 Ene 2015
    Mensajes:
    331
    Likes:
    30
    Temas:
    38
    Si, pero como dije "hoy se acostumbra" minimizar la documentación externa al programa, tampoco vamos a poder un rol como GerenteGeneraldeAsuntosSinImportancia, pondriamos un rol al puesto mas o menos descriptivo y un maestro de roles en otra tabla.
     
    A iRoot le gustó este mensaje.
  10. H0unter

    H0unter Miembro de bronce

    Registro:
    1 Jun 2010
    Mensajes:
    1,735
    Likes:
    237
    Temas:
    200
    Hoy se acostumbra a ni tener documentacion, jajjaa no significa que sea correcto :D
     
    A iRoot le gustó este mensaje.
  11. TheRoot

    TheRoot Miembro maestro

    Registro:
    8 Ene 2015
    Mensajes:
    331
    Likes:
    30
    Temas:
    38
    Hablo de buenas practicas no de malas costumbres por si acaso, las lladamas "metodologias agiles" buscan que el programa se "autodocumente"
     
    A edrg31 le gustó este mensaje.
  12. edrg31

    edrg31 Miembro de bronce

    Registro:
    23 Dic 2014
    Mensajes:
    1,270
    Likes:
    208
    Temas:
    39
    Para casos grandes, metodología antigua; casos pequeños, metodología ágiles.