#Modelado de bases de datos

1 messages · Page 1 of 1 (latest)

drifting knoll
#

Saludos! estoy intentando modelar la db para un app de control de ventas, busco opiniones, incoherencias y demás que puedan ver con respecto a este planteamiento inicial.

image.png
elfin drum
# drifting knoll Saludos! estoy intentando modelar la db para un app de control de ventas, busco ...

¿La bd es SQL o NoSQL?, me parece que hay cosas redundantes entre bills y billdetails, creo que lo importante del detalle de enlazar una factura/recibo con un producto y decir cuantas unidades de dicho producto se están comprando, y el precio unitario de dicho producto en ese momento (en caso de que varíe luego) la fecha de la compra te la da la factura/recibo.

De resto no sabría decirte sin conocer las características/reglas de negocio (parece que está bien)

polar cloud
#

xd

drifting knoll
#

ok. agregaré la cantidad y quitaré el createdAt y updatedAt. y uso sql

drifting knoll
#

@polar cloud así quedaría. el precio total de factura se calcula de los detalles. y bueno ahí lo pensé y efectivamente faltaban esos campos, no tengo idea pq no los puse desde un inicio

image.png
#

lo que me causa un tanto de ruido es si un supplier lo considero como un usuario y le pongo un role de "supplier" justamente.

#

decidí que a pensar de que tienen campos iguales, en concepto difieren bastante. por ej en la empresa existirán gran cantidad de clientes, pero luego puede q la empresa no tenga tantos proveedores cm clientes. el vs en cantidad es abismal. por si el cheif desea consultar sus proveedores, tendría q consultar en una tabla relativamente pequeña. y claro es hasta mas fácil leerlo estando en tablas separadas. pero no se si esto sea un buen enfoque o hay otras razones de peso en contra, etc.

#

pero claro, siguiendo esa filosofía tendría q crear 1 tabla por role también y no le veo mucho sentido. entonces....

drifting knoll
#

... este me gusta mas, agg un role+ supplier que al final me ahorra una tabla. y bueno ahí también puse para q los productos tengan varias img.

image.png
wispy perch
#

Un proveedor es un usuario? Se puede logear en el sistema?

wispy perch
drifting knoll
# wispy perch pregunto por esto

al inicio pensé en que no y justamente por eso pensé en hacerle una tabla aparte, pero luego pensé en que puedo crearle una cuenta y asumir que no deja de ser un usuario solo que con le role supplier. pero claro, igual me interesa saber que se hace en ambos casos... sea q quiera tomarlo como un usuario con cuenta o simplemente info plana inventario. perdona q respondí tarde, caí muerto en el pc xD

polar cloud
drifting knoll
polar cloud
#

ah weno

#

puedes simplemente jalarla del createdAt

#

pero como quieras xd

#

igual yo tengo uno similar

#

con su diseño de BD

elfin drum
# drifting knoll ... este me gusta mas, agg un role+ supplier que al final me ahorra una tabla. y...

Con este último diagrama tengo algunas dudas:

  • el proveedor es básicamente una extensión de usuario, para darle algunas características extra (qué atributos extra serían realmente necesarios si es que se da el caso), que como mencionas con el rol podrías resolverlo y es opcional si conviertes rol en una tabla adicional o no.
  • si vemos el sistema desde un punto de vista orientado a objetos, el proveedor hereda los atributos comunes de usuario (en este caso con tener la fk de usuario lo reflejas), y no sería necesario tener createdAt o updatedAt a menos que en tu lógica de negocio quieras mantener el caso de que alguien que primero fue tu usuario en algún momento posterior se convirtió en proveedor y quieras saber ambas fechas, porque en el caso de que crees el usuario siendo proveedor desde el inicio tendrías esos datos redundantes siempre, también me debatiría si él id de proveedor es necesario considerando que ya se tiene el de usuario (igualmente queda a consideración dependiendo de las reglas de negocio).
  • en el caso de la relación entre productos y proveedor, puede un mismo producto ser despachado por distintos proveedores (un proveedor debería poder despachar múltiples productos), entonces dependiendo de eso la fk de proveedor va en producto y no al revés, o es un muchos a muchos y sí necesitas una tabla intermedia muchos a muchos (un ejemplo x que se me ocurre en el momento es que tengas un producto como "harina de trigo de 1kg", y tengas dos marcas o dos proveedores distintos de la misma marca que ambos den lo mismo, entonces el producto lo dan distintos proveedores en incluso podrian tener distinto precio).

Te lo dejo para que consideres o si alguien más quiere dar feedback sobre esto, igual como he dicho, depende mucho de tus reglas de negocio, y si la cosa se complica con más entidades que falten posteriormente

wispy perch
#

No quiero alargar mucho la discusión, pero una cosa es tratar de descubrir las entidades, y otra es definir como se mapea esa estructura en una base de datos relacional. Un usuario es alguien que usa la aplicación, por eso hoy te pregunté si todos se logeaban en la app. Podés tener muchos tipos de usuarios, si usas OOP podés representar esas relaciones mediante herencia... pero las bases de datos relacionales no soportan herencia, y si tratas de meter todo en la misma tabla lo único que conseguís es complicarte la vida... Casi siempre es más fácil tener una tabla para cada entidad, independiente de como está implementado tu dominio

elfin drum
# wispy perch No quiero alargar mucho la discusión, pero una cosa es tratar de descubrir las e...

Concuerdo, el tema es si un proveedor se puede loguear en la app, y tomar la decisión si en ese caso se quiere tener una única tabla que chequear para eso o tener separadas (lo que quise dejar claro es que si se va a usar una sola tabla para consultar en caso de login, definir bien si se necesita esa segunda tabla y qué atributos tendría la segunda tabla, porque en el diagrama parece que no hace falta y aparte está duplicando atributos innecesarios si es el caso que los proveedores se pueden loguear)

drifting knoll
#

claro, concuerdo. el tema es que si decido separar o crear una tabla por c/proveedor tendría q hacer lo mismo para client. solo chief, admin y seller podría loguearse.

#

ahora. la unica diferencia entre alguien q se loguea y alguien que no, será el campo password. mi idea sería tener todo en 1 sola tabla y a los supplier o client crearles una cuenta y poner un default en ese campo password y no afectaría al negocio dado que en los endpoints se potegerán según el respectivo role. @wispy perch @elfin drum

polar cloud
#

te dije que tengo un diseño para que lo veas

drifting knoll
#

manda si gustas y lo veo. aunq mi idea era debatir xD

polar cloud
#

si te sirve, bacán

#

sino, no problema

#

o podrías referenciarte

#

me falta diseñar cómo tengo la del sistema hotelero

#

pero ya después

#

toy con harta chamba que preferiría haberme dedicado a otra cosa

drifting knoll
#

ok tú optaste por hacer una tabla para cada role

polar cloud
#

pues claro

#

los usuarios únicamente serían los trabajdores, pero no todos los trabajadores tendrán un usuario, solo determinados roles (almacen, cajero, etc)

drifting knoll
#

ya, pero no me gusta pq siento que se repiten tablas q guardan lo mismo. pero por otro lado, se segmenta cada grupo de usuarios xD.

wispy perch
#

Las tablas no se repiten, cada una tiene una función. Se repiten los campos entre tablas, sin duda, pero eso no es algo que esté mal. Es simplemente una coincidencia, pero no un indicador de que todas esas entidades diferentes deberían guardarse en el mismo sitio

#

Combinando entidades de esa manera solo perdés flexibilidad ante futuros cambios

#

Pero bueno 🤷‍♂️