Club Delphi  
    FTP   CCD     Buscar   Trucos   Trabajo   Foros

Retroceder   Foros Club Delphi > Principal > Varios
Registrarse FAQ Miembros Calendario Guía de estilo Buscar Temas de Hoy Marcar Foros Como Leídos

Grupo de Teaming del ClubDelphi

Respuesta
 
Herramientas Buscar en Tema Desplegado
  #1  
Antiguo 04-02-2004
luqui luqui is offline
Registrado
 
Registrado: feb 2004
Posts: 3
Poder: 0
luqui Va por buen camino
Vengo de COBOL.

Acabo de registrarme, y ante todo debo de deciros que no tengo ni idea de
delphi, pero escribo aqui para ver si me podeis dar algo de informacion.
Llevo programando en cobol 15 años (modo texto) en linux y en dos, pero
mi profesion no es la informatica, los programas que yo hago son de autoconsumo, osea que los hago para mi propia empresa. Lo tengo todo
infomatizado en cobol y la verdad funciona a las mil maravillas, pero quiero
aprender un lenguaje visual nuevo, he probado varios coboles nuevos visuales
y funcionan muy bien pero el precio es prohibitivo hablamos de 3000 euros
para arriba minimo el compilador, pero aparte hay que pagar las runtimes para
cada puesto, osea que la fiesta sale por .... no me lo quiero ni imaginar.
Bueno mi pregunta es:
¿ El delphi es tan bueno como dicen para programas de gestion ?
¿ Puede manejar grandes cantidades de datos ?
¿ Trabajan bien y rapido en red local ?.

Os digo esto porque no tengo ni idea y me gustaria que alguien me orientara un poco sobre este tema.
Tengo 9 ordenadores en red local trabajando en cobol, un servidor linux, otro windows, ficheros comunes que tienen hasta 10 millones de registros y hay terminales en dos y en windows que acceden a estos ficheros sin ningun
estado de espera (ficheros indexados cobol), grabando y leyendo todos al
mismo tiempo etc.
¿ Que lenguaje me puede dar ese rendimiento o a su vez base de datos ?.
Como veis necesito algo que sea rapido.
Bueno me gustaria que alguien me diera su opinion, de todas maneras este
es un foro de delphi por lo tanto el delphi siempre sera el mejor, pero hay que ser etico y saber decir cuando un lenguaje es bueno para una cosa o no, lo que no me gustaria es aprender un nuevo lenguaje y luego toparme con un monton de problemas.
Gracias anticipadas por vuestra colaboracion.

Un saludo.
Responder Con Cita
  #2  
Antiguo 04-02-2004
Avatar de kinobi
kinobi kinobi is offline
Miembro
 
Registrado: may 2003
Posts: 2.621
Poder: 23
kinobi Va por buen camino
Hola y bienvenido,

Cita:
Empezado por luqui
¿ El delphi es tan bueno como dicen para programas de gestion ?
Delphi (como lenguaje) es tan bueno o tan malo "para programas de gestión" como cualquier otro lenguaje de propósito general (léase C, C++, Java, ...). No está (estrictamente) orientado a tareas de gestión (empresarial/comercial) como pueda estarlo COBOL, pero tiene un repertorio abundante de conexión con gestores de datos (bases de datos relacionales, archivos indexados, ...).

Cita:
Empezado por luqui
¿ Puede manejar grandes cantidades de datos ?
El lenguaje en sí no, pero sí a través de componentes (construidos en el propio lenguaje) y con la ayuda de gestores de datos externos, fundamentalmente (para grandes cantidades de datos) bases de datos: Oracle, MS-SQL Server, InterBase, Firebird, MySQL, DB2, fuentes ODBC, ADO, ...

Cita:
Empezado por luqui
¿ Trabajan bien y rapido en red local ?.
De nuevo, no depende del lenguaje, sino de la propia arquitectura de la red y del tipo de desarrollo: cliente/servidor, distribuido, ...

Cita:
Empezado por luqui
¿ Que lenguaje me puede dar ese rendimiento o a su vez base de datos ?. Como veis necesito algo que sea rapido.
Yo he trabajado en un proyecto de portar una aplicación construida en RM-COBOL (para Unix y DOS) a Delphi+InterBase y el resultado (para los desarrolladores COBOL) fue inicialmente decepcionante (especialmente en cuanto al asunto de la "rapidez"), básicamente por construir un sistema cliente/servidor pero emulando el sistema COBOL existente (que trabajaba bajo sesiones Telnet).

