Cita: Tal vez no me exprese bien. Lo que me gustaría saber es si puede disminuir el rendimiento del servidor y la red o si no afecta su rendimiento y velocidad... porque si tengo una base de datos con millones de datos y miles de tablas seguramente tenga que mejorar el hardware y configuración de la red, pero como en mi caso, la base de datos es chica, entonces no tendría problemas con esto, o si?
Bueno, para saber si habrá impacto en la red, habría que estudiar cuál es el nivel de transacciones esperado, cuál el el grado de distribución de las aplicaciones, el uso de las mismas, etc. Es decir que hay que hacer un relevamiento y estimación de cómo se va a usar, en qué escenarios y cómo se modificará a futuro, en función de los planes que la empresa tenga para el negocio.
En esencia, no tiene sentido construir para administrar rascacielos, si la empresa está planeando manejar un hostal de 3 pisos... Pero si el hostal es la fase 1 de un rascacielos... las cosas cambian.
En sistemas, nadie planifica por exceso, a menos que sean planes de más de dos años de aplicación.
Cita: Cuando a vos un cliente te pide que le hagas una base de datos con X tablas para Y datos le preguntas el hardware que dispone? o esto no es necesario porque los requerimientos son mínimos? Porque estuve buscando información y solo dice "PostgreSQL (o el que sea) requiere tanta memoria ram, tanto espacio en disco y tal procesador", pero no encontré si esto también depende de lo grande que sea el proyecto a realizar...
Si un cliente te plantea "una base con X tablas para Y datos", hay dos opciones: o no sabe de qué está hablando, o no tiene ni idea de lo que necesita su negcio.
El cliente no te puede plantear que quiere una base con especificaciones concretas. Las bases se diseñan sobre la base de las necesidades del negocio, y no por lo que el cliente opine o crea.
Ni siquiera los ingenieros tienen claro lo que requiere una base de datos. Trabajé en un proyecto donde los ingenieros de desarrollo plantearon una base con 5 tablas. Luego de que analizásemos el problema, y lo que se iba a necesitar para proveer datos a los clientes, las cinco tablas se convirtieron en 67, y no exageramos ni un ápice.
Como DBA es tu obligación proveer de los datos a la aplicación, y los programadores no necesitan saber absolutamente nada de cómo está diseñada la estructura, sino que ellos deben proveer de la especificación de datos requeridos. Es uno mismo, como desarrollador de BBDD quien debe ocuparse de ver qué implica ese requerimiento, si se puede solventar con lo que se tiene, o si será mejor modificar alguna estructura para dar mejores y más óptimos resultados.
Una leccion que suelen darte en la universidad los profesores, y que he descubierto como muy cierta es que la lógica de programacion no es igual que la lógica de Bases de DAtos. Son formas completamente distintas de analizar las cosas. Ese salto a los programadores les cuesta, y mucho.
En otras palabras, que el cliente opine lo que quiere. Es TU responsabilidad hacer las cosas bien, aunque no sean exactamente como el cliente supone.
Luego se verá de explicarle al cliente (muy diplomaticamente) que lo que el tiene en mente no cumple con las necesidades de su propio negocio.