Otro problema complejo
Hoy veremos uno de esos temas que damos por sentados y que manejamos a la perfección pero realmente no tenemos ni la más mínima idea como todo en la vida, estoy hablando del diseño de una base de datos. Diseñar es fácil, pero de aquí a que realmente sea el diseño mejor diseño para lo que estamos programado hay muchísima distancia. En fin, vamos a abrir las puertas del infierno que ningún profesor de bases de datos quiere abrir y nosotros como alumnos mucho menos.
Complejidad a la vista
Cuando estamos desarrollando nuestros primeros proyectos nos desvivimos por buscar herramientas que hagan mucho más fácil nuestro trabajo tales como un lenguaje de sintaxis clara, un framework adecuado, un IDE muy cool que tenga colores por todos lados pero nos olvidamos de una parte bastante importante: cómo guardamos los datos. Ya sea que te decidas por una base de datos relacional o una no relacional el tema no deja de ser uno de los problemas más complejos en estos días pero todo tiene una explicación: sí, nos dan muchas clases de programación pero apenas una o dos de bases de datos.
Con tan poco tiempo dedicado a manejar datos, un estudiante nunca termina de entender cómo hacer esto de manera correcta y termina por comenzar a hacer las tablas y normalizarlas hasta la tercera forma normal, todo porque así recuerda que su profesor dijo que se tenía que hacer, sin embargo, nada dista más de la realidad. Entonces, ¿cuál es la mejor manera de comenzar a diseñar una base de datos? Bueno, a continuación abordamos este tema.
Primero lo primero
Antes de hacer cualquier diseño en un programa, una hoja de papel o siquiera en tu imaginación tienes que conocer 2 cosas: la naturaleza de tus datos y cómo se accederán a ellos. Lo primero para saber qué tipo de base de datos es la que te conviene más, si tus datos estarán previamente estructurados como el caso de una factura o un formulario desde luego te conviene una base de datos relacional, en cambio, si tus datos no tienen una estructura uniforme, una base de datos no relacional es una mejor idea aunque también quizá quieras ver primero otros factores que impacten en tu proyecto tales como la escalabilidad, precio y compatibilidad, ¿verdad que ya se complicaron las cosas?
Eso sólo tiene que ver con la naturaleza de tus datos, pero cuando ya hayas elegido uno de los dos tipos de bases de datos ahora viene la parte de diseñar cómo tus datos estarán almacenados, y para esto tienes que pensar en cómo tus datos serán consultados. La manera en que se harán las consultas impacta directamente en el rendimiento de la base de datos y si por alguna razón duplicas información o tienes que hacer una query con demasiados joins entonces estarás en un gran problema.
¿Ahora qué?
¿Ya tienes tu esquema bien diseñado y ya elegiste el tipo de base de datos? Felicidades, pero todavía no es el fin. Si tu base de datos es relacional ahora tendrás que normalizarlas y parar cuando el sistema que estés desarrollando lo requiera, por ejemplo, si llegas hasta una tercera o cuarta forma normal tendrás muchísimas tablas y un infierno por programar pero si te quedas en la primera forma normal o en la segunda ahora tendrás muchos datos duplicados, ¿verdad que no es tan sencillo?
Si sigues todos los pasos anteriores tendrás el tipo de base de datos adecuada para tu proyecto, claro, todo esto si ya has definido correctamente el alcance de tu proyecto y tienes bien definidos sus límites, ¿ya comienzas a creer que el software es complejo? Más vale que comiences a creerlo.
Pasos finales
En las primeras entradas que estaban dedicadas al Diseño Orientado a Objetos hablamos sobre la importancia de abandonar las cosas en el momento indicado y también aplica cuando estés diseñando bases de datos, no dudes en dejar ir una mala idea aún y cuando le hayas dedicado bastante tiempo. El no dejar ir una de estas soluciones erróneas te puede costar aún más caro que todos los recursos que le hayas invertido así que no tengas miedo de hacer esto.
En conclusión, diseñar una base de datos no es nada fácil y de nuevo, este tipo de habilidades sólo lo desarrollarás con la práctica. No estoy diciendo que tienes que formar parte de un proyecto extremadamente complejo y echártelo al hombro aún cuando no sabes nada, no, comienza planteándote proyectos imaginarios y pide consejo de tus maestros cuando te encuentres en un camino sin salida. No me pareció necesario incluir un ejemplo o una lista de pasos estructurados para diseñar una base de datos o normalizar, para esto puedes consultar un libro o buscar información en Google, seguramente ellos lo harán mucho mejor que yo.
En fin, otra entrada que concluimos en este blog... ¡Nos vemos a la vuelta!
Complejidad a la vista
Cuando estamos desarrollando nuestros primeros proyectos nos desvivimos por buscar herramientas que hagan mucho más fácil nuestro trabajo tales como un lenguaje de sintaxis clara, un framework adecuado, un IDE muy cool que tenga colores por todos lados pero nos olvidamos de una parte bastante importante: cómo guardamos los datos. Ya sea que te decidas por una base de datos relacional o una no relacional el tema no deja de ser uno de los problemas más complejos en estos días pero todo tiene una explicación: sí, nos dan muchas clases de programación pero apenas una o dos de bases de datos.
Con tan poco tiempo dedicado a manejar datos, un estudiante nunca termina de entender cómo hacer esto de manera correcta y termina por comenzar a hacer las tablas y normalizarlas hasta la tercera forma normal, todo porque así recuerda que su profesor dijo que se tenía que hacer, sin embargo, nada dista más de la realidad. Entonces, ¿cuál es la mejor manera de comenzar a diseñar una base de datos? Bueno, a continuación abordamos este tema.
Primero lo primero
Antes de hacer cualquier diseño en un programa, una hoja de papel o siquiera en tu imaginación tienes que conocer 2 cosas: la naturaleza de tus datos y cómo se accederán a ellos. Lo primero para saber qué tipo de base de datos es la que te conviene más, si tus datos estarán previamente estructurados como el caso de una factura o un formulario desde luego te conviene una base de datos relacional, en cambio, si tus datos no tienen una estructura uniforme, una base de datos no relacional es una mejor idea aunque también quizá quieras ver primero otros factores que impacten en tu proyecto tales como la escalabilidad, precio y compatibilidad, ¿verdad que ya se complicaron las cosas?
Eso sólo tiene que ver con la naturaleza de tus datos, pero cuando ya hayas elegido uno de los dos tipos de bases de datos ahora viene la parte de diseñar cómo tus datos estarán almacenados, y para esto tienes que pensar en cómo tus datos serán consultados. La manera en que se harán las consultas impacta directamente en el rendimiento de la base de datos y si por alguna razón duplicas información o tienes que hacer una query con demasiados joins entonces estarás en un gran problema.
¿Ahora qué?
¿Ya tienes tu esquema bien diseñado y ya elegiste el tipo de base de datos? Felicidades, pero todavía no es el fin. Si tu base de datos es relacional ahora tendrás que normalizarlas y parar cuando el sistema que estés desarrollando lo requiera, por ejemplo, si llegas hasta una tercera o cuarta forma normal tendrás muchísimas tablas y un infierno por programar pero si te quedas en la primera forma normal o en la segunda ahora tendrás muchos datos duplicados, ¿verdad que no es tan sencillo?
Si sigues todos los pasos anteriores tendrás el tipo de base de datos adecuada para tu proyecto, claro, todo esto si ya has definido correctamente el alcance de tu proyecto y tienes bien definidos sus límites, ¿ya comienzas a creer que el software es complejo? Más vale que comiences a creerlo.
Pasos finales
En las primeras entradas que estaban dedicadas al Diseño Orientado a Objetos hablamos sobre la importancia de abandonar las cosas en el momento indicado y también aplica cuando estés diseñando bases de datos, no dudes en dejar ir una mala idea aún y cuando le hayas dedicado bastante tiempo. El no dejar ir una de estas soluciones erróneas te puede costar aún más caro que todos los recursos que le hayas invertido así que no tengas miedo de hacer esto.
En conclusión, diseñar una base de datos no es nada fácil y de nuevo, este tipo de habilidades sólo lo desarrollarás con la práctica. No estoy diciendo que tienes que formar parte de un proyecto extremadamente complejo y echártelo al hombro aún cuando no sabes nada, no, comienza planteándote proyectos imaginarios y pide consejo de tus maestros cuando te encuentres en un camino sin salida. No me pareció necesario incluir un ejemplo o una lista de pasos estructurados para diseñar una base de datos o normalizar, para esto puedes consultar un libro o buscar información en Google, seguramente ellos lo harán mucho mejor que yo.
En fin, otra entrada que concluimos en este blog... ¡Nos vemos a la vuelta!
Comentarios
Publicar un comentario