Que tan viable es php

[josevictorbj]

Hola,

Tenemos un aplicativo que maneja unas 60 tablas, y hay algunas de ellas que manejan millones de registros, en una base datos sobre informix y linux el aplicativo esta hecho en 4gl. Pues bien la idea es migrar este programa a php con postgresql, esta base de datos solo es accesada por usuarios de una intranet local aprox. 30 usuarios, la gran duda debido al desconocimiento que tengo sobre php y la programacion web es sobre que tan viable ven ustedes este cambio, que desventajas o ventajas tendriamos, en cuanto a los reportes he escuchado que es un poco problematico, cabe anotar que tenemos que sacar reportes en formas preimpresas. Les agradezco la ayuda

[AlvaroG]

Pos me parece que si necesitás hacer los reportes, e interactuar con el sistema más allá de simplemente trabajar en el entorno web, quizás PERL te sirva más que PHP.
En cuanto a la carga, pos creo que si el servidor maneja la carga, php no te va a dar problemas por si mismo...

Pero escribo de atrevido nomás, probablemente haya gente en este foro con mucha más experiencia que yo.


Saludos.

[matiasdag]

Creo que depende. Si ya "compraste" PostgreSQL nadie te va a sacar de la cabeza que es lo mejor. Lo mismo pasa con los lenguajes, la gente suele casarse con un lenguaje (o un par) y usar ese para todo antes de hacer un minimo relevamiento porque se piensa que "es mas rapido" hacerlo con la herramienta conocida aunque no sea la apropiada que aprender una nueva.

Si necesitas acceso navigacional a los datos, te conviene una base de objetos (o base de datos orientada a objetos, u ODBMS) si el acceso es tabular, te conviene una base de datos relacional o RDBMS.

De ahí en mas no se si PHP se banca un ODBMS. Lo que dice Alvlin esta bien, si necesitas mucho tratamiento de texto (aparte de recuperar los datos) te conviene PERL, luego hay lenguajes para todos los gustos, depende que quieras favorecer, con PHP se favorece la "rapidez" de implementacion y facilidad (a veces) para resolver problemas (muchos problemas son causados por la mala eleccion del lenguaje o tecnologia, pero se ignora, y por eso se consideran "naturales" los problemas) por la gran comunidad de usuarios.

En que 4GL esta hecho?

[josevictorbj]

Primero quiero agradecerte por la orientacion, en cuanto a tu pregunta la version del 4gl es la 7.32, la idea nace de alguien que tenemos en la empresa quien hizo un programa de nomina en php el cual teniamos tambien en 4gl, este a gustado mucho sobre todo que se salio del entorno caracter a grafico tipo web. esto ultimo es lo que a impulsado la idea de seguir migrando y lo de postgresql es por $$ el licenciamiento.

[DarioDario]

El tema que planteas es delicado. Con el tema de la base de datos solo corresponde al motor de base de datos... PHP no te genera ningún problema con esto, PHP trabaja con la gran mayoría de ellas, el tema es que si tienes millones de registros en la DB y tarda o no en recuperar datos es un tema de el motor.

PHP a MI GUSTO (para que sepan que es una opinion) es una gran herramienta y muy poderosa pero hay que tener en claro varios puntos. Por ejemplo PHP no imprime nos esta hecho para imprimir reportes (imprimir me refiero imprimir en papel, generar los genera sin problemas). Si necesitas si o si imprimir en papel te recomiendo hacerte un modulo en PERL para esto.

PHP es muy versatil y bueno, pero esto depende de gusto. Tambien tiene ASP pero esto es otro tema.

Antes de PERL en mi caso te recomendaría Python, la oposicion real a PERL, es mucho mas limpia su sintaxis, tiene mucho poder, puedes programar aplicaciones de escritorio como aplicaciones WEB, es totalmente basado en objetos y unos cuantos BLA BLA BLA. Esto lo tendrías re revisar tú y sacar tus propias concluciones sobre el tema.

[OFF TOPIC]
Actualmente me encuentro estudiando Python, despues de una gran busqueda de información entre varios lenguajes y muchas comparativa. Lo estoy estudiando por un gusto personal, pero sobre todo (una de las cosas que mas peso en mi decicion) porque le veo una gran integración entre PHP y Python, si bien no van de la mano, se los puede hacer interactuar perfectamente y sobre todo ninguno de los dos tiene problemas con terceras herramientas (por ej. los motores de base de datos que utilizo).
[/OFF TOPIC]

