Usuario, cliente, cuenta de administrador en 3 tablas diferentes?

En mi aplicación web tendré tres tipos de cuentas.Usuario, cliente, cuenta de administrador en 3 tablas diferentes?

usuario: para el uso de la aplicación web gratis
cliente: para la publicidad y conseguir un logotipo de la compañía
Admin: para la edición y la eliminación de la materia

En caso de que todos estos tres estará en separada tablas o en una con una columna llamada "account_type" donde puedo marcarlo como Usuario, Cliente o Administrador?

¿Cuáles son los pros y los contras de ambos? ¿Hay una mejor práctica para esto?

Gracias

Fuente

2010-08-18 never_had_a_name

creo que sería útil para mantenerse cómo los casos de uso se refieren a otras cosas en su modelo de datos. Es decir. ¿Cuál es el vínculo entre el Cliente y las Imágenes, el Usuario/Administrador como acceso? – Nix

Diría una tabla, pero si hay muchos atributos diferentes para cada función, debería pensar en tablas diferentes. Puede marcar al usuario con un id/enum, llamémosle rol. role = 1 sería un usuario, role = 2 sería un cliente y role = 3 sería un administrador. De modo que puede extender fácilmente sus roles con una construcción de clave foránea (como dijo David Stratton). – hering

En general, un person puede haber usuario, cliente y admin - es así, me gustaría empezar con una tabla con columnas PersonIsCustomer, IsUser, IsAdmin. Más tarde (para búsqueda rápida) puede decidir agregar tablas separadas Admin, Customers, Users con FK a la tabla Person.

EDIT:

Un caso típico puede ser:

5 millones de usuarios
1000 clientes
10 administradores

En general, tienen tablas separadas para los clientes y los administradores deben acelerar cualquier consulta relacionada con el administrador/cliente.

Fuente

2010-08-18 12:11:00

A veces, los usuarios y los clientes tienen diferentes propiedades, por lo que debe dividir en 2 tablas en lugar de colocar columnas opcionales en la misma tabla. – brunocascio

Si un usuario sólo puede haber un tipo, que estaría mejor con una tabla y un campo de bits para IsAdministrator, etc.

Si un usuario puede ser de más de una cuenta tipo, a continuación, debe tener una tabla diferente, con una clave externa,

estructura de la muestra (Sypes de datos de SQL Server son únicamente sugerencias y)

tabla Usuarios

ID de usuario - int
nombre de usuario - varchar (25)
contraseña - varchar (25)
Nombre - varchar (50), etc ...

tabla Roles

RoleId - int
Descripción del papel - varchar mesa (25)

User_Roles

UserId - int (con una llave foregin a la tabla Usuarios)
int RoleId (clave externa a la tabla de roles)

Fuente

2010-08-18 12:06:26 David

Creo que te entiendo. Una tabla de Cuenta para información básica compartida por todos ellos, luego 3 tablas diferentes para cada uno de ellos con información específica, luego los enlace con ellos con una clave_extrana en la tabla básica ¿verdad? –

Sí, ya lo sabía, – David

. Estaba pensando que quería decir una tabla para administradores y otra para custmers con toda la información que se repite. Lo leí mal, ¿no? – David

Las ventajas y desventajas varían en función del tamaño y la complejidad de su sistema.

Me dividirla en usuario, Papel, userresources

usuario (definiría información básica)

las funciones de usuario

FK-> RoleType

Role_Type (usuario, administrador, cliente, posiblemente permisos o puede ampliar esto más).

userresources (medios de comunicación)

FK-> usuario

Fuente

2010-08-18 12:11:09 Nix

Usuario, cliente, cuenta de administrador en 3 tablas diferentes?

Respuesta

Cuestiones relacionadas