Explorar los consejos de diseño de base de datos

Video: Curso Bases de Datos

Uno de los aspectos más importantes de cualquier proyecto de desarrollo de aplicaciones es el diseño de base de datos. Y así, sin más preámbulos, aquí están algunos consejos para el diseño de buenas bases de datos.

Utilice el número correcto de tablas

En Amadeo, el emperador de Alemania critica una de las obras de Mozart que tiene “demasiadas notas”. Mozart responde indignado que no usa ni demasiadas ni demasiado pocas notas, pero el número exacto de las notas que la composición requiere.

Por lo tanto, debe ser con un diseño de base de datos. Su base de datos debe tener tantas tablas como la aplicación requiere - no más, no menos. No existe un único número “correcto” de las tablas para todas las bases de datos.

los diseñadores de bases de datos sin experiencia tienen una tendencia a utilizar demasiado pocas mesas - a veces tratando de meter una base de datos entera-el valor de la información en una sola tabla. En el otro extremo están las bases de datos con decenas de mesas, cada una compuesta de sólo unos pocos campos.

Video: Diseño Lógico de Bases de Datos

Evitar la repetición de los datos

Uno de los principios básicos de diseño de base de datos relacional es manejar datos que se repiten rompiéndolo a cabo en una tabla separada. Por ejemplo, en los viejos tiempos de procesamiento de archivo plano, era común para crear registros de facturas que tenían espacio para un cierto número de elementos de línea. Así, el registro de factura tendría campos con nombres como Elemento1, Item2, Elemento3, y así.

¡Malo!

Siempre que se encuentre la numeración nombres de campo por el estilo, se debe crear una tabla separada. En el caso del registro de factura, se debe crear una tabla separada para almacenar los datos de líneas.

Evitar los datos redundantes

En el diseño de las tablas que componen su base de datos, trate de evitar la creación de datos redundantes. Siempre que los datos redundantes se arrastra en una base de datos, se introduce la posibilidad de que los datos llegarán a ser corrupto. Por ejemplo, supongamos que almacena el nombre del cliente en dos tablas diferentes. Entonces, si se actualiza el nombre en una de las mesas pero no el otro, la base de datos se ha convertido inconsistente.

El tipo más obvio de error redundante de datos es crear un campo que existe en dos o más tablas. Pero hay tipos más sutiles de datos redundantes. Por ejemplo, considere una Factura tabla que contiene una LineItemTotal campo que representa la suma de las Total campos en cada uno de los elementos de línea de la factura. Técnicamente, este campo representa redundante Data- los datos también se almacena en el Total campos de cada elemento de línea.

Si se debe permitir que este tipo de redundancia depende de la aplicación. En muchos casos, es mejor que soportar la redundancia para la comodidad y la eficiencia de no tener que volver a calcular el total de cada vez que se accede a los datos. Pero siempre vale la pena considerar si la comodidad vale la pena el riesgo de dañar los datos.

Utilizar una convención de nomenclatura

Para evitar confusiones, elegir una convención de nomenclatura para los objetos de base de datos y se adhieren a ella. De esa manera las tablas de bases de datos, columnas, restricciones y otros objetos será nombrado de una manera consistente y predecible. (Basta pensar en el ahorro en la aspirina.)

Video: Bases de Datos - Ejercicio completo modelo Entidad-Relación a modelo relacional

Se puede argumentar a partir de ahora y hasta el día de San Swithen acerca de lo que las convenciones de nomenclatura debería ser. Eso no importa tanto. Lo que importa es que usted haga una convención - y lo sigue.

Evitar los nulos

Permitiendo nulos en sus tablas de la base complica significativamente la programación de la aplicación requerida para acceder a las tablas. Como resultado de ello, evitar los nulos especificando NOT NULL siempre que pueda. Utilice nulos en raras ocasiones, y sólo cuando realmente los necesite.