Saludos y espero que mi post sirva de algo.

[edwinandlozano]

Tengo una pregunta DarioDario tu indicas que php no esta hecho para imprimir y que se piense en un modulo en perl.. ahora mi curiosidad es la siguiente: si el sistema es web y tanto php como perl son lenguajes que estan al lado del servidor entonces ambos tendrian las misma desventaja o me equivoco??? almenos de que la impresora este en el servidor ambos lenguajes tienen funciones para manipularlas... si el inconveniente esta en imprimir informes que se prensentan en aplicaciones web entonces el problema no reside en el lenguaje "servidor" sino en la parte de la presentacion .. para esto no tenemos los css???..

[Cluster]

Iniciado por edwinandlozano

Tengo una pregunta DarioDario tu indicas que php no esta hecho para imprimir y que se piense en un modulo en perl.. ahora mi curiosidad es la siguiente: si el sistema es web y tanto php como perl son lenguajes que estan al lado del servidor entonces ambos tendrian las misma desventaja o me equivoco??? almenos de que la impresora este en el servidor ambos lenguajes tienen funciones para manipularlas... si el inconveniente esta en imprimir informes que se prensentan en aplicaciones web entonces el problema no reside en el lenguaje "servidor" sino en la parte de la presentacion .. para esto no tenemos los css???..

Lo que sucede es que PHP no tiene funcionalidades directas como para acceder a "puertos" (del servidor: LPTx, COM .. USB ... como para manejar impresoras conectadas al servidor directamente o por rutas de LAN ...).

Lo único que tiene y que sólo funciona para PHP bajo windows son las extensiones:

Printer
www.php.net/printer

Con "Perl" tienes más control al respecto (de puertos y demás).

Igualmente Perl o PHP funcionando "del lado del servidor" y queriendo "imprimir" en impresoras conectadas a los "clientes" directamente vas a tener el mismo problema a la hora de imprimir.

Los "CSS" o montar la estructura del docomuento a imprimir no es el problema .. sino la "impresión" en sí .. es decir, en CSS/HTML ni javascript directo tienes funciones para controlar la impresora:.. para definir un salo de página, mandar a imprimir N copias sin iteracción de una persona que lo haga "a mano" .. y temas similares que resuelves cómodamente en un lenguaje "de escritorio".

Para eso en el lado del "cliente" tienes sus própios lenguajes como por ejemplo "ActiveX" o "Applet Java" para tal fin .. para controlar por ejemplo tu tema concreto: impresión.

En PHP se estila mucho generar "PDF's" dinámicamente como versión a imprimir .. pero en ese caso generas ese tipo de documentos y tienes los problemas sobre la impresión "directa".

Por otro lado .. en cuanto a las "interface" para ingresar datos .. también hay que prestarle atención. Tus usuarios de tus actuales aplicaciones "modo texto" están acostumbrados a interfaces "rápidas" de ingreso de datos .. de validaciones "al servidor" rápidas .. etc. Fijate que una aplicación "web": normal, hay muchas recargas de página .. formularios HTML con elementos muy simples (nada de "grillas" y controles así que tienen ya implementados lenguajes "de escritorio" ..) en fin .. no quiere decir que no se puedan desarrollar interfaces "buenas" y "usables" en este entorno "web" pero si que tienes que tener presente que hay que recurrir muchas veces a otras técnicas que involucran otros conocimientos .. por ejemplo: Ajax (que está de "moda") donde puedes crear interfaces bastante atractivas y más parecidas en forma de funcionar a lo que una aplicación "clásica" de escritorio hace pero con la "gracias" de interactuar con tu navegador y tu lenguaje de lado del "servidor" (PHP o lo que uses y este a su vez con la BBDD a la que te conectes).

En resumen .. la respuestas a la pregunta es: SI, PHP es viable .. pero no -sólo- .. sino que acompañado de mucho: Javascript, DHTML, Ajax, e incluso "ActiveX" o "Applet Java" .. etc. Esto no es como decir "lo hago todo en "Visual Basic" y de ahí no sales .. aquí hay que "saber" o "conocer" de otras técnicas y lenguajes para llegar a buenos resultados.

Un saludo,

[edwinandlozano]

Iniciado por Cluster

