RDBMS utilizan un enfoque completamente diferente al almacenamiento de datos de bases de datos de objetos o de clave y valor.
El modelo relacional asume que no sabe qué datos se necesitarán en el futuro, o cómo se accederá a los datos en el futuro. Esto ha demostrado ser una suposición bastante confiable en mi experiencia.
Esa es una de las razones por las que SQL dbms le permitirá agregar índices a medida que se necesiten, y le permitirá soltar índices que han demostrado ser inútiles. Te permitirá agregar restricciones a medida que se conozcan, restricciones que a veces requieren agregar más tablas, y eliminar las restricciones a medida que cambien los requisitos. Te permitirá agregar columnas a medida que descubras más cosas que sería bueno saber. Le permitirá reemplazar tablas con vistas y reemplazar vistas con tablas. Algunos dbms le permitirán crear vistas materializadas; su impacto en la velocidad de las consultas puede ser dramático y su impacto en el uso del disco, devastador.
Las bases de datos útiles amplían su alcance. Una base de datos SQL, diseñada según el modelo relacional, hace que sea relativamente fácil agregar características que nadie soñó durante el diseño inicial, y sin aplastar otras partes del sistema. Entonces se les llama a menudo para hacer cosas que sus diseñadores iniciales no imaginaron.
Todas estas cosas
- agregar y quitar índices con el tiempo,
- agregar y quitar las limitaciones en el tiempo,
- agregar y quitar columnas con el tiempo,
- agregar y quitar tablas en el tiempo ,
hacen que cualquier estimación del uso del disco parezca una pérdida de tiempo. Cualquiera de ellos solo puede cambiar drásticamente el espacio de disco requerido para una base de datos.
Puede calcular el espacio requerido por una fila y una página con bastante precisión. (Pruebe Google para "Diseño de fila de YourDBMSname" y "Diseño de página de YourDBMSname".) Pero cuando intenta multiplicar por el número de filas requeridas, debe estimar el número de filas. Eso lo coloca al final de lo que Steve McConnell llama "el cone of uncertainty".
Si no ha medido el uso de disco en varios proyectos a lo largo del tiempo en su propia empresa, estimar el impacto de esos puntos indicados anteriormente es solo una adivinanza.
La última compañía de Fortune 100 para la que trabajé tenía una base de datos operativa que había estado en producción desde la década de 1970. Cientos de aplicaciones, escritas en más de 25 lenguajes de programación a lo largo de 40 años, llegan a ese punto todos los días. (Creo que fue construido en IMS de IBM originalmente; hoy se ejecuta en Oracle).
Incluso hace unos pocos años, nadie imaginó que su base de datos se utilizaría para traducir planos de ingeniería y listas de materiales al chino, y también para producir los documentos de aduana que necesitarían para obtener productos terminados fuera de China. La implementación de esas nuevas funciones requiere almacenar datos adicionales sobre cada parte y sobre cada documento de diseño en su inventario en vivo. Al principio de ese proyecto, nuestras estimaciones estaban bastante lejos. Ese es el gran final del cono. (Calculamos varias cosas, pero no el uso del disco. Se nos exigió que tuviéramos éxito, así que cualquiera que sea el diseño que se me ocurrió, a alguien se le requerirá que proporcione el espacio de disco necesario). Pero cuando comenzamos, sabíamos el valor exacto para cada estimar, porque ya habíamos hecho el trabajo. (Ese es el extremo angosto del cono.)
Entonces, ¿cómo mitiga el riesgo de conjeturas en un entorno de diseño e implementación de bases de datos? Tome una lección de 1972.
Cree un prototipo y mídalo.
Los ingenieros químicos aprendieron hace mucho tiempo que un proceso que funciona en el laboratorio no puede ser implementado en una fábrica en un solo paso. Se necesita un paso intermedio llamado planta piloto para proporcionar experiencia en el escalado de cantidades y en el funcionamiento en entornos no protectores . . . .
. . . Proyecto tras proyecto diseña un conjunto de algoritmos y luego se sumerge en la construcción de software entregado por el cliente en un horario que exige la entrega de lo primero que se construye. . . .
La pregunta de administración, por lo tanto, no es si construye un sistema piloto y lo descarta. Usted hará hacer eso. La única pregunta es si planificar de antemano para construir un producto descartable, o prometer entregar el desechado a los clientes.
Fred Brooks, Jr., en El mes laboral mítico, p 116.
¿Por qué quieres que para calcular la hora de diseñar un esquema .. que suena como una cosa razonable para tratar ya que el el esquema por sí solo no determinará en absoluto el tamaño de la base de datos. También se considera que el costo del espacio de almacenamiento será el factor menos importante para el costo general de, p. seleccionando la base de datos que necesita –
@ManfredMoser, un esquema de base de datos es la base de su diseño de datos de aplicación. Cómo está construido muestra cuáles son sus planes para el almacenamiento de datos. – Xeoncross
Sí ...pero MUCHOS otros factores influirán significativamente en el almacenamiento, por lo que cualquier evaluación del esquema solo sin requisitos adicionales como rendimiento (almacenamiento en caché, índices ...) o consultas (almacenamiento de datos en la parte superior de un OLTP) no tiene sentido ... perdiendo tu tiempo. –