Las hojas de cálculo (Excel, Google Sheets o una hoja con cualquier otro nombre) son herramientas realmente geniales y poderosas. Pero entonces, también lo son las bases de datos. ¿Cuándo deberías quedarte con una hoja de cálculo? ¿Cuándo debería pasar a una base de datos?
Esta es la continuación de mi artículo anterior "Hojas de cálculo frente a bases de datos:¿es hora de cambiar?" donde hemos discutido las desventajas más comunes de usar hojas de cálculo para organizar muchos datos. En este artículo, descubriremos cómo una base de datos resuelve esos problemas.
Uso de una base de datos para organizar datos
Mi lema es “utiliza la tecnología adecuada a tus necesidades”. Si puede administrar su negocio a través de hojas, ¡genial! Si necesita una base de datos simple, MS Access no es una mala opción. Pero si estos productos no funcionan para usted, probablemente necesitará una base de datos personalizada y una aplicación web. La base de datos almacenará sus datos; la aplicación web será una forma fácil de usar para interactuar con la base de datos y comunicarse con la capa de datos.
Nuestro negocio de servicios ficticio no era muy complicado, por lo que podíamos impulsarlo usando un modelo de datos bastante simple. Si observa la imagen a continuación, verá que todo lo que necesitamos está almacenado en solo cinco tablas:client_type , client , service , replacement y has_service .
Una regla clave del diseño de bases de datos es mantener los datos relacionados del mundo real en un solo lugar. . En este caso, mantendremos todo nuestro client datos en la tabla de clientes. De esta manera, evitaremos almacenar los mismos datos en múltiples ubicaciones (el tipo de redundancia malo mencionado anteriormente). Si cambiamos algo relacionado con un cliente, lo haremos una sola vez, en esta tabla. Esto mejorará en gran medida la calidad de los datos y será bueno para el rendimiento.
La siguiente tabla que contiene datos del mundo real es el service mesa. Nuevamente, podemos almacenar todos los detalles relacionados con nuestros servicios aquí y podemos realizar cambios en los datos de manera bastante eficiente.
El client tabla y el service table son entidades del mundo real que podrían existir sin la otra. Sin embargo, crear una base de datos con entidades no relacionadas no tiene mucho sentido, es como tener clientes sin productos o servicios sin compradores. Entonces relacionaremos estas dos tablas usando el has_service mesa. Para almacenar información sobre qué clientes tienen qué servicio, usaremos claves externas que actúan como referencias a ese cliente y servicio. Estas claves foráneas apuntan a registros en las tablas de servicios y clientes. También podemos mantener cualquier información adicional relacionada con cada relación de servicio al cliente en esta tabla.
El client_type table se utiliza como un diccionario que almacena todos los tipos posibles de clientes. Es mejor mantener diferentes segmentaciones en tablas de diccionario separadas (por ejemplo, si tuviéramos tipos de clientes y tipos de roles de empleados, los almacenaríamos en tablas diferentes). Sin embargo, solo necesitamos una mesa porque este es un modelo simple.
La última tabla de nuestro modelo es el replacement mesa. Lo usaremos para relacionar dos servicios:un servicio que queremos reemplazar y el servicio de reemplazo. Esto nos brinda la flexibilidad de ofrecer a los clientes reemplazos para los servicios existentes (muy parecido a cambiar de un plan de llamadas móviles a otro).
Ventajas de la base de datos
Las bases de datos son más complicadas de configurar que las hojas de cálculo, pero esto les brinda algunas ventajas significativas en términos de integridad y seguridad de los datos:
Claves y restricciones
Las bases de datos tienen reglas y controles incorporados que, si se usan correctamente, evitarán la mayoría de los problemas de calidad y rendimiento de los datos. Las claves primarias (columnas que identifican de manera única cada registro en una tabla) y las claves externas (columnas que hacen referencia a un registro en otra tabla) son críticas para la seguridad de los datos, pero definir claves alternativas o ÚNICAS (que contienen datos únicos para cada registro en una tabla) ) también es muy útil.
En las bases de datos relacionales, las claves relacionan datos de diferentes tablas. La clave principal de la tabla siempre es ÚNICA, mientras que una clave externa hace referencia a la clave principal de alguna otra tabla. Esa referencia relaciona datos de estas dos tablas (por ejemplo, las claves foráneas en has_service relacionar los datos de los clientes con los servicios que tienen). También nos avisará si estamos a punto de eliminar una clave principal referenciada en alguna otra tabla. Esto evitará que eliminemos registros que todavía se necesitan (como referencias) en otra tabla.
Las restricciones definen el tipo de datos que se pueden ingresar en un campo. Podemos especificar que los datos deben tener valor (NO NULL), definir un formato para los números de teléfono, contener solo letras, etc. Esto significa que podemos evitar problemas de datos por parte de personas que ingresan datos incorrectos en un campo.
Seguridad y permisos
Otra característica muy importante de la base de datos es controlar el acceso a sus datos . Esto le brinda la capacidad de establecer no solo quién puede acceder a su base de datos, sino también controlar lo que pueden ver o modificar. Esta es una gran parte de la seguridad de los datos. Por ejemplo, podría definir un rol de usuario que permitiría a un empleado cambiar los detalles del cliente pero no los detalles del servicio. También puede establecer reglas sobre qué empleados pueden cambiar o eliminar datos. Es una buena práctica estándar asegurarse de que las personas solo tengan acceso a los datos que necesitan para hacer su trabajo.
Por supuesto, podríamos intentar recrear estas funcionalidades en hojas (al menos de alguna manera), pero eso definitivamente sería "reinventar la rueda".
¿No podríamos simplemente usar una hoja de cálculo?
Por supuesto que podríamos. Podríamos crear hojas que sigan el mismo patrón utilizado en el modelo de datos. Eso resolvería muchos problemas de datos, pero...
La replicación del modelo de datos en hojas definitivamente no es una opción ideal. Perderíamos todas las ventajas que nos brinda el sistema de base de datos, todas las reglas y restricciones que mantienen los datos "saludables", todas las cosas que evitan eliminaciones accidentales y otros errores. Perderíamos la optimización y, si el conjunto de datos fuera lo suficientemente grande, el rendimiento se vería afectado.
Incluso si solucionamos eso, ¿qué hay de compartir datos, p. tener varios usuarios usando la misma hoja al mismo tiempo? ¿Qué problemas de integridad de datos y rendimiento causaría esto? Esto sería lo opuesto a simplificar las cosas.
Entonces, si cree que las hojas no pueden manejar sus necesidades comerciales, probablemente ya se esté dirigiendo hacia una base de datos. Si se encuentra atascado con datos almacenados en hojas y desea pasar a una base de datos, debe:
- Cree un modelo de base de datos que almacene sus datos de manera óptima.
- Cree una aplicación con la base de datos en segundo plano.
- Borre sus datos, transfórmelos (si es necesario) e impórtelos a la base de datos.
- Continúe trabajando solo con la base de datos.
¿Cuál debería elegir:hoja de cálculo o base de datos?
En el artículo de hoy, hemos aprendido cómo una base de datos resuelve problemas con el uso de hojas para organizar muchos datos. Mi consejo es siempre vaya con la solución más simple a su problema . Si las hojas de cálculo hacen el trabajo correctamente, utilícelas. Pero si es una empresa basada en datos, debe comenzar a usar una base de datos lo antes posible. Cuanto más espere para limpiar y migrar sus datos, más doloroso será el proceso.