Cita:
Empezado por luqui
Bueno me gustaria que alguien me diera su opinion, de todas maneras este es un foro de delphi por lo tanto el delphi siempre sera el mejor, pero hay que ser etico y saber decir cuando un lenguaje es bueno para una cosa o no,
Pues si quieres sinceridad, yo le echaría un vistazo a los hilos del foro de "debates" que tratan sobre el futuro de Delphi.

Cita:
Empezado por luqui
lo que no me gustaria es aprender un nuevo lenguaje y luego toparme con un monton de problemas.
Pues eso, me temo, lo vas a tener con cualquier solución que elijas. Otra historia es que los problemas sean o no solucionables.

Saludos.
Responder Con Cita
  #3  
Antiguo 04-02-2004
Avatar de marto
marto marto is offline
Miembro
 
Registrado: may 2003
Ubicación: Barcelona, Catalunya
Posts: 882
Poder: 21
marto Va por buen camino
Cita:
Empezado por luqui
Acabo de registrarme
Pues vienvenido!!!!!
Cita:
Empezado por luqui
, y ante todo debo de deciros que no tengo ni idea de
delphi,
Bueno.... todos pasamos por eso

Cita:
Empezado por luqui
pero quiero
aprender un lenguaje visual nuevo
Quizá aquí esté el mayor handicap de Delphi, no es tan dificil como otros (C++) pero tampoco tan fácil como algunos (VB)

Cita:
Empezado por luqui
¿ El delphi es tan bueno como dicen para programas de gestion ?
Rotundamente SÍ. Hoy por hoy no creo que exagere si digo que, con los conocimientos necesarios, es el mejor. Motivos:

1.- Entorno RAD realmente potente
2.- Lenguaje Orientado a Objetos, con lo cual es muy escalable y evitarás repetir código a diestro y siniestro
3.- Es compilado con lo cual será tan rápido como bueno sea tu código, pero no encontrarás uno mejor (sobre Windows)
4.- La VCL. Es la librería de clases que te ofrece el entorno, encapsula perfectamente todas la funciones de Windows y te da una potencia muy alta.
5.- Además, dispones del código que forma esa VCL, de manera que puedes aprender muchísimo leyendo el código de los programadores de Borland.
6.- La comunidad de programadores: dispones de un montón de código OpenSource en la red listo para integrarse en tus aplicaciones.

Cita:
Empezado por luqui
¿ Puede manejar grandes cantidades de datos ?
Claro! pero eso no depende tanto del lenguaje que uses como de la Base de Datos. Pra la cantidad que mencionas, si lo puedes pagar yo me inclinaría por Oracle, si no, MySql es una gran opción. Te recomiendo que busque en la web de Marteens un artículo sobre cómo elegir SGBD, es muy interesante.

Cita:
Empezado por luqui
¿ Trabajan bien y rapido en red local ?.
Todo lo bien que trabaja Windows, que tampoco es mucho

Cita:
Empezado por luqui
Os digo esto porque no tengo ni idea y me gustaria que alguien me orientara un poco sobre este tema.
Yo de ti me leería un buen libro. El misma web de Marteens tienes "La Cara Oculta De Delphi 4" en pdf de forma gratuita. Aunque hable sobre la versión 4, es perfectamente aplicable a las actuales.


Ahora que te he explicado las bondades de nuestro Adorado Delphi te daré las malas noticias. Con la salida de .NET, todos los programadores estamos "pendientes" a ver que pasa, ya que el futuro a medio / largo plazo de esta herramienta no está claro. Si buscas en el foro de debates encontrarás un hilo llamado "El futuro de Delphi" donde se debate sobre esto. De manera que, si has de empezar "de cero", no sé si es mejor Delphi o C# / VB.NET

Cita:
Empezado por luqui
Gracias anticipadas por vuestra colaboracion.
No dudes en plantear todas tus dudas con nosotros, como decimos en mi tierra, com més serem, més riurem (cuantos más seamos, más reiremos)

Un saludo.[/quote]
__________________
E pur si muove
Responder Con Cita
  #4  
Antiguo 04-02-2004
Avatar de delphi.com.ar
delphi.com.ar delphi.com.ar is offline
Federico Firenze
 
