Creo que el título es "Medidas de gestión de seguridad de bases de datos de SQL-Server". ¡Ven y ayúdame!

Experiencia en diseño de bases de datos

Un sistema de gestión exitoso se compone de: [50% negocio + 50% software], y el 50% del software exitoso tiene [25% base de datos + 25% programa ], la calidad del diseño de la base de datos es clave. Si se comparan los datos de una empresa con la sangre necesaria para la vida, entonces el diseño de la base de datos es la parte más importante de la aplicación. Existe una gran cantidad de material sobre diseño de bases de datos, e incluso se trata en cursos universitarios. Sin embargo, como hemos enfatizado repetidamente, no importa cuán bueno sea un maestro, nada puede compararse con las enseñanzas de la experiencia. Así que resumí los desvíos y experiencias que he tomado a lo largo de los años y encontré algunos profesionales con conocimientos en diseño de bases de datos en Internet para enseñarle algunas habilidades y experiencias en diseño de bases de datos. Se han seleccionado y recopilado 60 de los mejores consejos en este artículo. El contenido se divide en 5 partes para facilitar la indexación:

Parte 1: Antes de diseñar la base de datos

Esta sección enumera 12. Habilidades básicas, incluidas convenciones de nomenclatura y clarificación de requisitos comerciales.

Parte 2: Diseño de tablas de bases de datos

Total *** 24 consejos orientativos, que cubren el diseño de campos en tablas y problemas comunes que deben evitarse.

Parte 3 - Seleccionar claves

¿Cómo seleccionar claves? Aquí hay 10 consejos que cubren específicamente el uso correcto de las claves primarias generadas por el sistema, cuándo y cómo indexar campos para un rendimiento óptimo y más.

Parte 4: Garantizar la integridad de los datos

Analice cómo mantener la base de datos clara y sólida, y cómo minimizar los datos dañinos.

Parte 5: varios consejos

Hay muchos otros consejos que no están incluidos en las 4 partes anteriores. Espero que su trabajo de desarrollo de bases de datos sea más fácil.

Parte 1: antes de diseñar una base de datos

Revisar el entorno existente

Al diseñar una nueva base de datos, debe estudiar cuidadosamente no solo los requisitos comerciales sino también los sistema existente. La mayoría de los proyectos de bases de datos no se crean desde cero; a menudo, existen sistemas dentro de la organización que satisfacen necesidades específicas (que pueden no implementar cálculos automatizados). Obviamente, el sistema existente no es perfecto; de lo contrario, no sería necesario construir uno nuevo. Pero estudiar sistemas antiguos puede permitirle descubrir problemas sutiles que de otro modo podría pasar por alto. En términos generales, definitivamente será beneficioso para usted observar sus sistemas existentes.

Defina convenciones de nomenclatura de objetos estándar

Asegúrese de definir convenciones de nomenclatura para los objetos de la base de datos. Para las tablas de bases de datos, es importante determinar si el nombre de la tabla es plural o singular desde el comienzo del proyecto. Además, se deben definir reglas simples para los alias de la tabla (por ejemplo, si el nombre de la tabla es una palabra, el alias serán las primeras 4 letras de la palabra; si el nombre de la tabla es dos palabras, el alias serán las dos primeras). letras de cada palabra) forman un alias de 4 letras; si el nombre de la tabla consta de 3 palabras, también puede tomar una de cada una de las dos primeras palabras y luego dos letras más de la última palabra, y el resultado seguirá siendo un alias de 4 letras y el resto, etc.) Para las tablas de trabajo, el nombre de la tabla puede tener el prefijo WORK_ seguido del nombre de la aplicación que utiliza la tabla. Las columnas [campos] en las tablas requieren un conjunto de reglas de diseño para las claves. Por ejemplo, si la clave es de tipo numérico, puede usar _N como sufijo; si es de tipo carácter, puede usar el sufijo _C. Se deben utilizar prefijos y sufijos estándar para los nombres de columnas [campos]. Para otro ejemplo, si su tabla tiene muchos campos de "dinero", es posible que desee agregar un sufijo _M a cada columna [campo]. Además, es mejor que la columna de fecha [campo] comience con D_ como nombre.

