06/02/2006, 15:46
| |||
| |||
| En que desarrollar una aplicacion de facturacion y stock. Estimados, la idea es que me den sus opiniones, ya que tengo que desarrollar una aplicacion de facturacion, stock, manejo de clientes, etc y estoy pensando en que lenguaje hacerlo. Mi idea es usar c# y para la base de datos no estoy seguro de que usar. que se les ocurre? tanto para la aplicacion como para la bd. Saludos y gracias. PD: aclaro que no puede ser una aplicacion web sino que tiene que ser una aplicacion de escritorio.
__________________ Liber |
|
06/02/2006, 16:23
| |||
| |||
| gracias por la idea. visual basic lo encuentro medio feo, pero mysql, me gusta, lo que no se me ocurre si es posible integrarlo facilmente con aplicaciones de escritorio. Se puede lograr? Saludos.
__________________ Liber |
|
06/02/2006, 16:32
| ||||
| ||||
| Nuu, si bien mysql es extremadamente recomndable, no te lo recomiendo para usarlo en aplicaciones que pienses venderle a personas que no tengan conocimientos. Usá VB con Acces ADO. Si les decis "pero necesitas mysql" te van a decir "qué cosa pibe?"... Eso solo una opinión. Salu2!
__________________ diegoz.com.ar |
|
07/02/2006, 15:55
| ||||
| ||||
| Java y MySQL... y no por ser java tiene que ser aplicacion web, puedes desarrollar una de escritorio. Además es OpenSource. La otra es .NET y MS SQL, claro que para estos requieres comprar la licencia...
__________________ Saludos... Todos somos sabios, solo que en diferentes disciplinas... |
|
07/02/2006, 16:11
| |||
| |||
| Java puede ser una buena opcion, lo que quiero es no tener que montar un server para base de datos independiente de la aplicacion. Mi duda principal radica en ese punto. Que usar como bd, para evitar tener un server corriendo. Que les parece? Saludos.
__________________ Liber |
|
08/02/2006, 16:07
| ||||
| ||||
| ja ja... que mente... Claro que vas a tener que montar un servidor de Base de Datos si vas a desarrollar una aplicacion Cliente/Servidor. Lo primero que tienes que considerar es en que lenguajes saber programar.... a estas alturas todas las bases se pueden integrar con cualquier aplicacion. Tambien si tienes buenas maquinas ya que para .net de ley necesitas maquinas potentes. Si necesitas hacer algo rapido puedes utilizar vb y access. Pero access como base de datos para algo serio no es muy recomendable. Ah por cierto, solo soporta sin que de problemas hasta 10 usuarios |
|
08/02/2006, 16:48
| ||||
| ||||
| Lo del server que no quiere montar liberfg se refiere al de BD no al server de red... De todas maneras, si no quieres montar un DBMS (Server de BD) la verdad te estarias metiendo en un gravisimo problema ya que todas las operaciones que los DBMS hacen con la informacion las tendráis que desarrollar tu... y la verdad es como si quisieras reinventar la rueda... Pero de que lo puedes hacer sin DBMS lo puedes hacer...
__________________ Saludos... Todos somos sabios, solo que en diferentes disciplinas... |
|
08/02/2006, 16:50
| ||||
| ||||
| Ademas, el trabajo que te va a llevar montar el DBMS y la aplicación es muy simple a comparación de lo que intentarias realizar...
__________________ Saludos... Todos somos sabios, solo que en diferentes disciplinas... |
|
09/02/2006, 01:46
| |||
| |||
| yo en tu lugar montaria un webserver y desarrollaria con ASP o con PHP la aplicacion, luego no sabes las broncas de dlls al menos con Visual Basic 6 para correr ciertos controles. |
|
09/02/2006, 05:15
| |||
| |||
| Por lo que estoy viendo me voy a decidir por php y mysql, con los que ya tengo experiencia. Me parecia que una aplicacion de escritorio me iba a facilitar el tema de la impresion de las facturas, pero creo que se puede hacer de buena forma diagramando la misma con html e imprimiendo desde el browser. no? Saludos y gracias por todos los aportes!!! Liber
__________________ Liber |
|
10/02/2006, 00:47
| |||
| |||
| la impresion de formatos preimpresos puede darte ciertos problemas lo mas recomedable es que personalices el Internet Explorer de las maquinas de las cuales se imprimira (File-Page Setup- QUitar el header y footer y dejar los margenes acordes a prueba y error hasta q caiga bien), eso si el corte de page en caso de que tu impresion sea muy larga no podras controlarla, otra opcion es imprimr desde una movie Flash que tiene mejor control sobre la impresion. |
|
10/02/2006, 06:35
| |||
| |||
| Creo que voy a tener mas problemas con eso de lo que pensaba ya que tengo que imprimir en impresoras de aguja. Segun tengo entendido esto puede complicar un poco las cosas.... es verdad? Saludos
__________________ Liber |
|
10/02/2006, 17:46
| |||
| |||
| si ya tenias en mente usar C# , yo creo que esa es una excelente opcion. Podrias usar c# y mysql o ms sql server..... tambien podrias usar java con oracle o algo asi..... creo que cualquier opcion de esas es igualememtne buena para lo que quieres hacer..... saludos, |
|
11/02/2006, 20:38
| |||
| |||
| hay formas de salvar el problema con impresoras de aguja tambien, yo crearia primero el template en HTML y veria como cae al informacion, afortunadamente como las impresoras de aguja no manejan muchos fonts escogeria una tipo courier para q respetara el ancho de cada caracter. Prueba y veras si te acomoda o no... con el puro template html estatico, ya luego viene la talacha de hacerlo dinamico con la info de la database. Las ventajas de desarrollarlo en web son varias, ya que unicamente tendras q configurar el webserver central, y cualquiera podra acceder en la intranet a la aplicacion con el explorador, si hay q modificar algo lo haces simplemente en el server, los clientes veran los cambios. Si posteriormente quieres que una cotizacion o factura se envie via web puedes crear el archivo para adjuntarlo en un email, o bien, si alguien de la empresa quiere desde fuera acceder para el mantenimiento de la aplicacion, puede hacerlo si migras tu aplicacion tal cual esta hacia un webhosting comercial. |
|
12/02/2006, 04:37
| |||
| |||
| Cita: Puedes usar la memoria ram, que para eso se ha inventado, ¿no? Cada cierto tiempo, la vuelcas toda al disco duro. Te evitas tener servidores corriendo, bases de datos, conexiones...
Iniciado por liberfg Java puede ser una buena opcion, lo que quiero es no tener que montar un server para base de datos independiente de la aplicacion. Mi duda principal radica en ese punto. Que usar como bd, para evitar tener un server corriendo. Que les parece? Saludos. |
|
12/02/2006, 16:46
| |||
| |||
| BUenas ideas todas.... estoy ente c# y web (php mysql), la decision la tomo la semana que viene (entre mañana y pasado...). Luego les cuento por que me decidi! Saludos. Liber
__________________ Liber |
|
12/02/2006, 17:30
| ||||
| ||||
| podria preguntarte porque querias evitar tener un server de BD andando?
__________________ http://blog.tolaware.com.ar -> Blog de Java, Ruby y Linux |
|
13/02/2006, 05:51
| |||
| |||
| Hola TolaWare, creo que crei (valga la redundancia) que era la mejor manera de no complicar a las personas para las cuales voy a desarrollar ya que no tienen una infraestructura (pcs) que me parecieran adecuadas para montar una gran aplicacion, pero ya que los requerimientos para hacer andar php y mysql son relativamentes bajos creo que me voy a decidir por eso. Saludos, Liber
__________________ Liber |
|
13/02/2006, 07:43
| |||
| |||
| Cita: La pregunta no es esa, sino: "¿Y por qué debería tener un servidor?" No es necesario. Es más, tenerlo hace que: Gastas recursos, memoria RAM, el procesador se reparte en más procesos, se realizan muchas más operaciones para el mismo resultado y es menos flexible que hacerlo tú mismo.
Iniciado por TolaWare podria preguntarte porque querias evitar tener un server de BD andando? |
|
13/02/2006, 07:45
| |||
| |||
| Cita: Precisamente, en tu caso es mejor una aplicación que centralice el proceso e implique los menos recursos posibles, en vez de usar un mismo ordenador para ejecutar un intérprete de PHP, el script de PHP, el servidor SQL, el sistema usando el protocolo TCP/IP... La pérdida de rendimiento es _enorme_. Programando una aplicación nativa que se encargue de todo nos deja con 1 proceso en ejecución nativo. De la otra forma, nos deja con varios procesos (el servidor SQL usará más de un hilo, seguro), consumo de RAM, procesamiento, carga del sistema y de la red... Y lo que es peor, PHP es interpretado, con la consiguiente extrema pérdida de rendimiento.
Iniciado por liberfg Hola TolaWare, creo que crei (valga la redundancia) que era la mejor manera de no complicar a las personas para las cuales voy a desarrollar ya que no tienen una infraestructura (pcs) que me parecieran adecuadas para montar una gran aplicacion, pero ya que los requerimientos para hacer andar php y mysql son relativamentes bajos creo que me voy a decidir por eso. Saludos, Liber |
|
13/02/2006, 09:35
| ||||
| ||||
| Si estás hablando de aplicacion de escritorio C# pueder ser una excelente  opción y usar mysql como SGBD, si tienes problemas con licencias no es necesario que tengas que comprar el VSNet para desarrollar, lo puedes hacer con Sharp Develop una IDE bastante buena...Ahora, va a depender mucho la arquitectura que vayas a manejar para construir tu sistema, si vas a manejar algun tipo de COM+, Service, etc.., es importante hacer todo ese tipo de evaluacion para saber hasta donde puedes llegar así como considerar las características físicas de los equipos.. Salu2
__________________ Nadie roba nada ya que en la vida todo se paga . . . Exentrit - Soluciones SharePoint & Net |
|
13/02/2006, 12:13
| |||
| |||
| Esto se esta poniendo muy interesanate para mi. Esta bueno ver todos los puntos de vista y opiniones. Todos concuerdan con MaxExtreme en la perdida de rendimiento con una aplicacion web? Saludos
__________________ Liber |
|
13/02/2006, 12:30
| |||
| |||
| Cita: El problema no es que sea web (las primeras aplicaciones web se programaban en C y Perl).
Iniciado por liberfg Esto se esta poniendo muy interesanate para mi. Esta bueno ver todos los puntos de vista y opiniones. Todos concuerdan con MaxExtreme en la perdida de rendimiento con una aplicacion web? Saludos El gran problema es que PHP es código interpretado, es decir, tu ordenador ejecuta un programa que a su vez lee un fichero de texto (.php) y tiene que analizar las líneas y hacer lo que dicen (como lo que hace un compilador). Otro problema, es el servidor SQL, gasta recursos como cualquier otra aplicación. Otro más, es el tema de las conexiones entre programa y SQL. No sólo gastas en fabricar las llamadas SQL "GET tal FROM tal", también el servidor en recibirlas y re-procesarlas. Otro más, esas conexiones funcionan mediante TCP/IP, por lo que el sistema debe estar manejando el protocolo TCP, el IP, y la tarjeta de red; como cuando navegas por Internet. (etc). La carga no sería tanta si dispusieras de varios ordenadores, porque el gran problema, el servidor SQL, ya no estaría. Ahora bien, si juntas todo en 1 sólo ordenador... Todos estos problemas literalmente "desaparecen" con una sola aplicación. Ejemplo: Cambias un valor en tu BD. En un programa nativo supondrá esto: ActualizarValor(123); -> Cambiará el valor en la memoria RAM (acción realizada en micro-nanosegundos). En cambio, si tu haces el par PHP+SQL, harás: ActualizarValor(123); -> Debes transformarlo en una sentencia SQL: EscribirValorSQL(123); -> A su vez, enviará a través de la API SQL: EnviarSentencia("lo que sea"); -> Ese dato viajará por TCP/IP send(); -> Aquí el sistema se pondría a trabajar con TCP/IP (unos 0.010 segundos en red local para que llegue al destino, otra cascada de código a procesar). recv(); -> El sistema del servidor recibirá por TCP/IP la orden (otra cascada aquí) RecibirSentencia(); -> Que se transformará en una orden (otra cascada de órdenes aquí) GuardarValor(123); -> Ahora SÍ guardará el valor. ¿Ves la diferencia de cascada de órdenes? (Es un ejemplo _simple_). Si se entiende cómo funcionan las cosas "por dentro", entiendes la cantidad de procesamiento que requiere llevar a cabo una sencilla operación como enviar un dato a un servidor SQL. Sólo el protocolo TCP/IP no sabes la de líneas de código que lleva... |
|
13/02/2006, 16:24
| |||
| |||
| Bueno, en realidad entiendo lo que decis, pero no estoy seguro de compartirlo, osea, un ordenador medianamente moderno puede hacer funcionar un server con apache php y mysql, cuando a lo mejor el mismo pc no soporta la instalacion de framwork.net para correr un programa en c#. Por eso la duda de si realmente consumira mas recursos en un ordenador no de ultima generacion un server con php apache y mysql o una aplicacion en c#.... que te parece? Saludos!
__________________ Liber |
|
13/02/2006, 16:46
| ||||
| ||||
| Cita: Bueno.. antes de continuar.. entonces estás hablando de una aplicacion web o una aplicacion de escritorio..??? porque al hablar de Apache estás hablando de web ya que es un servidor http que vendría siendo lo equivalente al IIS, pero me llama la atencion hacia que lo estás orientando...
Iniciado por liberfg Por eso la duda de si realmente consumira mas recursos en un ordenador no de ultima generacion un server con php apache y mysql o una aplicacion en c#....  |
|
13/02/2006, 17:50
| |||
| |||
| Cita: Creo que no me has entendido, porque entonces no preguntarías cuál consume más... Una aplicación nativa/compilada (C#) funcionará más rápido que cualquiera interpretada (PHP) + servidores aparte (SQL).
Iniciado por liberfg Bueno, en realidad entiendo lo que decis, pero no estoy seguro de compartirlo, osea, un ordenador medianamente moderno puede hacer funcionar un server con apache php y mysql, cuando a lo mejor el mismo pc no soporta la instalacion de framwork.net para correr un programa en c#. Por eso la duda de si realmente consumira mas recursos en un ordenador no de ultima generacion un server con php apache y mysql o una aplicacion en c#.... que te parece? Saludos! |
|
13/02/2006, 18:54
| ||||
| ||||
| Claras, muy claras las observaciones de MaxExtreme. Ahora, yo en lo personal he tenido pobres resultados con C# para ese tipo de desarrollos por que los clientes requieren de equipos relativamente potentes. He usado Delphi y SQLite como algo muy ligero y rápido. Tambien Delphi y FireBird me han dado resultados. C# y MDSE es lo último que le puse a un cliente pero requiere de más equipo por las razones que ya se han expuesto en los mensajes anteriores. |
|
13/02/2006, 19:02
| ||||
| ||||
| Cita: Pero porque resultados pobres..?? tengo algunos sistemas para desktop app con bases de datos mayores a 5Gb mas de a 2 millones de registros con equipos desde pentium III win 98 con 64Mb (no pasa la query mas grande a los 6 seg) hasta Win 2003 con 1Gb en RAM de 2Ghz (de 2 a 4 seg), y los tiempos de respuesta son bastante buenos, creo que tambien influye como tengas tu diseño y a cuantas capas lo estés elaborando, tambien con lo que me apoyo es con los pooling de objetos y pooling de conexiones (gracias COM+)así como del caching para los resultados y en ocasiones si es necesario mantener algunas sessiones fisicamente en la Base de datos serializando y deserealizando mis objetos en XML..
Iniciado por Myakire Ahora, yo en lo personal he tenido pobres resultados con C# para ese tipo de desarrollos por que los clientes requieren de equipos relativamente potentes. Pero bueno, no me quiero desviar del tema, solo son datos que tengo, y hasta ahorita estoy bastante agusto con C# , pero bueno, como lo he comentado.. depende ya del diseño y/o arquitectura que maneje cada uno.  |
