Erros comúns feitos no deseño de bases de datos

Se está a traballar cunha base de datos que ten centos de rexistros ou millóns de rexistros, o bo deseño de bases de datos sempre é importante. Non só fará que a recuperación da información sexa moito máis sinxela, tamén simplificará expandir a base de datos no futuro. Desafortunadamente, é fácil caer nunhas poucas trampas que poden dificultar o futuro.

Hai libros enteiros escritos sobre a normalización dunha base de datos, pero se simplemente evita estes erros comúns, estará no bo camiño para o bo deseño da base de datos.

Erro de base de datos n. º 1: repetir os campos nunha táboa

Unha regra xeral básica para o bo deseño da base de datos é recoñecer a repetición de datos e poñer esas columnas repetidas na súa propia táboa. Repetindo os campos nunha táboa é común para os que viñeron do mundo das follas de cálculo, pero mentres as follas de cálculo tenden a ser planas polo deseño, as bases de datos deben ser relacionales. É como pasar de 2D a 3D.

Afortunadamente, os campos repetitivos adoitan ser fáciles de localizar. Basta con botar unha ollada a esta táboa:

Que pasa cando unha orde contén catro produtos? Necesitaríamos engadir outro campo á táboa para soportar máis de tres produtos. E se construímos unha aplicación cliente en torno á táboa para axudarnos a introducir datos, é posible que necesitemos modificar isto co novo campo do produto. E como atopamos todas as ordes con Jellybeans na orde? Quedaríamos obrigados a consultar cada campo de produto na táboa cunha declaración SQL que podería parecerse a: SELECCIONAR * FROM Produtos DONDE Product1 = 'Jelly Beans' Ou Product2 = 'Jelly Beans' Ou Product3 = 'Jelly Beans'.

En lugar de ter unha única táboa que enche toda a información, teremos tres táboas que cada un contén unha información distinta. Neste exemplo queremos unha táboa de pedidos con información sobre a orde en si, unha táboa de produtos con todos os nosos produtos e unha tableta de produtos que ligou os produtos á orde.

Observe como cada táboa ten o seu propio campo ID único. Esta é a clave principal. Ligamos táboas usando un valor de clave primaria como clave estranxeira noutra táboa. Lea máis sobre chaves primarias e claves estranxeiras.

Erro de base de datos n. ° 2: incrustar unha táboa nunha táboa

Este é outro erro común, pero non sempre se destaca tanto como os campos repetitivos. Ao deseñar unha base de datos, quere asegurarse de que todos os datos dunha táboa se relacionen. É como o xogo do neno sobre o que é diferente. Se tes unha banana, unha morango, un melocotón e un televisor, o televisor probablemente pertence a outro lugar.

Na mesma liña, se ten unha táboa de vendedores, toda a información nesa táboa debe relacionarse específicamente con esa persoa vendedora. Calquera información extra que non sexa exclusiva para esa persoa vendedora pode pertencer a outra parte da súa base de datos.

Aínda que esta táboa semella que está todo relacionada co vendedor individual, realmente ten unha táboa inserida dentro da táboa. Observe como se repiten Office e OfficeNumber con "Austin Downtown". E se cambia un número de teléfono da oficina? Necesitaría actualizar un conxunto de datos para cambiar unha única peza de información, o que nunca é bo. Estes campos deben ser movidos á súa propia táboa.

Este tipo de deseño tamén lle dá a capacidade de engadir información adicional á táboa de Office sen crear un pesadelo de desorde na táboa de vendas. Imaxina canto traballo sería seguir o enderezo da rúa, a cidade, o estado e o código postal se toda esa información estaba na táboa de vendas.

Erro de base de datos n. ° 3: Pór dúas ou máis partes de información nun único campo

Incrustar a información da oficina na táboa de vendas non foi o único problema con esa base de datos. O campo de enderezo contiña tres informacións: o enderezo, a cidade eo estado. Cada campo da base de datos só debe conter unha soa información. Cando ten varias pezas de información nun só campo, pode facerse máis difícil de consultar a base de datos para obter información.

