Normalmente vuelo por el asiento de mis pantalones cuando construyo mis bases de datos. Sin embargo, mi nuevo proyecto va a necesitar bastante planificación. Nunca fui a la escuela para el desarrollo de bases de datos, así que no tengo capacitación formal sobre el proceso de planificación.Cualquier consejo sobre la planificación de una gran base de datos
¿Hay algún buen software, metodologías para planificar estas cosas?
No caiga en la trampa de intentar diseñar todo por adelantado. Simplemente no se puede hacer.A medida que avanza el proyecto, encontrará mejores formas de implementar las características que ya ha implementado. Y a medida que gana experiencia en su proyecto, también obtiene información sobre el dominio y sobre cómo diseñar mejor la base de datos.
Recomendaría tener un enfoque ágil. Diseña un poco en el momento. Y cuando veas que las cosas que creaste ya podrían haber sido diseñadas de una mejor manera, refactoriza eso. Esto va al código y al esquema de la base de datos.
Una palabra de la nota sin embargo. Donde es fácil refactorizar la lógica comercial (a menos que coloque la lógica comercial en la base de datos, que no es así, ¿verdad?) Después de abrir la aplicación, la refacturación de la base de datos después del lanzamiento es considerablemente más difícil porque debe mantener los datos. Entonces, si necesita mover un campo de una tabla a otra, necesita cambiar los scripts.
Así que cuando se acerque a un lanzamiento, podría ser una buena idea planificar un poco más adelante. Pero en las primeras fases de desarrollo, definitivamente recomendaría adoptar un enfoque ágil. Crea una tabla a la vez. Un campo a la vez.
Pensar casos de uso y código de ejemplo antes de tiempo me ha sido de gran ayuda en el diseño de la base de datos; es una buena manera de probar la integridad de la base de datos sin escribir una sola declaración SQL.
¡Buena suerte!
Sí, asegúrese de escribir algunas consultas en su contra. – Sam
Este es un lugar donde el patrón de repositorio puede ayudar mucho, utilizo ese patrón cuando tengo una buena idea de cómo quiero que funcione el software, pero cuando no tengo una idea clara de los datos involucrados. En general, es mucho más fácil crear/refactorizar los objetos simulados que modificar las tablas y los procedimientos/consultas almacenadas en la base.
Puede separar tablas en diferentes discos para acelerar el acceso (supongo que mySQL puede hacerlo). Puedes obtener discos de alta velocidad.
Tal vez te refieres a grande como en, muchas mesas. Eso es algo muy importante tema, pero se puede comenzar con éstos:
Algunos desarrolladores que vuelan por la base de sus pantalones no hacen tales cosas. Felicitaciones por pensar en el futuro.
Visio puede hacer diagramas de relaciones. También puede papel y lápiz.
Aquí hay alguna información sobre el modelado de datos Asunto: http://en.wikipedia.org/wiki/Data_modeling
palillo con el primer pocos normal forms hora de diseñar su esquema si usted no sabe lo que está haciendo. Es probable que le permita hacer cambios más fáciles que cualquier otro método cuando se da cuenta de sus errores de diseño más adelante.
En caso de duda, no dude en solicitar una opinión. El método más fácil de visualizar un diseño de base de datos es utilizar Diagramas de relaciones entre entidades (Diagramas de ER) y también nos permite ver fácilmente cómo se ve su diseño sin revisar el código.
Dibujar cosas en E-R Diagrams puede ayudar a manejar la complejidad.
Edit: Permítanme agregar que también hay reglas/pautas para ayudar a traducir diagramas E-R en el esquema relacional, y también hay herramientas para ayudar en el proceso.
Piensa en el control de versiones del esquema. ¿Cómo se manejarán los cambios en el esquema de la base de datos a lo largo del tiempo? ¿Necesita migrar o actualizar datos? ¿Puedes descartar datos durante el desarrollo?
Tenga instancias separadas de la base de datos para la prueba, la puesta en escena y en vivo desde el principio.
Dibuja muchas fotos.
Parece que ya sabría esto: pero a menudo se requieren entidades asociativas (http://en.wikipedia.org/wiki/Associative_Entities) para la cordura de DB.
Comenzaría con una convención de nomenclatura. Yo uso * _NM (por nombre) y _NUM (para los números), V_ para las vistas, etc.
nada impactante tierra, pero hace que su trabajo sea más fácil cuando se puede adivinar sus propios nombres de tabla y los nombres de las filas sin tener que buscarlos. No importa lo que elija, solo asegúrese de que sea sensato y consistente. La mayoría de los DA profesionales solo usan mayúsculas para los nombres de las tablas.
Personalmente, me gusta usar ID para ID en cada tabla que tiene una ID (que generalmente es una PK), luego para las relaciones de clave foránea como _ID para representar la relación. Por ejemplo,
Table SCHOOL tiene un PK de ID.
La Tabla ESTUDIANTE tiene una PK de ID y una FK que hace referencia a la tabla ESCUELA, ID_Claudia.
Por lo tanto, al mirar la tabla de estudiantes sin ningún ERD, es fácil ver que SCHOOL_ID hace referencia a SCHOOL.ID y se ve bien al leer la declaración de SQL, también.
Con respecto a la herramienta de modelado de datos, Erwin: http://www.ca.com/us/data-modeling.aspx
Por lo tanto, antes de ofrecer algún consejo sobre la mejor manera de diseñar un gran esquema, necesito hacer una pregunta: ¿Es un gran esquema absolutamente necesario?
Ha preguntado si hay alguna buena metodología de software para planificar sistemas grandes. De hecho, existen, y uno de los mejores enfoques para el desarrollo de software complejo es SOA: Arquitectura Orientada a Servicios. Si desea informarse un poco sobre las mejores prácticas de SOA más allá del nivel de la base de datos, le recomiendo consultar los libros de Thomas Erls, especialmente su SOA: Principios de diseño de servicios. También recomiendo escuchar algunas de las conferencias de Udi Dahan sobre diseño y arquitecturas orientadas al servicio y basadas en el dominio. Mucho conocimiento bueno de ambos tipos.
Cuando se trata de bases de datos, antes de sumergirse y desarrollar un esquema muy grande y complejo, asegúrese de que realmente lo necesite. En un entorno orientado al servicio, la motivación es identificar límites claros e irrompibles entre los distintos servicios de los problemas comerciales que intenta resolver. Una vez que haya identificado estos límites, debería encontrar que hay esquemas más pequeños que se pueden crear dentro de ellos. A veces, esto lleva a la duplicación de datos, ya que la información debe publicarse de un servicio a otro cuando necesita cruzar los límites. Pero los beneficios de tener varios esquemas más pequeños y menos complejos pueden ser enormes. Obtiene una mayor autonomía, portabilidad, flexibilidad y capacidad de mantenimiento de la que tiene con un solo esquema monstruoso.
Mire en SOA, particularmente cómo manejar bases de datos en una arquitectura orientada a servicios. La siguiente presentación realizada por Udi Dahan también debe proporcionar alguna información muy útil:
Descargar y construir su base de datos utilizando la herramienta Mesa de trabajo de MySQL. Te ayudará a construir y mantener la base de datos.
¿Qué tan grande es "grande"? – cletus
¿Grande en el disco o en un esquema grande? – Sam
Lo siento muchachos, esquema grande – simonwjackson