C# y sistemas Windows

18/10/2007 - 16:09 por Leonel | Informe spam
En mi empresa estamos en la eleccion de un buen lenguaje para sistemas
Windows que manejan datos.

Con su experiencia, que tal son los sistemas en C# para Windows?

estables ? rapidos? se recomienda? etc.

Leo

Preguntas similare

Leer las respuestas

#11 Pablo Roca
28/10/2007 - 14:59 | Informe spam
¿En serio no ves la enorme falacia de tu argumento?



Pues no claro que no. No sé donde la ves.

Ahora son un completo anacronismo.



Para sistemas pequeños y medios, para nada. Diselo a los que llevan la base
de datos de mantenimiento del Eurotunel o al gobierno norteamericano, que lo
utilizan en muchas aplicaciones.

Lo que es un anacronismo es que pretendan que los desarrolladores de Visual
FoxPro vean con buenos ojos esta plataforma de NET (que es tan poco RAD).
Pero en fin, ya nos estamos desviando de la tematica del foro.


Saludos,

Pablo Roca
La Coruna - Spain
http://www.portalfox.com
Respuesta Responder a este mensaje
#12 Alfredo Novoa
28/10/2007 - 15:35 | Informe spam
On Sun, 28 Oct 2007 14:59:49 +0100, "Pablo Roca"
wrote:

¿En serio no ves la enorme falacia de tu argumento?



Pues no claro que no. No sé donde la ves.



En que una cosa puede ser válida, pero también obsoleta y
desaconsejable.

Ahora son un completo anacronismo.



Para sistemas pequeños y medios, para nada.



Para cualquier cosa más complicada que una lista de teléfonos es un
disparate utilizar archivos DBF en un desarrollo nuevo.

Y aun en esos casos hay cosas bastante mejores.

Diselo a los que llevan la base
de datos de mantenimiento del Eurotunel o al gobierno norteamericano, que lo
utilizan en muchas aplicaciones.



Serán sistemas heredados del año del catapún.


Saludos
Respuesta Responder a este mensaje
#13 Juan Diego Bueno
28/10/2007 - 16:24 | Informe spam
Hola Alfredo y Pablo Roca:

Ahora que habéis sacado el tema. Acabo de descubrir SQLite como SGBD
relacional ligero y de archivo. No para una lista de teléfonos, pero por
ejemplo, para una aplicación de facturación para una empresa unipersonal de
instalación sencilla ¿cómo lo veis?

SQL Server Express, por instalación, configuración y administración para
estos casos, bajo mi punto de vista se quedaría grande (al igual que otros
sgbd open source como postgresql). Más bien pienso en pequeñas aplicaciones
que mucha gente desarrolla en Access para usuarios que incluso pueden querer
llevarlas en un pendrive, pero pensando en cualquier lenguaje de
programación (no solo .NET) y SQLite

Por supuesto, SQLite tiene limitaciones: no tiene SPs por ejemplo, y aun me
falta por ver si las restricciones CHECK funcionan. Soporta constraints
Foreign Key, pero no las garantiza, pero si tiene triggers instead of para
inserción en vistas, y quizás algunas de estas funcionalidades las soporte
en un futuro.

Saludos

Juan Diego Bueno www.moondance.tk

"Alfredo Novoa" escribió en el mensaje
news:
On Sun, 28 Oct 2007 14:59:49 +0100, "Pablo Roca"
wrote:

¿En serio no ves la enorme falacia de tu argumento?



Pues no claro que no. No sé donde la ves.



En que una cosa puede ser válida, pero también obsoleta y
desaconsejable.

Ahora son un completo anacronismo.



Para sistemas pequeños y medios, para nada.



Para cualquier cosa más complicada que una lista de teléfonos es un
disparate utilizar archivos DBF en un desarrollo nuevo.

Y aun en esos casos hay cosas bastante mejores.

Diselo a los que llevan la base
de datos de mantenimiento del Eurotunel o al gobierno norteamericano, que
lo
utilizan en muchas aplicaciones.



Serán sistemas heredados del año del catapún.


Saludos
Respuesta Responder a este mensaje
#14 Carlos M. Calvelo
28/10/2007 - 16:48 | Informe spam
On 28 okt, 16:24, "Juan Diego Bueno"
wrote:
Hola Alfredo y Pablo Roca:

Ahora que habéis sacado el tema. Acabo de descubrir SQLite como SGBD
relacional ligero y de archivo. No para una lista de teléfonos, pero por
ejemplo, para una aplicación de facturación para una empresa unipersonal de
instalación sencilla ¿cómo lo veis?

SQL Server Express, por instalación, configuración y administración para
estos casos, bajo mi punto de vista se quedaría grande (al igual que otros
sgbd open source como postgresql). Más bien pienso en pequeñas aplicaciones
que mucha gente desarrolla en Access para usuarios que incluso pueden querer
llevarlas en un pendrive, pero pensando en cualquier lenguaje de
programación (no solo .NET) y SQLite

Por supuesto, SQLite tiene limitaciones: no tiene SPs por ejemplo, y aun me
falta por ver si las restricciones CHECK funcionan. Soporta constraints
Foreign Key, pero no las garantiza, pero si tiene triggers instead of para
inserción en vistas, y quizás algunas de estas funcionalidades las soporte
en un futuro.




Hola Diego,

Un par de cosas que me saltan a la vista después de
haber mirado, creo que ni un minuto:

http://www.sqlite.org/faq.html#q3

"This is a feature, not a bug. SQLite does not enforce data type
constraints."

http://www.sqlite.org/omitted.html

"FOREIGN KEY constraints are parsed but are not enforced."

No me hace falta leer mas. :)

Busca algo mas serio. En menos de nada se te complica
el problema y estás dedicando tu valioso tiempo a programmar
'features' que solo habría que declararlas en otro producto.

Sugerencia: Interbase. (aunque no lo conozco bien)

Saludos,
carlos
Respuesta Responder a este mensaje
#15 Carlos M. Calvelo
28/10/2007 - 16:50 | Informe spam
On 28 okt, 14:59, "Pablo Roca" wrote:
> ¿En serio no ves la enorme falacia de tu argumento?

Pues no claro que no. No sé donde la ves.

> Ahora son un completo anacronismo.

Para sistemas pequeños y medios, para nada. Diselo a los que llevan la base
de datos de mantenimiento del Eurotunel o al gobierno norteamericano, que lo
utilizan en muchas aplicaciones.




Pues.. inconscientemente, debe ser una costrumbre tuya hacer uso
de falacias porque aquí estás defendiendo la anterior con otra nueva.

Saludos,
Carlos
Respuesta Responder a este mensaje
Ads by Google
Help Hacer una preguntaSiguiente AnteriorRespuesta Tengo una respuesta
Search Busqueda sugerida