Igualmente Perl o PHP funcionando "del lado del servidor" y queriendo "imprimir" en impresoras conectadas a los "clientes" directamente vas a tener el mismo problema a la hora de imprimir.

Ha esto queria llegar si ambos lenguajes son "del lado del servidor" van a tener el mismo inconveniente.

Iniciado por Cluster

En PHP se estila mucho generar "PDF's" dinámicamente como versión a imprimir .. pero en ese caso generas ese tipo de documentos y tienes los problemas sobre la impresión "directa".

Ahora como dice cluster en aplicaciones web enable para realizar reportes impresos se esta utilizando pdf's pero en este tambien tendras el inconveniente de tener que interactuar hasta cierta parte con el usuario (impresion directa).. para eso me sigo dando palo con css que tiene metodos para dar un estilo segun el medio en que se despliegue (sea papel, pantalla, aural, braille) y sin necesidad de implementar creacion de pdf's en el servidor...

[Cluster]

Iniciado por edwinandlozano

Ha esto queria llegar si ambos lenguajes son "del lado del servidor" van a tener el mismo inconveniente.



Ahora como dice cluster en aplicaciones web enable para realizar reportes impresos se esta utilizando pdf's pero en este tambien tendras el inconveniente de tener que interactuar hasta cierta parte con el usuario (impresion directa).. para eso me sigo dando palo con css que tiene metodos para dar un estilo segun el medio en que se despliegue (sea papel, pantalla, aural, braille) y sin necesidad de implementar creacion de pdf's en el servidor...

mm Bueno .. pero si bien en CSS puedes definir una "vista" para el médio "printer" .. Generar un documento PDF si bien es más complejo .. también es más "profesional" bajo mi punto de vista (pese a su consumo de recursos). De hecho es ideal para tomarlo y enviarlo por e-mail y así no depender de como el "cliente de correo" de turno interprete ese CSS/HTML. Dominiar bien temas de paginados y en general definición del documento a imprimir exacto y standar (como así define "Portable Documento Format": PDF).

En definitiva todo tiene sus "pro's" y sus "contras" .. también hay que ver en que contexto hablamos ..

(Por mi parte, tengo aplicaciones para "intranets" que generar un HTML simple que fuerzo a imprimir con un window.print simple .. por qué son "comprobantes" de ingreso/etc, documentos que no importa mucho como se impriman .. pero por otro lado genero PDF's cuando se trata de generar un "contrato" o simlares donde la precisión y control del documento a imprimir es primordial).

Un saludo,

Un saludo,

[edwinandlozano]

Iniciado por Cluster

mm Bueno .. pero si bien en CSS puedes definir una "vista" para el médio "printer" .. Generar un documento PDF si bien es más complejo .. también es más "profesional" bajo mi punto de vista (pese a su consumo de recursos). De hecho es ideal para tomarlo y enviarlo por e-mail y así no depender de como el "cliente de correo" de turno interprete ese CSS/HTML. Dominiar bien temas de paginados y en general definición del documento a imprimir exacto y standar (como así define "Portable Documento Format": PDF).

En definitiva todo tiene sus "pro's" y sus "contras" .. también hay que ver en que contexto hablamos ..

(Por mi parte, tengo aplicaciones para "intranets" que generar un HTML simple que fuerzo a imprimir con un window.print simple .. por qué son "comprobantes" de ingreso/etc, documentos que no importa mucho como se impriman .. pero por otro lado genero PDF's cuando se trata de generar un "contrato" o simlares donde la precisión y control del documento a imprimir es primordial).

Un saludo,

Un saludo,

Como dices Cluster todo tiene sus pro y sus contras y en tu explicacion acabas de dar dos ejemplos muy claros en donde puedo aplicar la creacion de un documento pdf y cuando puedo manejarlo con css...
Si alguien quiere leer mas sobre css y sobre sus diferentes medios aqui dejo una referencia:
http://www.sidar.org/recur/desdi/tra...css/media.html
http://www.sidar.org/recur/desdi/tra.../css/page.html

[Cluster]

El problema final sigue siendo el mismo:

Cuando tenemos que controlar impresión directa; lease: "punto de venta" que tiene que imprimir un "comprobante/ticket/resguardo" por una impresora y a la vez una "factura" en otra impresora .. En estos casos un "lenguaje" del lado del cliente podría solventar el problema: ActiveX o similar.

Un saludo,