Compruebe las convenciones de nomenclatura entre nombres de tablas, nombres de informes y nombres de consultas. Puede confundirse rápidamente con los nombres de estos diferentes elementos de la base de datos. Si insiste en nombrar los diferentes componentes de estas bases de datos de manera uniforme, al menos debe diferenciarlos anteponiendo a los nombres de estos objetos el prefijo Tabla, Consulta o Informe.

Si utiliza Microsoft Access, puede utilizar los símbolos qry, rpt, tbl y mod para identificar objetos (como tbl_Employees). Cuando trabajaba con SQL Server también usaba tbl para indexar tablas, pero usaba sp_company (ahora sp_feft_) para identificar procedimientos almacenados porque a veces guardaba varias copias si encontraba una mejor manera de hacerlo. Cuando implementé SQL Server 2000, usé udf_ (o una etiqueta similar) para identificar las funciones que escribí.

Si quiere hacer bien su trabajo, primero debe perfeccionar sus herramientas.

Utilice herramientas de diseño de bases de datos ideales, como PowerDesign de SyBase, que admite PB, VB, Delphe y otros lenguajes. ODBC puede conectarse a más de 30 bases de datos populares en el mercado, incluidas dBase, FoxPro, VFP, SQL Server, etc. Me centraré en el uso de PowerDesign cuando tenga la oportunidad en el futuro.

Obtenga el manual de recursos de patrones de datos

Las personas que busquen patrones de ejemplo pueden leer el manual de recursos de patrones de datos, escrito por Len Silverston, W. H. Inmon y Kent Graziano. Libros de modelado que vale la pena tener. El libro incluye capítulos que cubren una variedad de dominios de datos, como personas, organizaciones y desempeño laboral. También puede consultar libros relacionados para obtener más información.

Piensa en el futuro, pero no olvides las lecciones del pasado

Me resulta muy útil preguntar a los usuarios cómo creen que cambiarán sus necesidades en el futuro. Al hacer esto, se logran dos objetivos: en primer lugar, obtendrá una comprensión clara de dónde debe ser más flexible el diseño de su aplicación y cómo evitar cuellos de botella en el rendimiento. En segundo lugar, sabrá que sus usuarios se sorprenderán tanto como usted cuando cambien los requisitos que no lo fueron; identificado de antemano.

¡Asegúrate de recordar las lecciones del pasado! Los desarrolladores también deberíamos ayudarnos unos a otros compartiendo nuestras experiencias. Incluso si los usuarios piensan que ya no necesitan soporte, debemos educarlos al respecto. Todos hemos tenido esos momentos de "desearía haber hecho esto...".

Realizar el diseño lógico antes de la práctica física

Realizar el diseño lógico antes de sumergirse en el diseño físico. A medida que sigue surgiendo una gran cantidad de herramientas CASE, su diseño también puede alcanzar un nivel lógico muy alto y, por lo general, puede comprender mejor todos los aspectos necesarios para el diseño de bases de datos en su conjunto.

Comprenda su negocio

No agregue ni una sola tabla de datos a su esquema ER (entidad-relación) hasta que esté 100% seguro de que el sistema satisface sus necesidades desde la perspectiva del cliente ( ¿Aún no tienes un patrón? Entonces consulta el Consejo 9). Comprender su negocio puede ahorrarle mucho tiempo en etapas posteriores de desarrollo. Una vez que haya identificado las necesidades de su negocio, podrá tomar muchas de las decisiones usted mismo.

Una vez que creas que has aclarado el contenido del negocio, será mejor que tengas una comunicación sistemática con el cliente. Adopte la terminología del cliente y explíquele lo que piensa y lo que escucha. Al mismo tiempo, la base de relaciones del sistema también debe expresarse utilizando palabras como may, will y must. De esta manera, puede permitir que su cliente corrija su propia comprensión y se prepare para el siguiente paso en el diseño de ER.

Cree un diccionario de datos y un diagrama ER

Asegúrese de tomarse el tiempo para crear un diagrama ER y un diccionario de datos. Debe incluir al menos el tipo de datos de cada campo y las claves primaria y externa de cada tabla. Crear diagramas ER y diccionarios de datos lleva un poco de tiempo, pero es completamente necesario para que otros desarrolladores comprendan el diseño completo. Crearlo antes ayudará a evitar posibles confusiones en el futuro, permitiendo que cualquiera que conozca las bases de datos sepa exactamente cómo obtener datos de la base de datos.

