Me gustaría saber de los programadores experimentados cuáles consideran que son las consideraciones más importantes al diseñar una nueva base de datos.¿Cuáles son las consideraciones más importantes al diseñar una base de datos?
Primero y más importante, aprenda y comprenda el dominio comercial.
1) ¿Está buscando a una alta tasa de transacción como un sitio web ocupado, o de poca como a un sistema de recursos humanos empresa pequeña
2) ¿La seguridad es un gran problema - está manejando datos personales o datos financieros . O es sólo un catálogo de productos
3) ¿Sus usuarios pueden hacer muchas actualizaciones/inserciones o se lo leen principalmente única
4) ¿Cuántos usuarios, cuáles son los patrones de uso (carga pico o uniformemente distribuida)
5) ¿necesita 24x7, 16x5 u otro tiempo de actividad, 24x7 es mucho más difícil de hacer ya que no tienen tiempo de inactividad para el mantenimiento
6) ¿Qué tan grande es el PP va a ir? Si es realmente grande que tendrá que diseñar sus tablas de tener en cuenta que y/o partición
7) ¿Es necesario mirar grupo empresarial con calor conmutación por error, o simplemente normales de alojamiento
8) Cómo se administrará la base de datos, en la mayoría de los proyectos DB se gasta el 95% del desarrollo para los usuarios y sus aplicaciones, se olvida el administrador de base de datos
9) DB Admin, incluye copias de seguridad anteriores, cambios a otros sistemas, integración a otros sistemas, carga de datos
10) Actualmente, la carga de datos y el uso de datos existentes es otro bi g problema en sí mismo.
Eso es todo para un comienzo
Fidelidad con las entidades del mundo real que la base de datos debe modelar.
+1 si no tiene eso, tendrá un desastre que nunca funcionará bien. –
Yo personalmente sugiero recoger o tomar prestado una copia de "Database Design for Mere Mortals". Todo lo que necesitaría considerar al diseñar una base de datos se enumeraría en ese libro, y es en un orden muy metódico y lógico en el que puede construir la base de datos. Las definiciones de Tabla y Columna son tediosas, pero valen la pena cada minuto que se usa al final.
Creo que es posible que pueda leer el primer capítulo si el libro se encuentra en Google Books o en la vista previa de la página en Amazon.com.
Hay algunas cositas que puede aprender a lo largo del tiempo o de este sitio como "mejores prácticas", pero no hay nada mejor que diseñarla desde cero en el primer intento.
La base de datos es secundaria a su diseño de procesos de negocio y debe apoyar limpiamente sus procesos de negocio de una manera directa y sencilla. Obtendrá mucho más beneficio de un modelo de entidad limpio y bien formado que el que obtendrá de un índice aquí y allá. Entonces, una vez que se define su proceso, lo toma y lo divide en "entidades" lo más limpiamente posible con relaciones que tengan sentido. Una vez que conoces tus entidades, traducen a tablas de bases de datos.
Una de las cosas más importantes que hacer es no sobreescribir.
Para darle una respuesta con algunos dientes, tomemos como ejemplo una entidad "vehículo". Un vehículo tiene múltiples ruedas. Usted tiene una decisión crítica para hacer saber que habrá múltiples ruedas unidas al vehículo. Tiene 2 opciones para hacer: puede hacer que "ruedas" sea una entidad separada, o puede hacer que "número de ruedas" sea un campo entero en la entidad "Vehículo".
Si usted sabe absolutamente que necesitará almacenar mucha información variable sobre cada rueda, luego cree una entidad "Rueda". Ahora tiene una relación entre entidades (el automóvil y la rueda).
Si no, un campo simple funcionará bien.
Pensar en estas decisiones críticas y hacer que las cosas sean lo más simples posible es, con mucho, lo más importante para mí al diseñar una base de datos. Puede hacer que la diferencia entre las cosas sea realmente fácil y realmente difícil cuando construyes la (s) siguiente (s) capa (s) de tu aplicación.
Un conjunto básico de puntos:
También debe entender para qué se utilizará la base de datos. si se trata de transacciones (OLTP), debe ser lo más normalizado posible, y el objetivo es que las transacciones se completen lo más rápido posible. si se trata de análisis y/o informes (OLAP), debe denormalizarse en muchos lugares donde realizará la agregación. las consideraciones de diseño para las bases de datos OLTP no son aplicables a las bases de datos OLAP, y viceversa.
Conozca sus datos.
quién va a construirlo y mantenerlo, dónde, cómo y con qué. ¿TIENE métodos, procedimientos y procesos para hacerlo o simplemente para promocionarlo? Ciertamente, las necesidades del negocio impulsan los datos necesarios que deberían capturarse en un ERD independiente de la implementación. Pero también debe pensar en quién mantendrá los datos a lo largo del tiempo. Además de quién es el "propietario" de los datos. ¿Quién posee las definiciones de entidades y atributos?
Los requisitos de información son la parte más importante.
Esta es otra forma de decir "determinar el propósito de su sistema", a partir de una respuesta proporcionada por CMS.
El modelado de datos conceptuales es solo una forma organizada de recopilar y presentar los requisitos de información.Cada valor almacenado y servido por la base de datos está conectado a un atributo y cada atributo a un dominio. Los atributos, a su vez, describen entidades o relaciones entre entidades. Las entidades y las relaciones de la materia constituyen la estructura conceptual del "mundo real" que describen los datos. Construir un ERD desde un modelo conceptual es fácil, aunque tedioso.
Después de eso, puede elegir un DBMS, diseñar la base de datos lógica, diseñar la base de datos física y compilar. En cada paso, las decisiones que toma son más reversibles, debido a la independencia de los datos. La independencia de los datos encapsula las decisiones de diseño dentro de la base de datos, a excepción de las consecuencias en el rendimiento. Tienes que conocer tu herramienta, por supuesto.
Tener una herramienta para administrar modelos y convertirlos en diagramas y scripts puede ser muy útil para acelerar este proceso y reducir los errores.
Pero si tiene errores serios u omisiones en sus requisitos de información, ninguna cantidad de diseño inteligente o implementación lo compensará.
1 - Consistencia
Con el tiempo su base de datos va a cambiar y otras personas tendrán que trabajar con ella. Hágase un favor a ellos mismos y asegúrese de que las estructuras estén nombradas de tal manera que cualquier persona razonable con conocimiento de dominio básico pueda anticipar el contenido de la tabla. Tómese el tiempo para escribir (podría ser una simple como bloc de notas) algunas construcciones básicas que utiliza.
Ejemplos:
clavesTanto si elegir usar guiones bajos o no (sustituir cualquier otra conversión por guiones bajos) realmente no importa al final del día ong ya que son consistentes en la forma en que los usa o no los usa.
Su base de datos es la última línea de defensa para la integridad de los datos. Haga todo su acceso a los datos a través de procedimientos almacenados y aplique la integridad de los datos mediante el uso de restricciones de verificación, claves externas, etc. Escriba los datos correctamente, no use VARCHAR (50) cuando CHAR (5) sea más específico y preciso.
Alguien más mencionó algo sobre mantenerlo simple. Por último, pero no menos importante, no construyas algo porque "piensas" que lo necesitarás el próximo mes. Las cosas cambian rápidamente y terminarás haciendo más mantenimiento en cosas que "pensaste" que ibas a usar, en lugar de cosas que estás usando si llenas tu base de datos con cosas que no sirven para nada.
Una buena base de datos se puede juzgar de la siguiente manera:
Si una base de datos está diseñado correctamente, usted debería ser capaz de entender cómo opera un negocio mirando nada más que el esquema.
En otras palabras, la base de datos es el negocio. Si la base de datos no refleja cómo se ejecuta el negocio, la base de datos es incorrecta o el negocio es incorrecto.
La base de datos es también una de las pocas cosas que realmente necesita para anticipar. Siempre puede corregir el código incorrecto, pero rara vez puede volver atrás de un cambio de esquema incorrecto. Asegúrate de hacerlo bien.
Seguridad, rendimiento, disponibilidad ... pero la integridad de datos y el modelado preciso de UoD ni siquiera hacen sus 10 cosas "más importantes" :( – sqlvogel
+1 muy útil gracias – Anthony