¿Qué esquema de tabla de base de datos es más eficiente?

Question

¿Qué esquema de tabla de base de datos es más eficiente y por qué?

"Users (UserID, UserName, CompamyId)"
"Companies (CompamyId, CompanyName)"

O

"Users (UserID, UserName)"
"Companies (CompamyId, CompanyName)"
"UserCompanies (UserID, CompamyId)"

Dado que el usuario y la empresa tienen una relación uno a uno.

Answer 1

Sin duda, el anterior es más eficiente dada esa restricción.Para obtener la misma información, tendrá menos uniones en sus consultas.

Answer 2

Bueno, esa es una pregunta un poco abierta y depende de las reglas de su negocio.La primera opción que tiene solo permite asignar una empresa a un usuario.estás definiendo una relación de muchos a uno.

El segundo esquema define una relación de muchos a muchos que permite asignar varios usuarios a varias empresas.

Resuelven diferentes problemas y, dependiendo de lo que intentes resolver, determinarán qué esquema debes usar.

Estrictamente hablando, desde el punto de vista de las "transacciones", el primer esquema será más rápido porque solo tiene que confirmar una fila para que un objeto de usuario se asocie a una empresa y para recuperar la empresa para la que trabaja su usuario solo requiere una unión. sin embargo, la segunda solución se escalará mejor si los requisitos de su negocio cambian y requieren que usted tenga varias empresas asignadas a un usuario.

Answer 3

Como siempre depende.Personalmente elegiría la respuesta número uno, ya que tendría menos uniones y sería más fácil de mantener.Menos uniones deberían significar que requiere menos escaneos de tablas e índices.

SELECT userid, username, companyid, companyname
FROM companies c, users u
WHERE userid = companyid

Es mucho mejor que...

SELECT userid, username, companyid, companyname
FROM companies c, users u, usercompanies uc
WHERE u.userid = uc.userid
AND c.companyid = uc.companyid

Answer 4

Los dos esquemas no se pueden comparar, ya que tienen relaciones diferentes; probablemente debería observar cuál es la especificación de las tablas y luego determinar cuál se ajusta a la relación necesaria.

El primero implica que un Usuario sólo puede ser miembro de uno empresa (una relación pertenece_a).Mientras que el segundo esquema implica que un Usuario puede ser miembro de muchas empresas (una relación tiene_muchos)

Si está buscando un esquema que pueda (o admita más adelante) una relación has_many, entonces querrá optar por el segundo.Por el motivo compare:

//select all users in company x with schema 1
select username, companyname from companies
inner join users on users.companyid = companies.companyid
where companies.companyid = __some_id__;

y

//select all users in company x with schema 2
select username, companyname from companies
inner join usercompanies on usercompanies.companyid = companies.companyid
inner join users on usercompanies.userid = users.userid
where companies.companyid = __some_id__;

Tienes una unión extra en la mesa de selección.Si solo desea la relación pertenece_a, entonces la segunda consulta hace más trabajo del que debería y, por lo tanto, la hace menos eficiente.

Answer 5

Creo que te refieres a "muchos a uno" cuando se trata de usuarios y empresas, a menos que planees tener una empresa única para cada usuario.

Para responder a su pregunta, siga el primer enfoque.Una tabla menos para almacenar reduce el espacio y hará que sus consultas utilicen menos comandos JOIN.Además, y lo que es más importante, coincide correctamente con la entrada deseada.El esquema de la base de datos debe describir el formato de todos los datos válidos; si se ajusta al formato, debe considerarse válido.Dado que un usuario sólo puede tener una empresa, es posible tener datos incorrectos en su base de datos si utiliza el segundo esquema.

Answer 6

Si el Usuario y la Empresa realmente tienen una cara a cara relación, entonces sólo necesitas una tabla:

(ID, UserName, CompanyName)

Pero sospecho que realmente quisiste decir que hay una uno a muchos relación entre usuario y empresa: uno o más usuarios por empresa, pero solo una empresa por usuario.En ese caso, la solución de dos tablas es correcta.

Si hay un muchos a muchos relación (una empresa puede tener varios usuarios y un usuario puede estar vinculado a varias empresas), entonces la solución de tres tablas es correcta.

Tenga en cuenta que eficiencia No es realmente el problema aquí.Es la naturaleza de los datos la que dicta qué solución debe utilizar.