Ya sea que esté trabajando con una base de datos que tiene cientos de registros o millones de registros, el diseño adecuado de la base de datos siempre es importante. No solo hará que recuperar la información sea mucho más fácil, sino que también simplificará la expansión de la base de datos en el futuro. Desafortunadamente, es fácil caer en algunas trampas que pueden dificultar las cosas en el futuro.
Hay libros completos escritos sobre el tema de la normalización de una base de datos, pero si simplemente evita los errores comunes que se muestran aquí, estará en el camino correcto hacia un buen diseño de la base de datos.
Error de base de datos # 1: Repetir campos en una tabla
Una regla básica para un buen diseño de la base de datos es reconocer los datos repetidos y colocar esas columnas repetitivas en su propia tabla. La repetición de campos en una tabla es común para aquellos que provienen del mundo de las hojas de cálculo, pero mientras que las hojas de cálculo tienden a ser planas, las bases de datos deben ser relacionales. Es como pasar de 2D a 3D.
Por suerte, los campos repetitivos suelen ser fáciles de detectar. Basta con echar un vistazo a esta tabla:
| Solicitar ID | Producto1 | Producto2 | Producto3 |
| 1 | Osos de peluche | Frijolitos confitados | |
| 2 | Frijolitos confitados |
¿Qué sucede cuando un pedido contiene cuatro productos? Necesitaríamos agregar otro campo a la tabla para admitir más de tres productos. Y si hemos creado una aplicación cliente alrededor de la tabla para ayudarnos a ingresar datos, es posible que tengamos que modificarla con el nuevo campo de producto. ¿Y cómo encontramos todos los pedidos con Jellybeans en el pedido? Nos veríamos obligados a consultar cada campo de producto en la tabla con una declaración de SQL que podría ser: SELECCIONAR * DE PRODUCTOS DONDE Producto1 = 'Frijoles de jalea' O Producto2 = 'Frijoles de jalea' O Producto3 = 'Frijoles de jalea'.
En lugar de tener una sola tabla que rellene toda la información, deberíamos tener tres tablas en las que cada una contenga una información distinta. En este ejemplo, desearíamos una tabla de pedidos con información sobre el pedido en sí, una tabla de productos con todos nuestros productos y una tableta de pedidos de productos que vinculara los productos con el pedido.
| Solicitar ID | Identificación del cliente | Fecha de orden | Total |
| 1 | 7 | 1/24/17 | 19.99 |
| 2 | 9 | 1/25/17 | 24.99 |
| Identificación de producto | Producto | Contar |
| 1 | Osos de peluche | 1 |
| 2 | Frijolitos confitados | 100 |
| ProductOrderID | Identificación de producto | Solicitar ID |
| 101 | 1 | 1 |
| 102 | 2 | 1 |
Observe cómo cada tabla tiene su propio campo de ID único. Esta es la clave principal. Enlazamos tablas utilizando un valor de clave principal como clave externa en otra tabla. Lea más sobre claves primarias y claves externas.
Error de la base de datos # 2: Incrustar una tabla en una tabla
Este es otro error común, pero no siempre se destaca tanto como los campos repetitivos. Al diseñar una base de datos, debe asegurarse de que todos los datos de una tabla estén relacionados con sí mismos. Es como el juego de ese niño para detectar lo que es diferente. Si tienes un plátano, una fresa, un melocotón y un televisor, el televisor probablemente pertenezca a otro lugar.
En la misma línea, si tiene una tabla de vendedores, toda la información en esa tabla debe estar relacionada específicamente con esa persona de ventas. Cualquier información adicional que no sea exclusiva de ese vendedor puede pertenecer a otra parte de su base de datos.
| SalesID | primero | Último | Dirección | Número de teléfono | Oficina | Número de oficina |
| 1 | Sam | Elliot | 118 Main St, Austin, TX | (215) 555-5858 | Austin Downtown | (212) 421-2412 |
| 2 | Alicia | Herrero | 504 2nd Street, Nueva York, NY | (211) 122-1821 | Nueva York (este) | (211) 855-4541 |
| 3 | Joe | Parroquia | 428 Aker St, Austin, TX | (215) 545-5545 | Austin Downtown | (212) 421-2412 |
Si bien esta tabla puede parecer que todo está relacionado con el vendedor individual, en realidad tiene una tabla incrustada dentro de la tabla. Observe cómo la Oficina y la Oficina se repiten con "Austin Downtown". ¿Qué pasa si un número de teléfono de oficina cambia? Necesitaría actualizar todo un conjunto de datos para cambiar una sola pieza de información, lo que nunca es bueno. Estos campos deben ser movidos a su propia tabla.
| SalesID | primero | Último | Dirección | Número de teléfono | OfficeID |
| 1 | Sam | Elliot | 118 Main St, Austin, TX | (215) 555-5858 | 1 |
| 2 | Alicia | Herrero | 504 2nd Street, Nueva York, NY | (211) 122-1821 | 2 |
| 3 | Joe | Parroquia | 428 Aker St, Austin, TX | (215) 545-5545 | 1 |
| OfficeID | Oficina | Número de oficina |
| 1 | Austin Downtown | (212) 421-2412 |
| 2 | Nueva York (este) | (211) 855-4541 |
Este tipo de diseño también le brinda la posibilidad de agregar información adicional a la tabla de Office sin crear una pesadilla de desorden en la tabla de vendedor. ¡Imagine cuánto trabajo sería simplemente hacer un seguimiento de la dirección, la ciudad, el estado y el código postal si toda esa información estuviera en la tabla de vendedores!
Error de la base de datos # 3: Poner dos o más datos en un solo campo
La incorporación de la información de la oficina en la tabla de vendedores no fue el único problema con esa base de datos. El campo de dirección contenía tres datos: la dirección, la ciudad y el estado. Cada campo en la base de datos solo debe contener una sola pieza de información. Cuando tiene varias piezas de información en un solo campo, puede ser más difícil consultar la base de datos para obtener información.
Por ejemplo, ¿qué pasaría si quisiéramos realizar una consulta a todos los vendedores de Austin? Tendríamos que buscar dentro del campo de dirección, que no solo es ineficiente, sino que también puede devolver información errónea. Después de todo, ¿qué pasa si alguien vivía en la calle Austin en Portland, Oregon?
Así es como debería verse la tabla:
| SalesID | primero | Último | Dirección 1 | Dirección 2 | Ciudad | Estado | Cremallera | Teléfono |
| 1 | Sam | Elliot | 118 Main St | Austin | TX | 78720 | 2155555858 | |
| 2 | Alicia | Herrero | 504 2nd St | Nueva York | Nueva York | 10022 | 2111221821 | |
| 3 | Joe | Parroquia | 428 Aker St | Apt 304 | Austin | TX | 78716 | 2155455545 |
Hay un par de cosas a tener en cuenta aquí.Primero, "Address1" y "Address2" parecen caer bajo el error de campos repetitivos.
Sin embargo, en este caso, se refieren a datos separados que se relacionan directamente con la persona de ventas en lugar de a un grupo repetitivo de datos que deben ir en su propia tabla.
Además, como un error adicional que debe evitarse, observe cómo el formato para el número de teléfono se ha eliminado de la tabla. Debe evitar almacenar el formato de los campos cuando sea posible. En el caso de los números de teléfono, hay varias formas en que las personas escriben un número de teléfono: 215-555-5858 o (215) 555-5858. Esto haría más difícil la búsqueda de un vendedor por su número de teléfono o hacer una búsqueda de personal de ventas en el mismo código de área.
Error de la base de datos # 4: no usar una clave primaria correcta
En la mayoría de los casos, deseará usar un número que se incremente automáticamente o algún otro número generado o alfanumérico para su clave principal. Debe evitar el uso de información real para la clave principal, incluso si parece que sería un buen identificador.
Por ejemplo, cada uno de nosotros tiene su propio número de seguridad social individual, por lo que usar el número de seguridad social para la base de datos de un empleado puede parecer una buena idea. Pero aunque es raro, incluso un número de seguridad social puede cambiar, y nunca queremos que cambie nuestra clave principal.
Y ese es el problema con el uso de información real como un valor clave. Puede cambiar
Error de la base de datos # 5: No usar una convención de nomenclatura
Es posible que esto no parezca una gran cosa cuando empiece a diseñar su base de datos, pero una vez que llegue al punto de escribir consultas en la base de datos para recuperar información, contar con una convención de nombres ayudará a memorizar los nombres de los campos.
Solo imagine cuánto más difícil sería ese proceso si los nombres se almacenaran como Nombre, Apellido en una tabla y Nombre primero, Apellido en otra tabla.
Las dos convenciones de nomenclatura más populares son poner en mayúscula la primera letra de cada palabra en el campo o separar las palabras con un guión bajo. También puede ver a algunos desarrolladores que escriben con mayúscula la primera letra de cada palabra, excepto la primera palabra: primer nombre, apellido.
También querrá decidir usar nombres de tablas singulares o nombres de tablas plurales. ¿Es una tabla de órdenes o una tabla de órdenes? ¿Es una tabla de clientes o una tabla de clientes? Nuevamente, no desea quedarse atascado con una tabla de pedidos y una tabla de clientes.
La convención de nombres que elija no es tan importante como el proceso de elegir y adherirse a una convención de nombres.
Error de la base de datos # 6: Indización incorrecta
La indexación es una de las cosas más difíciles de corregir, especialmente para aquellos nuevos en el diseño de bases de datos. Todas las claves primarias y las claves externas deben estar indexadas. Esto es lo que vincula las tablas, así que sin un índice, verá un rendimiento muy pobre de su base de datos.
Pero lo que a menudo se pasa por alto son los otros campos. Estos son los campos "DONDE". Si a menudo va a limitar su búsqueda utilizando un campo en una cláusula WHERE, debe pensar en colocar un índice en ese campo. Sin embargo, no desea indexar excesivamente la tabla, lo que también puede afectar el rendimiento.
¿Cómo decidir? Esto es parte del arte del diseño de bases de datos. No hay límites estrictos sobre cuántos índices debe colocar en una tabla. Principalmente, desea indexar cualquier campo que se use con frecuencia en una cláusula WHERE. Lea más acerca de cómo indexar correctamente su base de datos.