No se puede subestimar la importancia de tener un documento actualizado como un diagrama ER, que es útil para mostrar relaciones entre tablas, mientras que un diccionario de datos explica el propósito de cada campo y cualquier Alias. Esto es completamente necesario para la documentación de expresiones SQL.

Creación de patrones

Un diagrama vale más que mil palabras: los desarrolladores no sólo deben leerlo e implementarlo, sino también usarlo para ayudarse a sí mismos y a sus usuarios a hablar. Los esquemas ayudan a mejorar la colaboración para que sea menos probable que surjan grandes problemas en el diseño inicial de la base de datos. El patrón no tiene por qué ser complicado; incluso puede ser tan simple como escribirlo a mano en una hoja de papel. Solo queremos asegurarnos de que la relación lógica pueda producir beneficios en el futuro.

Comience con la entrada y la salida

Al definir los requisitos de campos y tablas de la base de datos (entrada), primero debe verificar los informes, consultas y vistas (salida) existentes o diseñados para decidir qué tablas y Los campos son necesarios para respaldar estos resultados. Un ejemplo simple: si un cliente requiere un informe para ordenar, segmentar y sumar por código postal, desea asegurarse de que incluya un campo de código postal separado y no mezcle el código postal con el campo de dirección.

Consejos para la generación de informes

¿Comprenda cómo los usuarios suelen informar los datos: procesamiento por lotes o envío de informes en línea? ¿El intervalo de tiempo es diario, semanal, mensual, trimestral o anual? Considere también la posibilidad de crear tablas de resumen si es necesario. Las claves primarias generadas por el sistema son difíciles de gestionar en los informes. Las búsquedas de usuarios utilizando claves secundarias en tablas con claves primarias generadas por el sistema a menudo arrojan muchos datos duplicados. Este rendimiento de recuperación es relativamente bajo y puede causar confusión fácilmente.

Comprender las necesidades del cliente

Esto puede parecer obvio, pero las necesidades provienen de los clientes (piense aquí tanto en los clientes internos como en los externos). No confíe en las necesidades escritas de los usuarios. Las necesidades reales están en la cabeza de los clientes. Le pide al cliente que le explique sus necesidades y, a medida que continúa el desarrollo, le pide con frecuencia que se asegure de que sus necesidades todavía estén dentro del propósito del desarrollo. Una verdad inmutable es: "No sé lo que quiero hasta que lo veo" inevitablemente conducirá a muchos retrabajos porque la base de datos no cumple con los requisitos que el cliente nunca ha escrito. Y lo que es peor es que tu interpretación de sus necesidades es la tuya y puede estar completamente equivocada.

Las 4 partes restantes continuarán...

Experiencia en diseño de bases de datos (2)

