Cita:
|
Empezado por Mick
Efectivamente una caida de un equipo incluso en monopuesto, puede corromper las tablas o indices, exactamente de la misma forma que si el servidor se cae en firebird/interbase/etc tambien se pueden corromper las tablas.
|
Una diferencia importante, y creo que vale la pena aclararla, es que hay menos posibilidades que ante una caida (digamos por falta de corriente) se corrompan las tablas de un servidor oracle o firebird, que la que habría ante la misma caida de un monopuesto con paradox. De esto, también google creo que puede dar buenas referencias, que alguna estadística debe haber por alli. A mi me lo dice el sentido común, puesto que estos servidores implementan métodos de recuperación de fallos. Firebird, por ejemplo, la mayoría de las veces, simplemente volvería a su último estado consistente antes del fallo eléctrico.
N discuto que hay casos en los que se corrompería inevitablemente, pero realmente estos mecanismos de recuperación ayudan mucho a evitarlo. No conozco a profundidad paradox, pero ¿tiene algo similar?
En el caso ya mencionado de Oracle... he dedicado buena parte de mis esfuerzos en lectura de los últimos meses a documentarme sobre los mecanismos de que dispone Oracle para recuperarse de fallos. Uf... es sorprendente la tecnología que han desarrollado en torno a esto. Es posible incluso de fallos físicos en los discos. Obviamente hay un procedimiento a seguir, y tiene un costo en hardware y software... pero existe para quien necesite estar protegido contra todo.
Cita:
|
Empezado por Mick
La diferencia y ventaja de un sistema cliente servidor, es que solo el mal funcionamiento del servidor puede corromper las tablas, ya que es el unico que accede directamente a la base de datos.
|
Gran ventaja, ¿no?
Cita:
|
Empezado por Mick
el riesgo de mal funcionamiento de unos pocos equipos es pequeño.
|
Eso depende de las características/edad de los componentes de hardware, del ambiente y de muchas otras cosas. He visto sistemas monopuesto, que yo catalogaría de alto riesgo..
Cita:
|
Empezado por Mick
un sistema cliente servidor no hace milagros para que las tablas no se estropeen
|
Nadie ha dicho que haga milagros... pero ¿te he contado de oracle?
Cita:
|
Empezado por Mick
gestiona igualmente registros e indices como cualquier sistema de tablas planas, la diferencia es que solo un equipo (el servidor) hace las inserciones/modificaciones/borrados.
|
Yo diría que si, pero que incluso en la gestión puede ser mucho mas óptimo. En tablas planas, el único caso excepcional que conozco, y que ya he mencionado antes, es btrieve.
Cita:
|
Empezado por Mick
Puedes buscar en google por corrupcion de datos veras que en todos los sistemas de base de datos existe ese problema.
|
Un punto inevitable. Habrá que sacar un indicador que nos arroje luz sobre un "coeficiente de corrupción" que involucre variables tales como Número de corrupciones, Número de instalaciones, Número de usuarios concurrentes, etc.
Cita:
|
Empezado por Mick
En general un sistema monopuesto de tablas planas tiene las mismas posibilidades de que se estropeen las tablas que un sistema cliente servidor con un solo cliente.
|
Este punto es MUY discutible, yo no lo creo.
Cita:
|
Empezado por Mick
las inserciones y modificaciones no tienen mayor problema en cualquier sistema de base de datos
|
.
Depende del "tipo" de sistema de bases de datos. Conozco algunos donde hay miles de operadores grabando registros, donde esos "irrisorios" milisegundos se pueden convertir en un verdadero cuello de botella. También conozco sistemas de bases de datos que no dependen de un operador "humano", sino que están registrando información generada por otras máquinas, y que puede ir a ritmos verdaderamente vertiginosos. Por algo los señores de la computación se han inventado términos como OLTP, OLAP y similares.
Cita:
|
Empezado por Mick
normalmente una tarjeta de red media (de 100Mb puede transmitir datos a 5 o 6 Megabytes/segundo) eso es velocidad totalmente sobrada, para hacer cientos o miles de inserciones por segundo.
|
Estas suponiendo, erroneamente creo, que el cuello de botella es la red. Habrán casos en que efectivamente lo es, y habrán otros en que la red tiene poco que ver.
Cita:
|
Empezado por Mick
hay determinadas procesos que se pueden hacer mas rapido usando tablas planas, y otros que se realizan mas rapido en sistemas cliente/servidor.
|
En el caso específico de un usuario... con un sistema bien diseñado, creo que siempre irá mas rápido las tablas planas. El punto de discusión, según entiendo, no es solo la velocidad.
Cita:
|
Empezado por Mick
hay cosas que precisamente no se pueden hacer sin perder rendimiento en sistemas cliente/servidor por el hecho de no poder acceder directamente a los registros.
|
Lo cual puede ser una gran ventaja... según de donde se vea. Desde el punto de vista de la seguridad, por ejemplo... es mucho mejor que no se pueda acceder directamente a los registros. Te ofrece una mayor garantía que solamente aquellos usuarios con las credenciales adecuadas podrán acceder a ellos, ya sea para verlos o para modificarlos.
Cita:
|
Empezado por Mick
La cuestion esta en usar la herramienta mas adecuada para cada proyecto o situacion, no se puede decir que un sistema de bases de datos determinado (sea paradox, o interbase o el que sea) es el mejor para todos los casos.
|
En este punto estamos totalmente de acuerdo... aunque creo que es de sobra evidente que en la mayoría de los casos es preferible un sistema C/S. Incluso para pequeñas tiendas o negocios, de cara al futuro, es mejor contar desde el inicio con un sistema que les permita escalar de acuerdo a su crecimiento. En el caso de firebird, el costo es mínimo desde el inicio, por lo que no veo muchas ventajas en no elegirlo (en muchos casos).
Cita:
|
Empezado por Mick
Otra cosa muy importante es saber los requerimientos, carencias, puntos fuertes, y configuraciones necesarias de cada sistema antes de empezar a utilizarlo.
|
Definitivo. Cualquier programador que no cumpla esto, es un verdadero irresponsable.
Hasta luego.
