Cita:
Iniciado por JhondeKharl 
Mmm. . . Si, ¿verdad? Para "tres tablas", Tres Semanas, suena más que exagerado, pena mas. Pero tengo mi excusa! Aprender todo este mundo nuevo me llevó mi tiempo, sin mencionar que todo lo que me dijeron fue "Haz un banco de reactivos". . . y ¡ya! Pero bueno, ya teniendo mi interfaz (programa en escritorio, todavía tengo que pelear con PHP para subirlo a la red. . . ese otro *edo ¬¬')
Doy las gracias por la. . . guía (sigo sin saber el ¡por que? debe de ser así, pero bueno). Sólo necesitaba un empujón para saber que tan mal encaminado iba y al parecer más que mal, estaba en la dirección contraria. Sin embargo, sólo me queda una duda. ¿Como hago la "consulta" para guardar una imagen (en Mysql, o Workbench {que es lo mismo pero sin consola})? y ¿Que tipo de variable es el más ajustado? Unos me recomiendan Varbinary y otro Blob más no me explican como usarlos correctamente.
De antemano agradezco toda la ayuda disponible. Igualmente muchas gracias TheLibras~ saludos~
Vamos al principiobásico: Si son imágenes, no es buena idea guardarlas en la base de datos, a menos que sea una exigencia téncia o de sistema debiidamente fundamentada.
Lo usual, y lo práctico, es almacenar las imagenes en carpetas, y las rutas de acceso a las mismas en la base.
En ese sentido, "variables" no son temas de la base. Los campos sobn VARCHAR o BLOB, según se neesite para el caso.
En cuanto a lo que comenta Libras, es parcialmente correcto: La base se fundamenta en el
sistema a soportar, y no en la aplicación, así como la aplicación
no debe ser un reflejo de la base.
Esto es un tema de larga data y discusión, pero la idea es que:
- Una base debe ser lo suficientmente flexible como para responder a todas las consultas que pueda cubrir con sus datos, sin importar qué aplicación la invoque.
- La aplicación debe cumplir con losprocesos de negocio, no ajustarse a la estructura de la base.
- No debe existir exceso de acoplamiento entre ambas cosas, a fin de evitar que un cambio en una de ellas genere un fallo o inconsistencias.
Fundamentalmente:
- Las aplicaciones están orientadas a procesos, cumplen reglas de negocio. Las bases de Datos NO, se orientan a DATOS, en abstracción a su uso, y protege las restricciones de negocio, pero no las origina.
- Las bases de datos están orientadas al sistema, en abstracto. No a los procesos. Están más cerca de la representación de clases del sistema, que de las interfases de usuario.
Entremedio de las dos cosas (UI y DB) existe una capa que genera la relación (BL), y es allí donde se resuelve los procesos hacia y desde la base.
No hay que confundir los roles de cada cosa.