Registrado: may 2003
Ubicación: Buenos Aires, Argentina *
Posts: 5.932
Poder: 26
delphi.com.ar Va por buen camino
Como opinión personal, puedo decirte que es un hermoso lenguaje para aprender.
  • La sintaxis es extremadamente prolija y sencilla.
  • Es muy intuitivo.
  • Es un lenguaje muy fundamentado, nada se hace así porque sí.
  • No suele tener comportamiento errático, lo que escribes es lo que hace. Puedes comprobarlo si entiendes algo de assembler
  • Posee una muy completa y clara documentación y ayuda OnLine.
  • Puedes hacer buenas aplicaciones con poco conocimiento del leguaje.
  • ...
  • Tienes este foro, para solucionar tus dudas

Saludos!
__________________
delphi.com.ar

Dedique el tiempo suficiente para formular su pregunta si pretende que alguien dedique su tiempo en contestarla.
Responder Con Cita
  #5  
Antiguo 05-02-2004
luqui luqui is offline
Registrado
 
Registrado: feb 2004
Posts: 3
Poder: 0
luqui Va por buen camino
Gracias por vuestras respuestas, solamente por a ver respondido tan rapido
y con tanta sinceridad me dan ganas de aprender el lenguaje y participar en
este foro.
Pero os cuento un poco, hace unos meses exporte un fichero de los mios a
formato txt, y un amigo mio que programa en visual basic, creo un pequeño
programa para trasladar esos datos a una base de datos sql, y otra a oracle.
Me hizo unas pruebas y como bien dice kinobi el resultado no fue decepcionante
fue mucho mas allá, cualquier base datos le es imposible menear esa cantidad
de datos con la rapidez que lo hace el cobol con sus archivos indexados nativos.
He estado probando el POWER COBOL que tiene tambien el NET COBOL, y utiliza
los mismos ficheros que el RM/COBOL que es el que yo utilizo (con la posibilidad de conectarte a culquier base de datos) y no habia tanta diferencia solamente
las de windows.
En definitiva que probablemente sigua con el cobol, porque haga lo que haga
me parece que a la larga me voy arrepentir.
De todas maneras me platearé lo del delphi.
Muchas gracias a todos, y os tengo que felicitar por el foro que teneis, ya que veo que hay bastante gente objetiva sin importar el lenguaje que utilices.
Repito muchas gracias a todos y estaremos en contacto.

Un saludo.
Responder Con Cita
  #6  
Antiguo 05-02-2004
Avatar de kinobi
kinobi kinobi is offline
Miembro
 
Registrado: may 2003
Posts: 2.621
Poder: 23
kinobi Va por buen camino
Hola,

Cita:
Empezado por luqui
Pero os cuento un poco, hace unos meses exporte un fichero de los mios a
formato txt, y un amigo mio que programa en visual basic, creo un pequeño
programa para trasladar esos datos a una base de datos sql, y otra a oracle.
Me hizo unas pruebas y como bien dice kinobi el resultado no fue decepcionante fue mucho mas allá, cualquier base datos le es imposible menear esa cantidad de datos con la rapidez que lo hace el cobol con sus archivos indexados nativos.
bueno, no te dejes engañar. Cualquier gestor de base de datos de los que se han nombrado en el hilo es capaz de manejar esa cantidad de información (10 millones de registros) con auténtica soltura. Otra historia es que las aplicaciones clientes, porque estén mal diseñadas y/o construidas, no sean capaces de hacerlo.

Los métodos de acceso y organización de los modernos gestores relacionales no tienen nada que envidiar a los que puedas utilizar en COBOL, incluso van más allá: control transaccional (contra una o varias bases de datos): atomicidad de las operaciones, consistencia, aislamiento y persistencia (las propiedades ACID); posibilidad de uso de procedimientos almacenados (cierto que para algunos autores es una desventaja, fundamentalmente a la hora de la transportabilidad); utilización de un modelo matemático (el relacional) que se adapta a muchos, muchísimos, de los problemas de modelización del mundo real, ...

Y por si todo esto fuera poco, tienes el Lenguaje Estructurado de Consultas (SQL), en mi opinión mucho más potente a la hora de la gestión, mantenimiento y recuperación de la información que el más evolucionado de los COBOL.

Saludos.

Última edición por kinobi fecha: 05-02-2004 a las 17:16:02.
Responder Con Cita
  #7  
Antiguo 26-02-2004
luqui luqui is offline
Registrado
 
Registrado: feb 2004
Posts: 3
Poder: 0
luqui Va por buen camino
Mi decision ha sido tomada, me quedo con el NETCOBOL.

