FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#1
|
|||
|
|||
Necesito de ustedes paraun concejo
Hola foro, ya se que este hilo no se especializa en dar concejos, disculpemen, pero necesito de ustedes, resulta que realice una aplicacion en D3 usando paradox v.7.0, la aplicacion funciona bien pero mi primera pregunta es. Es apto este motor de BD para tantos registros que esta BD va a tener (mas de 1.500.000 reg.)?, ahora mi segunda duda, esta BD le interesan a varias personas que logicamente estan conectadas a Internet, D3 me permite programar tanto la conexion para visualizar la BD en las estaciones, ademas de alguna interfaz (Hoja) en internet para que se pueda manipular dicha BD?, si no es D3 cual otro lenjuage? espero haberme dado a entender y gracias por sus comentarios que meserviran de mucho para poder tomar una decision acertada.
Chaoooooooooooooooooooo
__________________
Siempre hay un primer momento para todo. |
#2
|
||||
|
||||
Te recomiendo pasar de Paradox, y basarte en algo mas estable/robusto, como Interbase/Firebird, o mySQL.
No veo porque no hacer la paginilla en D3, siempre que tu webserver corra sobre windows, y tenga soporte para CGI/Isapi. Luego hay soluciones mas estándarizadas, como PHP, que correrá en multiples plataformas y puede hacerlo como módulo de apache. Saludos.
__________________
Juan Antonio Castillo Hernández (jachguate) Guía de Estilo | Etiqueta CODE | Búsca antes de preguntar | blog de jachguate |
#3
|
||||
|
||||
Wop!
Cita:
__________________
E pur si muove |
#4
|
||||
|
||||
Como pides un consejo, te lo doy, Leete la guía de estilo y mira en qué has fallado
__________________
:) |
#5
|
|||
|
|||
Cita:
Es mas, los sistemas navegacionales son mas rapidos realizando determinadas tareas que los sistemas cliente/servidor. Paradox es perfectamente usable si el numero de puestos no es muy grande, como lo demuestran miles de aplicaciones que existen en el mercado. En tu caso particular tienes que tener problemas de diseño, uno de ellos es el no uso de indices, cosa necesaria en cualquier sistema de base de datos sea paradox, o interbase o el que sea. Otro problema que puedes tener, es que la red en la que se este implementado el sistema no funcione correctamete: de forma demasiado lenta y perdiendo paquetes (esto es una razon que puede provocar que los archivos se estropeen: sean indices de paradox o cualquier otro archivo que se este escribiendo a traves de la red) esto es muy comun, hay montones de pequeñas empresas por ahi con sistemas y cableados que no funcionan del todo bien: es muy facil que un switch no funcione correctamente, o un driver de alguna tarjeta de red tenga bugs y haya que actualizarlo o mas facil incluso que los cables de red no esten bien hechos (te sorprenderias de la cantidad de tecnicos de redes que no saben hacer correctamente los cables). En definitiva, si el numero de puestos va a ser pequeño, es preferible utilizar un sistema de tablas planas (estilo paradox), ya que es mas facil de instalar y tiene en general menos mantenimiento que un sistema cliente servidor. Si el numero de puestos va a ser grande es preferible usar un sistema cliente/servidor. Saludos PD: Segun mi experiencia (basada en miles de instalaciones actualmente funcionando), si en un sistema implementado con tablas paradox se estropean continuamente los indices, es que existe un problema de hardware: la red o algun ordenador no funciona correctamente. |
#6
|
|||||
|
|||||
Cita:
Cita:
Cita:
Cita:
Cita:
__________________
E pur si muove |
#7
|
||||
|
||||
Creo que paradox fácilmente puede ser mas rápido que interbase firebird. También btrieve lo es (y estoy seguro que mas que paradox).
En el caso concreto de paradox, depende, como ha dicho mick, que tengas un número reducido de usuarios. Con un sistema de 4 o mas usuarios, creo que comenzarías a tener problemas por la saturación de la red (que depende también de como esten programados los clientes) y quizas, los bloqueos. Con btrieve, he visto sistemas con 50 o 60 usuarios trabajar sin problemas, y sin corromperse jamás un índice. Pero eso fué hace bastantes años... y por ahora, creo que, de cara al futuro, es mejor comenzar con una bd cliente servidor de una vez. Dependerá de los objetivos de tu sistema también, que para almacenar recetas de cocina, incluso access estaría bien. Pero 1,500,000 registros, y contando... yo me iria por una BD mas robusta y escalable. Hasta luego.
__________________
Juan Antonio Castillo Hernández (jachguate) Guía de Estilo | Etiqueta CODE | Búsca antes de preguntar | blog de jachguate |
#8
|
||||
|
||||
Cita:
Y en el tema de mantenimiento prefiero ni entrar
__________________
E pur si muove |
#9
|
|||
|
|||
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.
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. En un sistema de tablas planas como todos los equipos acceden directamente a los datos el mal funcionamiento de cualquiera de los equipos puede estropear los datos. Por eso con pocos equipos no tiene mayor problema ya que el riesgo de mal funcionamiento de unos pocos equipos es pequeño. Otra cosa es que tengamos decenas o cientos de clientes, en ese caso es facil que algun equipo siempre este funcionando mal o averiado, con lo que el mantenimiento se vuelve imposible. Pero en general eso es la unica diferencia fundamental, un sistema cliente servidor no hace milagros para que las tablas no se estropeen, 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. Puedes buscar en google por corrupcion de datos veras que en todos los sistemas de base de datos existe ese problema. 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. Contrariamente a los que dices, precisamente las inserciones y modificaciones no tienen mayor problema en cualquier sistema de base de datos, salvo procesos especificos, el alta de datos es realizado por operadores que tienen que teclear la informacion de modo que el tiempo en que se tarda en insertar un registro (aunque tenga muchos indicees) es irrisiorio (unos milisegundos) aunque sea a traves de la red. Si en tus sistemas eso se vuelve lento, repito, tu red no funciona bien: 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. Normalmente el punto fuerte de los programadores en general no es el hardware sino simplemente programar, he visto muchos casos de programadores volviendose locos buscando bugs en sus programas, cuando precisamente el software estaba correctamente y el problema era averias de hardware o bugs en drivers del sistema operativo. Nadie puede exigir que un software funcione si el hardware en el que se debe ejecutar no funciona bien o no esta correctamente montado. Cosas como la necesidad de un SAI es basica, cualquier sistema de base de datos se puede corromper si se va la corriente, y hay muchos programadores que cosas como esta no lo saben o no los tienen en cuenta. Ningun sistema es la panacea, hay determinadas procesos que se pueden hacer mas rapido usando tablas planas, y otros que se realizan mas rapido en sistemas cliente/servidor. Es de sobra sabido por todos que la forma de trabajar y programar en cliente/servidor es distinta que con tablas planas porque 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. 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. Otra cosa muy importante es saber los requerimientos, carencias, puntos fuertes, y configuraciones necesarias de cada sistema antes de empezar a utilizarlo. Por ejemplo es bien sabido que interbase debe estar en modo sincrono si se quierea minimizar la posible corrupcion de datos en los servidores (a costa eso si de perder velocidad). Igualmente un servidor de datos que almacene tablas planas se puede configurar de este modo para que se grabe inmediatamente la informacion al disco duro. Me pregunto cuantos de los que estan leyendo esto y usan o han usado tablas planas, han configurado los servidores para que la informacion se grabe inmediatamente (y no me refiero al uso de flushbuffers o cosas por el estilo en el programa). Me pregunto tambien cuanta gente antes de hacer una instalacion en un cliente , comprueban la velocidad de la red asi como el cableado y la distribucion de colores de los conectores de red para asegurarse de que han sido montados correctamente (esto suele estar mal en un tercio de las instalaciones). Saludos Miguel |
#10
|
|||||||||
|
|||||||||
Wop!
Cita:
Cita:
Cita:
Cita:
Cita:
Cita:
Cita:
Cita:
Cita:
__________________
E pur si muove |
#11
|
||||
|
||||
Cita:
Cita:
paradox. No se pueden sacar conclusiones generales de 1 o 2 o 3 sistemas nada mas. Cita:
Cita:
Otra cosa es que uno intente programar en sistemas de tablas planas como si fuese un sistema cliente servidor (utilizando querys para todo). Donde precisamente si se producen cuellos de botella de ese tipo, es en aplicaciones hechas con sistemas clientes servidor por programadores que estan acostumbrados a utilizar tablas planas, y no saben que hay que cambiar la forma de programar y solicitar solo subconjuntos pequeños de datos al servidor. Puedes consultar estos foros veras montones de ejemplos, de gente com problema de lentitud en interbase precisamente por que se empeñan en utilizar un grid para mostrar todos los registros de una tablas (select * from table), y se traen todos los datos hacia el cliente. O se empeñan en hacer locates sobre querys como si fuesen tablas, lo que precisamente exige el envio de todos los registros hacia el cliente. Estos programadores estan acostumbrados a que la navegacion por los registros en grids sea rapida (ir al principio y al final,etc) , precisamente porque los sistemas de tablas planas solo leen de los archivos aquellos registros que necesitan, para leer los datos del final de una tabla en un sistema de tablas planas no es necesario traer los registros anteriores, o relanzar una nueva query que solo involucre a estos ultimos registros. En definitiva la insercion y modificacion de datos es tan rapida como cualquier otro sistema. Lo que si es mas lento utilizando tablas planas es la creacion de informes complejos que involucren todos los registros de las tablas, y esto siempre y cuando no se realizen estos calculos directamente desde el servidor. Pero normalmente la velocidad en el calculo de determinados informes no es critica, porque no es una operacion que se este haciendo continuamente sobre el sistema, lo que si se hace continuamente en la mayoria de los sistemas, son determinadas consultas (que definiendo los indices adecuados en las tablas son inmediatos), inserciones y modificaciones. Saludos Miguel |
#12
|
|||||||||||||
|
|||||||||||||
Cita:
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:
Cita:
Cita:
Cita:
Cita:
Cita:
Cita:
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:
Cita:
Cita:
Cita:
Cita:
Hasta luego.
__________________
Juan Antonio Castillo Hernández (jachguate) Guía de Estilo | Etiqueta CODE | Búsca antes de preguntar | blog de jachguate |
#13
|
|||||
|
|||||
Cita:
Cita:
Cita:
Cita:
Cita:
Perdona por la ironía, pero es que ante tanto sinsentido me quedo sin argumentos... no sé por dónde empezar
__________________
E pur si muove |
#14
|
||||
|
||||
Hola,
Cita:
Otro asunto sería que tu argumentos se basaran en miles de instalaciones Paradox y miles de instalaciones pon_la_alternativa_que_quieras. Cita:
Saludos. |
#15
|
|||
|
|||
Cita:
Un archivo de incide puede estar organizado en forma de un arbol ordenado de tipo b, b* o b+, etc. Hay distintas variaciones pero lo fundamental, es que el archivo se divide en distintos bloques, digamos de 4096 bytes cada, uno. Cada bloque es un nodo del arbol. En cada nodo se guardan de forma ordenada los valores del campo o campos que formen el indice, por cada valor se guarda tambien una referencia (un puntero) al registro en la tabla principal. Los hijos de cada nodo son otros nodos en los que se guardan los valores menores y mayores de los campos con respecto a sus padres. Supongamos que tenemos un indice sobre un campo de tipo cadena, digamos campo 'nombre' de de 32 bytes. Luego, en cada nodo padre caben 4096/(32+8)= sobre 100 campos proximadamente. Cada nodo puede tener hasta 101 nodos hijos. En un arbol organizado de esta forma y que tuviese 3 niveles, cabrian aproximadamente 101*101*101 ~ mas de 1 millon de campos. Esto significia que si tenemos una tabla de 1 millon de registros y queremos localizar un registro que cumpla la condicion nombre='PEPE%', el ordenador cliente tendria que leer como MAXIMO 3 nodos en el archivo de indice para localizar el registro. Eso serian leer 4096*3= 12288 bytes a traves de la red. Considerando que con una tarjeta de red normalita puedes leer a 6.000.000 bytes por segundo, podemos concluir que el retraso ocasionado por la velocidad de la red en la busqueda en una tabla de 1 millon de registros es bastante aceptable, sobre 2 milisegundos para localizar el registro. Saludos Miguel |
#16
|
|||
|
|||
Cita:
Cita:
Saludos Miguel |
#17
|
||||
|
||||
Cita:
Y entrando en relación al tema que se trata, basar las hipotéticas ventajas de un motor de datos sobre otro en función de determinados parámetros de rendimiento en casos concretos (a pesar de ser miles), es un argumento importante, pero no definitivo. Los servidores de datos relacionales pueden hacer muchas más cosas que las que se pueden hacer con un motor basado en archivos indizados, a pesar que en determinadas circunstancias estos últimos puedan tener un rendimiento (en cuanto a velocidad de acceso) superior a los primeros. Saludos. Última edición por kinobi fecha: 11-08-2004 a las 19:48:09. |
#18
|
|||
|
|||
Cita:
Pondre otra analogia, seguramente un ferrari que corra a 300 km/h sera muy bueno en Alemania donde en las autopistas no hay limite de velocidad. Pero para ir por el medio del monte es preferible un todoterreno Cita:
Saludos Miguel |
#19
|
||||
|
||||
Cita:
En cuanto al asunto de los servidores de datos relacionales, no trataba de decir que un motor que no funcione bajo una arquitectura cliente/servidor no pueda serlo (relacional). Ahora bien, puestos a puntualizar, maticemos que un motor de datos sólo puede ser (verdaderamente) relacional si cumple las 12 de reglas de Codd y, en este caso, Paradox no las cumple en su totalidad, y por este motivo debería ser excluido de esta categoría de motores (relacionales). Saludos. |
#20
|
|||
|
|||
Cita:
En ningun momento he afirmado que paradox sea o no sea relacional. Independientemente de esto no conozco ningun sistema que cumpla fielmente todas las reglas de codd. Saludos Miguel PD: Esto se esta volviendo un dialogo para besugos XD |
|
|
|