[Prólogo]: Un sistema de gestión exitoso se compone de: [[50% negocio + 50% software], y el 50% del software exitoso se compone de [25% base de datos + 25% programa]. La calidad del diseño de la base de datos es clave. Si se comparan los datos de una empresa con la sangre necesaria para la vida, entonces el diseño de la base de datos es la parte más importante de la aplicación. Existe una gran cantidad de material sobre diseño de bases de datos, e incluso se trata en cursos universitarios. Sin embargo, como hemos enfatizado repetidamente, no importa cuán bueno sea un maestro, nada puede compararse con las enseñanzas de la experiencia. Así que resumí los desvíos y experiencias que he tomado a lo largo de los años y encontré algunos profesionales con conocimientos en diseño de bases de datos en Internet para enseñarle algunas habilidades y experiencias en diseño de bases de datos. Se han seleccionado y compilado 60 de los mejores consejos en este artículo para facilitar la indexación, el contenido se divide en 5 partes:

La parte anterior presentó 12 consejos básicos antes de diseñar una base de datos, incluidos estándares de nomenclatura y claridad. requisitos comerciales (Charla sobre experiencia en diseño de bases de datos [1]). La segunda parte de este artículo presenta 24 técnicas guía para diseñar tablas de bases de datos, que cubren el diseño de campos en tablas y los problemas comunes que deben evitarse.

Parte 2: Diseño de tablas y campos

Comprobación de cambios

Cuando diseño una base de datos, considero qué campos de datos pueden cambiar en el futuro. Por ejemplo, este es el caso de los apellidos (tenga en cuenta que son apellidos occidentales, como las mujeres que toman el apellido de su marido después del matrimonio, etc.). Por lo tanto, cuando configuro un sistema para almacenar información del cliente, tiendo a almacenar el campo de apellido en una tabla de datos separada y también adjunto campos como la fecha de inicio y la fecha de finalización, para que se puedan rastrear los cambios en esta entrada de datos.

Utilice nombres de campos significativos

Una vez participé en el desarrollo de un proyecto que incluía un programa heredado de otro programador. Al programador le gustaba mostrar instrucciones de datos en la pantalla. Los campos que usan palabras no son una mala idea, pero desafortunadamente, a ella también le gusta usar algunos métodos de nombres extraños. Los nombres son una combinación de nombres húngaros y números de serie de control, como cbo1, txt2, txt2_b, etc.

A menos que esté utilizando un sistema que solo abrevie los nombres de los campos, describa los campos lo más claramente posible. Por supuesto, no exagere, como Customer_Shipping_Address_Street_Line_1, aunque es muy descriptivo, pero nadie quiere escribir un nombre tan largo, el tamaño específico está a su alcance.

Usar nombres de prefijo

Si hay muchos campos del mismo tipo (como Nombre) en varias tablas, es posible que desee utilizar el prefijo de una tabla específica (como CusLastName ) para ayudarle a identificar los campos.

Los datos de puntualidad deben incluir un campo "Última fecha/hora de actualización". Las marcas de tiempo son particularmente útiles para encontrar la causa de problemas de datos, reprocesar/recargar datos por fecha y eliminar datos antiguos.

Estandarización y basada en datos

La estandarización de datos no sólo te facilita a ti mismo sino que también facilita a otros. Por ejemplo, si su interfaz de usuario necesita acceder a fuentes de datos externas (archivos, documentos XML, otras bases de datos, etc.), es posible que desee almacenar la información de conexión y ruta correspondiente en la tabla de soporte de la interfaz de usuario. Además, si la interfaz de usuario realiza tareas como el flujo de trabajo (enviar correos electrónicos, imprimir membretes, modificar el estado del registro, etc.), los datos que generan el flujo de trabajo también se pueden almacenar en la base de datos. La programación previa siempre requiere esfuerzo, pero los cambios de políticas y el mantenimiento son mucho más fáciles si estos procesos se basan en datos en lugar de estar codificados. De hecho, si el proceso se basa en datos, puede asignar a los usuarios una responsabilidad considerable para mantener sus propios procesos de flujo de trabajo.

La estandarización no se puede exagerar

Para aquellos que no están familiarizados con el término normalización, la estandarización puede garantizar que los campos de la tabla tengan los elementos más básicos y esta medida ayuda a eliminar datos. redundancia en la base de datos. Existen varias formas de normalización, pero generalmente se considera que la tercera forma normal (3NF) tiene el mejor equilibrio entre rendimiento, escalabilidad e integridad de los datos. En pocas palabras, 3NF estipula:

* Cada valor en la tabla solo se puede expresar una vez.

* Cada fila de la tabla debe estar identificada de forma única (tener una clave única).

* La información que no es clave y que depende de otras claves no debe almacenarse en la tabla.

Una base de datos que cumple con el estándar 3NF tiene las siguientes características: un conjunto de tablas dedicadas a almacenar datos relacionados conectados por claves. Por ejemplo, una base de datos 3NF que almacena clientes y sus pedidos relacionados podría tener dos tablas: Cliente y Pedido. La tabla Pedido no contiene ninguna información sobre el cliente asociado con el pedido, pero se almacena un valor clave en la tabla que apunta a la fila de la tabla Cliente que contiene la información del cliente.

También existen niveles más altos de estandarización, pero ¿más estándar significa necesariamente mejor? La respuesta no es necesariamente. De hecho, incluso 3NF puede introducir demasiada complejidad en la base de datos para algunos proyectos.

En aras de la eficiencia, a veces es necesario estandarizar las tablas. Hay muchos ejemplos de este tipo. Una vez trabajé desarrollando software de análisis de restaurantes y usé tablas no estandarizadas para reducir el tiempo de consulta de un promedio de 40 segundos a aproximadamente dos segundos. Aunque tengo que hacerlo, nunca tomo la no estandarización de las tablas de datos como una filosofía de diseño determinada. La operación específica es solo una derivación. Entonces, si hay un problema con la tabla, es completamente posible regenerar la tabla no estandarizada.

Consejos para la generación de informes de Microsoft Visual FoxPro

Si está utilizando Microsoft Visual FoxPro, puede reemplazar los nombres numerados con nombres de campo fáciles de usar: como Nombre del cliente en lugar de txtCNaM. De esta manera, cuando cree formularios e informes utilizando asistentes [asistentes, conocidos como 'elfos' en Taiwán), los nombres facilitarán su lectura a las personas que no son programadores.

Indicador de inactivo o inactivo

Es útil agregar un campo para indicar si el registro ya no está activo en el negocio.

Ya sea un cliente, un empleado u otra persona, esto ayudará a filtrar el estado activo o inactivo al ejecutar consultas. También elimina algunos de los problemas que enfrentan los nuevos usuarios al adoptar datos. Por ejemplo, es posible que ciertos registros ya no estén disponibles para ellos y pueden usarse como medida de precaución al eliminarlos.

Usa entidades de rol para definir columnas [campos] que pertenecen a una determinada categoría

Cuando necesites definir cosas que pertenecen a una categoría específica o que tienen un rol específico, puedes usar rol entidades para crear relaciones específicas relacionadas con el tiempo, permitiendo así la autodocumentación.

El significado aquí no es permitir que la entidad PERSONA tenga un campo Título, sino decir, ¿por qué no usar la entidad PERSONA y la entidad PERSON_TYPE para describir a la persona? Por ejemplo, cuando John Smith, ingeniero, es ascendido a John Smith, director y, finalmente, al alto puesto de John Smith, CIO, todo lo que tiene que hacer es cambiar el valor clave de la relación entre las dos tablas PERSON y PERSON_TYPE, y al mismo tiempo agregue un campo Fecha/hora para saber cuándo ocurrió el cambio. De esta manera, su tabla PERSON_TYPE contiene todos los tipos posibles de PERSONA, como Asociado, Ingeniero, Director, CIO o CEO, etc.

Una alternativa sería cambiar el registro PERSONA para reflejar el nuevo título, pero esto haría imposible rastrear la hora exacta de la ubicación del individuo.

Usa datos comunes de autoridad de denominación de entidades

La forma más sencilla de organizar tus datos es utilizar nombres comunes, como: PERSONA, ORGANIZACIÓN, DIRECCIÓN, TELÉFONO, etc. Cuando combina estos nombres generales de uso común o crea subentidades correspondientes específicas, obtiene su propia versión especial. La razón principal para comenzar con términos generales es que todos los usuarios concretos pueden concretar cosas abstractas.

Con estas representaciones abstractas, puede utilizar sus propios nombres especiales en identificadores de nivel 2. Por ejemplo, PERSONA puede ser Empleado, Cónyuge, Paciente, Cliente, Proveedor o Profesor, etc. Asimismo, ORGANIZACIÓN también puede ser Mi Empresa, Mi Departamento, Competidor, Hospital, Almacén, Gobierno, etc. Finalmente, DIRECCIÓN puede ser específicamente Sitio, Ubicación, Hogar, Trabajo, Cliente, Proveedor, Corporación, Oficina de campo, etc.

El uso de términos abstractos generales para identificar categorías de "cosas" le brinda una tremenda flexibilidad a la hora de relacionar datos para cumplir con los requisitos comerciales, al tiempo que al hacerlo también puede reducir significativamente la cantidad de redundancia necesaria para el almacenamiento de datos.

Los usuarios provienen de todo el mundo

Al diseñar una base de datos para usar en Internet o con otras características internacionales, asegúrese de recordar que la mayoría de los países tienen diferentes formatos de campo, como códigos postales, etc., algunos países, como Nueva Zelanda, no tienen códigos postales.

La duplicación de datos requiere tablas de datos separadas

Si se encuentra ingresando datos repetidamente, cree nuevas tablas y nuevas relaciones.

3 campos útiles que deben agregarse a cada tabla

* dRecordCreationDate, el valor predeterminado es Now() en VB y el predeterminado es GETDATE() en SQL Server

* sRecordCreator, el valor predeterminado NO ES USUARIO PREDETERMINADO NULL en SQL Server

* nRecordVersion, la marca de versión del registro ayuda a explicar con precisión los motivos de los datos nulos o los datos perdidos en el registro

Utilice varios campos para la dirección y el número de teléfono

Una sola línea que describa la dirección postal no es suficiente. Address_Line1, Address_Line2 y Address_Line3 proporcionan mayor flexibilidad. Además, es mejor tener números de teléfono y direcciones de correo electrónico en sus propias tablas de datos, con sus propios tipos y categorías de etiquetas.

Tenga cuidado con la estandarización excesiva, ya que esto puede causar problemas de rendimiento. Aunque la separación de las tablas de direcciones y teléfonos suele ser óptima, si es necesario acceder a este tipo de información con frecuencia, puede ser mejor almacenar la información "preferida" (como Cliente, etc.) en su tabla principal. El compromiso entre desestandarización y acceso acelerado tiene sentido.

Usar múltiples campos de nombre

Me sorprende que muchas personas simplemente dejen un campo en la base de datos para el nombre. Pensé que sólo los nuevos desarrolladores harían esto, pero de hecho esta práctica es muy común en línea. Sugiero que el apellido y el nombre se traten como dos campos y luego se combinen al realizar la consulta.

Lo que más uso comúnmente es crear una columna [campo] calculada en la misma tabla, a través de la cual se pueden conectar automáticamente los campos estandarizados, de modo que cambie cuando cambien los datos. Sin embargo, para hacerlo es necesario ser inteligente a la hora de utilizar software de modelado. En resumen, el uso de campos de conexión puede aislar eficazmente las aplicaciones de usuario y las interfaces de desarrollador.

Cuidado con los nombres de objetos con mayúsculas y minúsculas y los caracteres especiales.

Una de las cosas que más me molestaba en el pasado era tener nombres de objetos con mayúsculas y minúsculas en las bases de datos, como CustomerData. Este problema existe desde el acceso a las bases de datos Oracle. No me gusta el enfoque de mayúsculas y minúsculas para nombrar objetos, lo que resulta en tener que cambiar los nombres manualmente. Piénselo, ¿podrá este tipo de base de datos/aplicación sobrevivir el día en que se adopten bases de datos más potentes? Los nombres que están todos en mayúsculas e incluyen guiones bajos son más legibles (CUSTOMER_DATA). Nunca deje espacios entre caracteres en los nombres de los objetos.

Tenga cuidado con las palabras reservadas

Asegúrese de que los nombres de sus campos no entren en conflicto con palabras reservadas, sistemas de bases de datos o métodos de acceso comunes. Por ejemplo, hay una tabla en una conexión ODBC. programa que escribí recientemente, DESC se utiliza como nombre del campo de descripción. ¡Las consecuencias se pueden imaginar! DESC es la palabra reservada después de la abreviatura de DESCENDENTE. Una instrucción SELECT * en la tabla funciona, pero todo lo que obtengo es un montón de información inútil.

Mantenga la coherencia en los nombres y tipos de campos

Asegúrese de garantizar la coherencia al nombrar los campos y asignarles tipos de datos. Si un campo se llama "número_acuerdo" en una tabla, no cambie el nombre a "ref1" en otra tabla. Si el tipo de datos es un número entero en una tabla, no lo cambie a carácter en otra tabla. Recuerde, una vez que haya terminado su trabajo, otros aún necesitarán usar su base de datos.

Elija los tipos de números con cuidado

Tenga especial cuidado al utilizar los tipos smallint y tinyint en SQL. Por ejemplo, si desea ver el total de ventas mensuales y su tipo de campo total es smallint. entonces, si el total excede $32,767 no podrá realizar cálculos.

Eliminar indicador

Incluya un campo "Eliminar indicador" en la tabla para que las filas se puedan marcar para su eliminación.

No elimine filas individuales en una base de datos relacional; es mejor utilizar procedimientos de depuración de datos y mantener cuidadosamente la integridad del índice.

Evite el uso de activadores

La funcionalidad de un activador a menudo se puede lograr de otras maneras. Los desencadenantes pueden convertirse en una distracción al depurar un programa. Si necesita utilizar desencadenantes, será mejor que se concentre en documentarlos.

Incluir mecanismo de control de versiones

Se recomienda introducir un mecanismo de control de versiones en la base de datos para determinar la versión de la base de datos en uso. Tienes que cumplir este requisito pase lo que pase. Con el tiempo, las necesidades de los usuarios siempre cambiarán. En última instancia, esto puede requerir modificaciones en la estructura de la base de datos. Aunque puede determinar la versión de la estructura de una base de datos verificando nuevos campos o índices, ¿no me resulta más conveniente almacenar la información de la versión directamente en la base de datos?

Deje suficiente margen para los campos de texto

Los campos de texto de tipo ID, como ID de cliente o número de pedido, etc., deben ser más grandes de lo que generalmente se imagina, porque no lleva mucho tiempo. para usted Probablemente se sentirá avergonzado al agregar caracteres adicionales. Por ejemplo, digamos que su ID de cliente tiene 10 dígitos. Luego, debe establecer la longitud del campo de la tabla de la base de datos en 12 o 13 caracteres. ¿Es esto una pérdida de espacio? Sí, un poquito, pero no tanto como crees: alargar un campo 3 caracteres sólo hace que toda la base de datos ocupe 3MB más de espacio cuando hay 1 millón de registros y un pequeño índice. Pero este espacio adicional permitirá que la base de datos crezca en tamaño sin tener que reconstruir toda la base de datos en el futuro. El mejor y más trágico ejemplo es el cambio del número de documento de identidad de 15 a 18 dígitos.

Consejos para nombrar columnas [campos]

Descubrimos que si se utiliza un prefijo unificado para los nombres de las columnas [campos] de cada tabla, se simplifica enormemente la escritura de expresiones SQL. Esto tiene desventajas, como destruir la función de las herramientas de conexión automática de tablas, que vinculan los nombres de las columnas [campos] públicas con ciertas bases de datos, pero incluso estas herramientas a veces se conectan incorrectamente. Como ejemplo sencillo, supongamos que hay dos tablas:

Cliente y Pedido. El prefijo de la tabla Cliente es cu_, por lo que los nombres de las subsecciones en la tabla son los siguientes: cu_name_id, cu_surname, cu_initials, cu_address, etc. El prefijo de la tabla Pedido es or_, por lo que los nombres de las subsecciones son: or_order_id, or_cust_name_id, or_quantity, or_description, etc.

La instrucción SQL para seleccionar todos los datos de la base de datos se puede escribir de la siguiente manera:

Seleccione * Del Cliente, Pedido Donde cu_apellido = "MINOMBRE" ;

y cu_name_id = or_cust_name_id y or_quantity = 1

Sin estos prefijos, se escribirá así (use alias para distinguir):

Seleccione * Del cliente, Pedido donde Apellido del cliente =. "MYNAME" ;

and Customer.name_id = Order.cust_name_id and Order.quantity = 1

La primera declaración SQL no perdió muchos caracteres. Pero si la consulta involucra 5 tablas o incluso más columnas [campos], sabrás lo útil que es esta técnica.

Vista previa: Parte 3 - Seleccionar claves

¿Cómo seleccionar claves? Aquí hay 10 consejos que cubren específicamente el uso correcto de las claves primarias generadas por el sistema, cuándo y cómo indexar campos para un rendimiento óptimo y más.

Experiencia en diseño de bases de datos (3) Fuente: Foro de bases de datos

[ 2005-07-26 09:56:21 ] Autor: Tuberose Editor: moningfeng ¡Disfrute de audio y video Divx6 Revisión completa! , navegación y descarga, observación del software de experiencia Opera BT: ¡No dejes que el software fraudulento te engañe! ¡Presta atención! Se filtraron varias imágenes de Longhorn 5203. ¿Serás ese "podcaster" genial? Mi historia de amor con Super Rabbit Divx Converter maravillosas imágenes. buen ayudante para la conversión de formato, una carta del vicepresidente de Microsoft a los estudiantes universitarios chinos: aprendizaje de Java desde principiante hasta competente (con preguntas frecuentes) PS 3D Light and Shadow Magic: haz un agujero en el cristal Photoshop 3D Magic 2: el secreto de Luz y sombra, la forma de disfrutar de audio y video. Exploración de revisión completa de Divx6 Descarga única, observación del software de experiencia Opera BT: ¡No dejes que el software fraudulento te engañe! ¡Presta atención a las múltiples imágenes filtradas! ¿"podcast"? Mi historia de amor con Super Rabbit Divx Converter maravillosa conversión de formato de imagen de prueba Una carta del vicepresidente de Microsoft a los estudiantes universitarios chinos: aprendizaje de Java desde principiante hasta competente (con preguntas frecuentes) PS 3D Light and Shadow Magic: Make un agujero en el cristal Photoshop 3D Magic 2: El misterio de la luz y la sombra

[Prólogo]: Un sistema de gestión exitoso se compone de: [50% negocio + 50% software] y 50% de éxito El software se compone de [25% base de datos + 25% programa]. La calidad del diseño de la base de datos es clave. Si se comparan los datos de una empresa con la sangre necesaria para la vida, entonces el diseño de la base de datos es la parte más importante de la aplicación. Existe una gran cantidad de material sobre diseño de bases de datos, e incluso se trata en cursos universitarios. Sin embargo, como hemos enfatizado repetidamente, no importa cuán bueno sea un maestro, nada puede compararse con las enseñanzas de la experiencia. Así que resumí los desvíos y experiencias que he tomado a lo largo de los años y encontré algunos profesionales con conocimientos en diseño de bases de datos en Internet para enseñarle algunas habilidades y experiencias en diseño de bases de datos. Se han seleccionado y compilado 60 de las mejores técnicas en este artículo para facilitar la indexación, el contenido se divide en 5 partes:

La primera parte presenta 12 técnicas básicas antes de diseñar una base de datos, incluidos estándares de nomenclatura y claridad. requisitos comerciales (charla de experiencia en diseño de bases de datos (1)); la segunda parte presenta 24 habilidades guía para diseñar tablas de bases de datos, que cubren el diseño de campos en la tabla y los problemas comunes que deben evitarse (charla de experiencia en diseño de bases de datos (2)); Parte de este artículo presenta principalmente claves de selección e índices, incluidos 10 consejos específicamente relacionados con el uso correcto de las claves primarias generadas por el sistema, así como cuándo y cómo indexar campos para un rendimiento óptimo.

Parte 3: índices y claves de selección

La extracción de datos debe planificarse con antelación

Uno de los departamentos de mis clientes estaba procesando más de 80.000 contactos a la vez , mientras completa los datos necesarios para cada cliente (esto definitivamente no es un trabajo fácil). También necesito identificar un grupo de clientes como objetivos de mercado. Cuando diseñé las tablas y los campos desde el principio, intenté no agregar demasiados campos al índice principal para acelerar la base de datos. Luego me di cuenta de que las consultas y la extracción de información específicas de un grupo no eran ni precisas ni rápidas. Como resultado, los campos de datos tuvieron que reconstruirse y fusionarse en el índice principal. Considero fundamental tener un esquema de índice: ¿por qué debería utilizar el número como campo de índice principal cuando quiero crear una búsqueda de tipo de sistema? Puedo recuperarlo por número de fax, pero para mí es casi tan poco importante como el tipo de sistema. Al utilizar este último como campo principal, la reindexación y recuperación después de actualizar la base de datos es mucho más rápida.

Existen diferencias en la indexación de datos en los dos entornos de almacén de datos operativo (ODS) y almacén de datos (DW). En un entorno DW, desea considerar cómo el departamento de ventas organiza las actividades de ventas. No son administradores de bases de datos, pero determinan la información clave dentro de las tablas. Aquí el diseñador o el personal de la base de datos deben analizar la estructura de la base de datos para determinar las mejores condiciones entre el rendimiento y la salida correcta.

Utilice claves primarias generadas por el sistema

Esto es lo mismo que el Consejo 1, pero creo que es necesario recordárselo a todos nuevamente aquí. Si siempre utiliza claves generadas por el sistema como claves principales al diseñar su base de datos, entonces realmente controla la integridad del índice de la base de datos. De esta manera, la base de datos y los mecanismos no humanos controlan eficazmente el acceso a cada fila de los datos almacenados.

Existe otra ventaja de utilizar claves generadas por el sistema como claves principales: es fácil encontrar fallas lógicas cuando se tiene una estructura de claves consistente.

Descomponer campos para indexar

Para separar los campos con nombre y los campos incluidos para admitir informes definidos por el usuario, considere descomponer otros campos (incluso las claves principales) en sus partes componentes para que los usuarios puedan indexar. él. Los índices acelerarán la ejecución de los scripts SQL y Report Builder. Por ejemplo, normalmente creo informes en situaciones en las que tengo que usar expresiones LIKE de SQL porque el campo del número de caso no se puede dividir en elementos como año, número de serie, tipo de caso y código del demandado. El rendimiento también se deteriorará. Si