Funciona igual que cualquier cobol, con su comandos standard, y con todos
los nuevos salidos en esta version.
Los runtimes son gratuitos no exiten royalties, solo se paga a nivel de desarrollador (esta era una de las grandes pegas que tenia).
Puedes utilizar su motor de ficheros indexados o conectarte a cualquier base
de datos SQL, ORACLE etc.
El futuro de NETCOBOL esta asegurado, ya que microsoft lo ha incluido en su
plataforma.NET.
Lo he estado evaluando durante estos dias (de lo cual me he quedado impresionado) y he hecho mis pruebas y aqui me remito en los resultados:

Velocidad de ejecucion:
Impresionante, la verdad es que no me esperaba esta velocidad, lo he probado en terminales con pentiun 400 y terminales pentiun 2200 y no he
notado ninguna diferencia en la ejecucion.

Velocidad en ficheros:
este era el kit de la cuestion, he instalado la base de datos SQL para hacer mis pruebas, y creado una serie de formularios con un tratamiento de articulos para una produccion en cadena que es a lo que nos dedicamos en nuestra empresa. He pasado mi fichero de notas de produccion de historico, articulos, componentes etc a formato ASCI y he importado esos datos a SQL y a ficheros nativos cobol. Una vez que tenia los mismos datos en SQL y ficheros cobol empezó la prueba.
Hice dos programas distintos, uno atacando a la base de datos SQL y otro a los ficheros cobol nativos. Los resultados fueron: SQL tardó en procesar las notas de produccion para su emision 24 minutos, COBOL tardó 4 minutos.
La diferencia es bastante notable. Despues accedí desde terminales a sql y se ralentizaban las consultas y desde cobol no se apreciaba retardo ninguno.
Despues tambien me di cuenta que desde terminales en dos en RM/COBOL puedo acceder a los ficheros de NETCOBOL, ya que utilizan las misma estructura porque resulta que es el mismo motor, osea que puedo tener terminales antiguos en MSDOS y terminales con NET COBOL trabajando en red y utilizando los mismos ficheros.

Bueno estas han sido mis pruebas, y lo que me ha hecho que me decantara por un lenguaje u otro.

De todas maneras os sigo agradeciendo que me acogierais de esta manera sin ser ningun programador en DELPHI y me contestarais a las dudas que tenia en ese momento.

Ante todo muchas gracias y un saludo.
Responder Con Cita
  #8  
Antiguo 26-02-2004
Avatar de kinobi
kinobi kinobi is offline
Miembro
 
Registrado: may 2003
Posts: 2.621
Poder: 23
kinobi Va por buen camino
Hola,

Cita:
Empezado por luqui
Hice dos programas distintos, uno atacando a la base de datos SQL y otro a los ficheros cobol nativos. Los resultados fueron: SQL tardó en procesar las notas de produccion para su emision 24 minutos, COBOL tardó 4 minutos.
La diferencia es bastante notable.
la diferencia es notable, pero falta muchos datos para saber si es "real". Habría que conocer qué servidor SQL se ha utilizado, el modelo de datos (relacional) utilizado, índices creados; en función del servidor utilizado, qué parámetros (a nivel del servidor y de la propia organización de archivos de base de datos) se han configurado y cómo; cuáles han sido las consultas que se han utilizado para atacar al servidor SQL; si se ha utilizado un entorno host: qué lenguaje se ha utilizado, cuáles son los métodos de acceso que provee ese entorno para conectarse al servidor SQL y cómo se han usuado, ...

Un mismo servidor SQL puede dar resultados completamente diferentes en cuanto a rendimiento, incluso de varios órdenes de magnitud, variando uno sólo de esos parámetros.

No pongo en duda tus resultados, pero estoy convencido que también podrían obtenerse los contrarios (a favor de un servidor SQL frente a un entorno de desarrollo como el de RM/COBOL o NETCOBOL).

En todo caso, me alegro que hayas encontrado una solución a tu problema.

Saludos.
Responder Con Cita
Respuesta


Herramientas Buscar en Tema
Buscar en Tema:

Búsqueda Avanzada
Desplegado

Normas de Publicación
no Puedes crear nuevos temas
no Puedes responder a temas
no Puedes adjuntar archivos
no Puedes editar tus mensajes

El código vB está habilitado
Las caritas están habilitado
Código [IMG] está habilitado
Código HTML está deshabilitado
Saltar a Foro


La franja horaria es GMT +2. Ahora son las 12:59:37.


Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi
Copyright 1996-2007 Club Delphi