Re: iniciando desarrollo bd

Juan Martínez escribió:
> Alvaro Herrera escribió:
> >WILLIAM PARRA escribió:
> >>En tal sentido, te pregunto: ¿Cual de las dos formas es más práctica y
> >>eficiente?
> >
> >Es que no es tan simple como decir que una forma gana sobre la otra
> >por el asunto de tener vista remota de los datos. Hay un tema de tiempo
> >de desarrollo para el asunto web que es bastante mas complicado, por el
> >tema de escribir el javascript correcto, verificar que funcione bien en
> >cualquier browser, etc etc, que al principio del desarrollo se ignora y
> >no se considera en el costo del mismo, pero a la larga termina siendo
> >muy doloroso.
>
> Eso es cierto hasta por ahi.
>
> Segun lo que entendi, la persona que hace la consulta explico que seria
> una aplicacion en un entorno conocido, es decir, sabe quienes la va a
> usar. Teniendo esa variable resuelta, entonces es mas facil poner
> ciertos requisitos para usar una webapp.

Eso es utopico. Ya estuve ahi, los requerimientos estaban claros desde
el principio, "solo usaremos Netscape tal y tal version". Todo
funcionaba maravilloso; despues resulto que el tipo de ventas tenia que
usar Internet Explorer por algun motivo, y no hubo ninguna forma de
impedir cambiar el requerimiento.

> >(no es agradable cuando el jefe te dice "Fijate que me llamo un cliente
> >que tiene IE 7.1.00.2 y el cuadrito de tal y tal parte le sale de color
> >damasco cuando deberia ser terracota ...
>
> Uhh..debes tener muy mala experiencia en ese terreno...debes haber
> tenido jefes muy inchapelotas...

Claro; y al contrario, no es que haya tenido jefes hinchapelotas, sino
que la cruda realidad te pone las cosas dificiles.

> >crea una nueva hoja de estilo
> >pero asegurate que no eches a perder la hoja que funciona con Safari
> >10.4FOO y ten cuidado con los margenes que corregiste del Firefox 2.0.
> >Ah y no te olvides de corregir el problema de XSS que nos tiene con el
> >phishing apuntando al Citibank")
>
> Insisto, el consultante podria definir ciertos requisitos para la
> aplicacion.

Claro, dejalo que lo haga y en un an~o mas volvera con una problema
distinto.

> >Si es necesario lo de permitir una vista remota para que el gerente vea
> >las cosas desde su casa, entonces una idea es encontrar un compromiso y
> >desarrollar una webapp "read-only",
>
> Normalmente el gerente quiere trabajar desde la casa, por lo que esa
> solucion no creo que le guste mucho. Ahora esto se puede elaborar mas
> diplomatica o politicamente: "llamas a la esposa y le preguntas que
> version de navegador tiene en casa, y se te pregunta por que, ah que es
> para una aplicacion que estas haciendo para su marido que le va a
> permitir trabajar todo el dia en casa..." :-) Acto seguido, la esposa
> cuelga el telefono y formatea el equipo ;-)

????

Si el gerente quiere trabajar de la casa, pues se le instala la
aplicacion cliente en la casa. Es mucho menos trabajo que hacer una
webapp. El punto de tener la webapp era poder acceder a los datos
"desde cualquier parte"; si quieres hacer algo mas que simplemente
mostrar un grafiquito, instala la aplicacion cliente y listo.

> >(Obviamente, tanto la app cliente-servidor como la webapp deben
> >compartir la mayor cantidad de codigo posible, almacenandolo en forma de
> >SPs o vistas en la base de datos.
>
> Claro. Es lo ideal, ahora que tan factible?

Totalmente factible, como mucha gente que lo ha hecho puede atestiguar
... ahora, si tienes un equipo de desarrollo penca, estas frito sea cual
sea tu plataforma.

> Pero webapp la gracia que tiene, es precisamente la compatibilidad y
> portabilidad. Ademas es mucho mas rapido de desarrollar, si lo haces con
> buenas costumbres de programacion. Tiene desventajas como todo eso
> si...Yo no las mandaria tan rapido al despeñadero...

Portabilidad? Cual portabilidad? Con los lios que ya mencione
(javascript, etc) es un cacho. Rapido de desarrollar? No me hagas
reir. Desarrollar una aplicacion cliente es mucho mas rapido (bueno,
dependiendo del lenguaje que escojas supongo).

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.