Por exemplo, e se queremos realizar unha consulta sobre todos os vendedores de Austin? Necesitamos buscar dentro do campo de enderezos, que non só é ineficiente, pero pode devolver información incorrecta. Despois de todo, que pasa se alguén vivía na rúa Austin en Portland, Oregon?

Vexa como debería parecer a mesa:

Hai algunhas cousas a destacar aquí. En primeiro lugar, "Address1" e "Address2" parecen estar baixo o erro dos campos repetitivos.

Non obstante, neste caso refírense a pezas separadas de datos que se relacionan directamente coa persoa que vende e non a un grupo repetitivo de datos que debería incluír na súa propia táboa.

Ademais, como un erro extra para evitar, observe como o formato do número de teléfono foi eliminado da táboa. Debe evitar almacenar o formato dos campos cando sexa posible. No caso dos números de teléfono, hai moitas formas en que as persoas escriben un número de teléfono: 215-555-5858 ou (215) 555-5858. Isto faría que sexa máis difícil atopar unha persoa de venda polo seu número de teléfono ou facer unha procura de vendedores no mesmo código de área.

Erro de base de datos n. º 4: Non se usa unha clave primaria correcta

Na maioría dos casos, vai querer usar un número de incremento automático ou algún outro número xerado ou alfanumérico para a súa chave primaria. Debe evitar usar calquera información real para a clave principal aínda que pareza que faría un bo identificador.

Por exemplo, cada un ten o noso propio número de seguro social individual, polo que o uso do número de seguridade social para unha base de datos do empregado pode parecer unha boa idea. Pero, aínda que é raro, é posible cambiar un número de seguridade social e nunca queremos cambiar a nosa clave primaria.

E ese é o problema co uso da información real como un valor clave. Pode cambiar.

Erro de base de datos n. ° 5: Non se usa unha convención de nomeamento

Isto pode non soar como un gran negocio cando comezar a deseñar a súa base de datos, pero unha vez que chegue ao momento de escribir consultas contra a base de datos para recuperar información, ter unha convención de nomeamento axudará a memorizar nomes de campo.

Imaxínache canto máis difícil será ese proceso se os nomes foron almacenados como FirstName, LastName nunha táboa e first_name, last_name noutra táboa.

As dúas convencións de nomeamento máis populares son capitalizar a primeira letra de cada palabra no campo ou separar palabras usando un guión baixo. Tamén pode ver algúns desenvolvedores capitalizando a primeira letra de cada palabra excepto a primeira palabra: firstName, lastName.

Tamén quererá decidir sobre o uso de nomes singulares de táboas ou nomes de táboas en plural. ¿É unha táboa de pedidos ou unha táboa de pedidos? ¿É unha táboa de clientes ou táboa de clientes? Unha vez máis, non quere quedar atrapado cunha táboa de pedidos e unha táboa de clientes.

A convención de nomeamento que elixe non é tan importante como o proceso de escoller e adherirse a unha convención de nomeamento.

Erro de base de datos n. ° 6: indexación indebida

A indexación é unha das cousas máis difíciles de conseguir, especialmente para os novos no deseño da base de datos. Todas as chaves primarias e chaves estranxeiras deben estar indexadas. Estas son as táboas de ligazón entre si, polo tanto, sen un índice, verá un desempeño moi baixo da súa base de datos.

Pero o que moitas veces se perde son os outros campos. Estes son os campos "ONDE". Se moitas veces vai limitar a súa busca usando un campo nunha cláusula WHERE, quere pensar en poñer un índice sobre ese campo. Non obstante, non quere indexar demasiado a táboa, que tamén pode prexudicar o rendemento.

Como decidir? Isto forma parte da arte do deseño da base de datos. Non hai límites duros sobre cantos índices debes poñer nunha táboa. Principalmente, quere indexar calquera campo que se use con frecuencia nunha cláusula WHERE. Lea máis sobre indexar correctamente a súa base de datos.