Los valores nulos son a menudo mal uso de todos modos. El uso correcto de nulo es un valor que se desconocen, no para un valor en blanco o vacío. Por ejemplo, considere un registro de dirección típico que permite que dos líneas de dirección, de nombre Dirección 1 y Dirección 2. La mayoría de las direcciones tienen una sola dirección, por lo que la segunda línea de dirección está en blanco. El valor de esta segunda línea de dirección es, de hecho, conocido - que está en blanco. Eso no es lo mismo que nulo. Nula implicaría que la dirección puede tener una segunda dirección de línea simplemente no sabemos lo que es.

Incluso para las columnas que podrían parecer apropiado para los nulos, por lo general es más conveniente simplemente deje en blanco el valor de la columna para los valores que no son conocidos. Por ejemplo, considere una número de teléfono columna en una Cliente mesa. Es seguro asumir que todos sus clientes tienen números de teléfono, por lo que sería correcto utilizar nulo para números de teléfono que no conoce. Sin embargo, desde un punto de vista práctico, es igual de fácil para no permitir valores nulos para la columna de número de teléfono, y dejar a los números de teléfono desconocidos en blanco.

Evitar códigos secretos

Evite los campos con nombres como Tipo de cliente, donde el valor del campo es una de varias constantes que no están definidos en otra parte de la base de datos, tales como R para Al por menor o W para Al por mayor. Es posible que tenga sólo estos dos tipos de clientes actuales, pero las necesidades de la aplicación puede cambiar en el futuro, lo que requiere un tercer tipo de cliente.

Una alternativa sería la creación de una mesa aparte de los códigos de tipo de cliente (llámese CustomerTypes) Y, a continuación, crear una restricción de clave foránea por lo que el valor de la Tipo de cliente la columna debe aparecer en el CustomerTypes mesa.

Utilizar sabiamente limitaciones

restricciones le permiten evitar que los cambios en la base de datos que violan la consistencia interna de los datos. Por ejemplo, una restricción de comprobación permite validar únicos datos que cumple con ciertos criterios. Por ejemplo, puede utilizar una restricción de comprobación para asegurarse de que el valor de un campo denominado Precio es mayor que cero.

UN restricción de clave foránea requiere que el valor de una columna en una tabla debe coincidir con el valor que existe en alguna otra mesa. Por ejemplo, si tiene una Artículos de línea tabla con una columna llamada ID del Producto, y una productos tabla con una columna también nombró ID del Producto, usted podría utilizar una restricción de clave foránea para asegurarse de que la ID del Producto valor para cada fila de la Artículos de línea tabla coincida con un registro existente en el productos mesa.

Uso desencadena cuando sea apropiado

UN desencadenar es un procedimiento que se activa cuando ciertos datos de base de datos se actualiza o se accede. Los factores desencadenantes son una gran manera de hacer cumplir las reglas de base de datos que son más complicadas que las restricciones simples. Por ejemplo, supongamos que una Factura tabla contiene una Recuento de elementos columna cuyo valor es el número de elementos de línea de la factura. Una forma de mantener el valor de esta columna de forma automática sería la creación de disparadores que se incrementan la Recuento de elementos columna siempre que se inserta un elemento de línea, y disminuir el Recuento de elementos columna cada vez que se elimina un elemento de línea. A veces, la automatización es una cosa hermosa.

Utilizar procedimientos almacenados

Procedimientos almacenados son procedimientos de SQL que se encuentran escondidos en la base de datos y que son parte de ella. Hay varias ventajas de utilizar procedimientos almacenados en lugar de SQL en sus aplicaciones de codificación:

El uso de procedimientos almacenados elimina la carga de la programación SQL desde sus programadores de aplicaciones. En su lugar, hace que el SQL que se utiliza para acceder a la base de datos una parte de la base de datos en sí - sin problemas, sin despeinarse. Todo los programas de aplicación tienen que hacer es llamar al procedimiento almacenado adecuado para seleccionar, insertar, actualizar o eliminar datos de bases de datos.

Los procedimientos almacenados son más eficientes como una forma de manipulación de las transacciones, ya que el servidor de base de datos se encarga de toda la transacción.

Los procedimientos almacenados son también más eficientes, ya que reducen la cantidad de tráfico de red entre el servidor de base de datos y el servidor Web.

Por último, los procedimientos almacenados son más seguros, ya que reducen el riesgo de ataques de inyección SQL.