La actualizacion seria si llegara el caso, de una sola tabla por
usuario(medicos), y no sería siemmpre, como comente en un msg de hace
tiempo, entre actualizacion y actualizacion puede o bien ser todos a la
cez(cso poco probable) o, uno ahora, otro dentro de un par de minutos, y
así, pero prefiero ponerme en el peor de los casos
> 2009/7/21 Espartano <espartano(dot)mail(at)gmail(dot)com>:
>
>> 2009/7/21 Mariano Reingart <reingart(at)gmail(dot)com>:
>>
>>> 2009/7/21 suso <jlcubas(at)terra(dot)es>:
>>>
>>>> Hola Edwin, que tal!
>>>> Gracias por la respuesta
>>>> Estos datos que me proporcionas es muy facil de conseguir, pero no habrá
>>>> problemas para 20 usuarios concurrentes "tirando" a la vez?
>>>> Tengo unas dudillas más:
>>>> Discos de respaldo, internos, externos, en paralelo, caché de la cpu?
>>>>
>>>>> Cor 2 Duo
>>>>> 4Gb Ram
>>>>> Disco Sata de 160 GB(depende de la cantidad de datos que hay)
>>>>> Ya!!
>>>>> Ah! Y Debian Lenny
>>>>>
>>>>>
>>> Una pregunta, que tipo de bases de datos necesitas armar:
>>> * muchas consultas complejas
>>> * alta tasa de actualización (insert, updates y deletes)
>>> * muchas conexiones concurrentes (actualizando o consultando)
>>> * tamaños de las tablas, cantidad de registros, indices, etc.
>>>
>>> Yo si el presupuesto lo permite, me inclinaría por más
>>> nucleos/procesadores y discos:
>>>
>> Si bien las velocidades de los procesadores son importantes, en este
>> caso creo que tiene mayor importancia la cantidad de memoria RAM, yo
>> apostaria mas por este orden de prioridades
>>
>> Memoria RAM
>> Discos rapidos
>> CPU
>>
>>
>
> Depende, si los 20 usuarios actualizan a la vez gran cantidad de
> registros por segundo/minuto, me parece más importante la velocidad de
> los discos.
> Tampoco la base de datos parece tan grande como para que 4GB sea poco.
> Por último, yo creo que siempre es más fácil agregar memoria, que
> cambiar los discos o los cpu.
>
> Sds
> Mariano
>
>