Hola jovenes
Para quien se le de bien las bases de datos.
Tengo una duda sobre como debo reflejar una tabla y es la tabla transferencia entre cuentas.
Siempre la reflejé así:
Nombre tabla: Transferencias
Campos:
ID
IDCuentaOrigen
IDCuentaDestino
Cuando
Cuanto
Pero ahora estoy pensando o repensando que debería ser así:
Nombre tabla: Transferencia origen
ID
IDCuentaOrigen
Cuando
Cuanto
Y otra tabla: Transferencia destino
ID
IDCuentaDestino
Cuando
Cuanto
En fin estoy algo liado o echo un lío, cual creen que es la forma. Y sino es ninguna anterior pues expongan, gracias.
Ah y saludos a todos.
Para quien se le de bien las bases de datos.
Tengo una duda sobre como debo reflejar una tabla y es la tabla transferencia entre cuentas.
Siempre la reflejé así:
Nombre tabla: Transferencias
Campos:
ID
IDCuentaOrigen
IDCuentaDestino
Cuando
Cuanto
Pero ahora estoy pensando o repensando que debería ser así:
Nombre tabla: Transferencia origen
ID
IDCuentaOrigen
Cuando
Cuanto
Y otra tabla: Transferencia destino
ID
IDCuentaDestino
Cuando
Cuanto
En fin estoy algo liado o echo un lío, cual creen que es la forma. Y sino es ninguna anterior pues expongan, gracias.
Ah y saludos a todos.
Hola
En mi opinión depende de las miras que tengas en cuanto a modificaciones futuras. Sé que no es la respuesta que esperabas, pero te doy mi opinión:
Para algo básico, a mi me sirve la primera forma.
Para algo que vaya a crecer, o para tener un control más fino de las operaciones según nuevas necesidades, usaría la segunda, con dos tablas, pero en principio me parece que duplicar en ambas tablas 'Cuando' y 'Cuanto' no tiene mucho sentido, pudiendo usar relaciones o incluso una consulta tipo vista con un join de las dos tablas.
La verdad es que el diseño de bases de datos no es lo mío, a mí también me surgen este tipo de dudas y además de ser muy personal, cada cabeza piensa de una forma distinta...
Bueno, pues no es que haya sido de gran ayuda, pero ahí están mis dos céntimos
Saludos
En mi opinión depende de las miras que tengas en cuanto a modificaciones futuras. Sé que no es la respuesta que esperabas, pero te doy mi opinión:
Para algo básico, a mi me sirve la primera forma.
Para algo que vaya a crecer, o para tener un control más fino de las operaciones según nuevas necesidades, usaría la segunda, con dos tablas, pero en principio me parece que duplicar en ambas tablas 'Cuando' y 'Cuanto' no tiene mucho sentido, pudiendo usar relaciones o incluso una consulta tipo vista con un join de las dos tablas.
La verdad es que el diseño de bases de datos no es lo mío, a mí también me surgen este tipo de dudas y además de ser muy personal, cada cabeza piensa de una forma distinta...
Bueno, pues no es que haya sido de gran ayuda, pero ahí están mis dos céntimos
Saludos
Por favor, usa el corrector ortográfico antes de pulsar el botón 'Enviar'
Gracias jguardon para mi siempre es un placer hablar contigo 
Lo de Cuando y Cuanto en la segunda forma es para poner la fecha y el importe inequivocamente y además para poner o no en positivo uno y en negativo otro pero esto es según la forma de guardar elegida, ya sabes que habrá personas que guarden todo todo en positivo y lo trata por código y lógica, habrá otras personas que pondrán positivo y negativo en los datos para no tener que tratar nada.
Pero al final mediante un mapa mental he estado desarrollando toda la lógica de la base de datos y he decidido dejarlo como la primera. Y sí, tienes razón, este come cocos de diseñar una buena y verdadera base de datos desde luego debe ser un experto y yo soy más maestro liendre, ya sabes. Gracias, saludos.
Lo de Cuando y Cuanto en la segunda forma es para poner la fecha y el importe inequivocamente y además para poner o no en positivo uno y en negativo otro pero esto es según la forma de guardar elegida, ya sabes que habrá personas que guarden todo todo en positivo y lo trata por código y lógica, habrá otras personas que pondrán positivo y negativo en los datos para no tener que tratar nada.
Pero al final mediante un mapa mental he estado desarrollando toda la lógica de la base de datos y he decidido dejarlo como la primera. Y sí, tienes razón, este come cocos de diseñar una buena y verdadera base de datos desde luego debe ser un experto y yo soy más maestro liendre, ya sabes. Gracias, saludos.
Buenas, he visto el post algo tarde, voy a dar mi opinión o punto de vista para que así podamos tener más elementos en lo que se puede denominar un Brain Storming.
Creo que la primera opción sería la más adecuada, aunque dependiendo de la escalabilidad quizá se debería cumplimentar con alguna tabla intermedia en lo que en el Software Factory se denomina relaciones Many to Many.
El tema del DBA (Data Base Administrator) es como comentáis un arduo trabajo a nivel sobre todo de definición, y no solo hay que mirar el que los datos cuadren, si no que hay que evaluar la extracción posterior para Reporting. Imaginate en tu supuesto que quisieras saber los importes que han salido como SALIDAS o ENTRADAS de dinero, pues con tu primera propuesta puedes obtener esos datos mediante un inner join a la tabla cuentas y comprobar el Sumatorio de importes con CuentaOrigen o CuentaDestino. La relación en este caso sería Uno a Uno PK FK sin ninguna tabla intermedia.
Más cosas que puedo aportar, la nomenclatura es vital, parace una tonteria y lo se, pero no es lo mismo IdCuentaOrigen que CuentaOrigenId, la primera conduce a error si puede llegar a ser parte de la clave primaria, la segunda te da inequivocamente que es una Foreing Key que va vinculada a otra tabla. Hay que tener en cuenta que en la creación de software cada vez se da más y más el denominado patrón "Code First" que mediante implementación de ORM permiten que una vez generamos el mapa mental de las clases, éstas pasen a ser entidades de Base de Datos, por tanto y por tratarse de Frameworks, estrictos las nomeclaturas entran mucho en juego.
Resumiendo el tostón que estoy dando, es, que tu opción primera tiene mucha validez lógica, que no es la única porque no sabemos que piensa tu cabeza.
Espero haber arroado algo de luz al respecto y si no, lo hemos intentado.
Creo que la primera opción sería la más adecuada, aunque dependiendo de la escalabilidad quizá se debería cumplimentar con alguna tabla intermedia en lo que en el Software Factory se denomina relaciones Many to Many.
El tema del DBA (Data Base Administrator) es como comentáis un arduo trabajo a nivel sobre todo de definición, y no solo hay que mirar el que los datos cuadren, si no que hay que evaluar la extracción posterior para Reporting. Imaginate en tu supuesto que quisieras saber los importes que han salido como SALIDAS o ENTRADAS de dinero, pues con tu primera propuesta puedes obtener esos datos mediante un inner join a la tabla cuentas y comprobar el Sumatorio de importes con CuentaOrigen o CuentaDestino. La relación en este caso sería Uno a Uno PK FK sin ninguna tabla intermedia.
Más cosas que puedo aportar, la nomenclatura es vital, parace una tonteria y lo se, pero no es lo mismo IdCuentaOrigen que CuentaOrigenId, la primera conduce a error si puede llegar a ser parte de la clave primaria, la segunda te da inequivocamente que es una Foreing Key que va vinculada a otra tabla. Hay que tener en cuenta que en la creación de software cada vez se da más y más el denominado patrón "Code First" que mediante implementación de ORM permiten que una vez generamos el mapa mental de las clases, éstas pasen a ser entidades de Base de Datos, por tanto y por tratarse de Frameworks, estrictos las nomeclaturas entran mucho en juego.
Resumiendo el tostón que estoy dando, es, que tu opción primera tiene mucha validez lógica, que no es la única porque no sabemos que piensa tu cabeza.
Espero haber arroado algo de luz al respecto y si no, lo hemos intentado.
Última modificación: 14-03-2021, 16:40 por calcena.
Gracias calcena
Sinceramente me ha valido de mucho, es más puedo decir que hoy me has enseñado algo nuevo, gracias de verdad. Ah hace tiempo que no pululo por aquí pero ha la vez te echaba de menos.
Saludo, joven.
Sinceramente me ha valido de mucho, es más puedo decir que hoy me has enseñado algo nuevo, gracias de verdad. Ah hace tiempo que no pululo por aquí pero ha la vez te echaba de menos.
Saludo, joven.
(14-03-2021, 16:39)calcena escribió: Más cosas que puedo aportar, la nomenclatura es vital, parace una tonteria y lo se, pero no es lo mismo IdCuentaOrigen que CuentaOrigenId, la primera conduce a error si puede llegar a ser parte de la clave primaria, la segunda te da inequivocamente que es una Foreing Key que va vinculada a otra tabla.
calcena para dejar lo claro. Lo correcto y a la vez inequívoco sería, por ejemplo: Clave primaria [IDCuentaOrigen] y clave foranea [CuentaOrigenID]
¿Es así verdad?
Gracias