miércoles, febrero 18, 2009

Otra seta, perdón, libro sobre LINQ

Cuando comparo este libro con una seta (y la seta sale ganando al final) no es sólo por la capacidad de propagación por esporas de los libros sobre LINQ sino, principalmente, por su potencial alucinógeno. Leo un par de páginas y alucino. Luego viene la resaca. Pasa un par de horas y siento el mono de volver a comprobar cuán malo es el libro. Y así, entre risas y risas, me lo he leído. Pero las setas tienen fibra y son buenas para el colon.
Vale, me he pasado. Si a usted le cuesta leer en pantalla, este libro puede sustituir a la ayuda en línea, siempre que renuncie al índice, a las búsquedas y a ese estilo seco de los documentos de Microsoft que tanto gusta a los amantes del dolor. De todos modos, supongo que tengo que justificarme. Ahí va eso...
El principal problema de (joder, qué pedazo de título)... bueno, de este título, es la bisoñez del autor, acompañada de un exceso de entusiasmo, buenrrollismo y grandes dosis de soberbia injustificada. Este es un libro de apenas 380 páginas, con los típicos listados sin abreviar y con un tipo de letra más grande que la del texto. A pesar de todo esto, el autor se permite escribir un ditirambo de cuarenta páginas en honor a los ORM... demostrando de paso que no tiene ni pajolera idea del asunto. Ahí va un sabroso "tip" (página 5):
Note: Writing stored procedures does not equate to bad design. On the contrary, stored procedures if managed correctly are an excellent alternative to dynamic SQL. If you use a code generator to create your CRUD stored procedures, or if you develop them by hand and have good oversight, in many cases you will be able to use them in conjunction with an ORM tool.
¡Gracias, gran Vijay (así se llama el pavo), por perdonar nuestras viles existencias! Pero siento interrumpir: usted, ¿ha entendido algo? ¿Son buenos o no los procedimientos almacenados? ¿Sólo si se escriben a mano, o si los crea una herramienta? Ah, ¿en ambos casos? Entonces, ¿para qué mencionar que mañana lloverá o no? El problema está en que el Gran Vijay "sabe" que los procedimientos almacenados sólo son buenos si sirven a los propósitos del Gran ORM. Pero soltar tal chorrada es peligroso. Te puede enemistar con esa bestia cejijunta del DBA (en cristiano, el Administrador de Bases de Datos). Los DBA's, cuando se enfadan, te dejan sin índices secundarios y te echan sal en el café.
"Claro, Marteens, cabronazo, pero nos has ocultado el contexto de la parida". Bien aquí tiene el contexto: el señor Mehta nos explica que la compañía X ha escrito software para un fabricante de comida para perros. ¿Y sabe qué?, pues que usaron procedimientos almacenados. La cosa se les escapa de las manos (claro, porque son unos pecadores relacionales). Y de repente, llega la gran oportunidad: pueden vender la aplicación a un fabricante de comida para gatos. Aquí viene la Segunda Parida:
With the increased development costs, Company X won't be making enough money to justify this deal [...] so they hire a consulting company to help reduce their overhead.
Vijay, hermanito, que nunca se te ocurra montar una empresa con los ahorros de papá, que te los vas a fundir. La consultoría, evidentemente, les endiña un ORM a la Compañía X, y según palabrita del niño Vijay, (they) optimize and normalize the company database. Lamento señalar que:
  • Lo de "optimizar y normalizar" suele resultar bastante costoso. Es como empezar de cero. Para que resulte viable, es obligatorio que la consultoría subcontrate programadores en algún país remoto del Tercer Mundo. Quizás los tiros vayan por ahí.
  • Ah, de repente la base de datos carece de "normalización". ¿Esa es una consecuencia de utilizar procedimientos almacenados?
Pero la diversión continúa:
Company X is able to eliminate the thousands of stored procedures (que ya funcionaban) and instead use "automagic" mapping features to generate its SQL. Development costs go down, profits go up and everyone is happy [...]
... especialmente el niño Vijay, que ya tiene el ejemplo canónico que siempre se escribe en los primeros capítulos. Menos mal que enseguida nos aclara que "this is an oversimplified example". Menos mal. Porque cuando la magia entra por la puerta, la inteligencia salta corriendo por la ventana.
Vale, reconozco que los escritores solemos rellenar los primeros capítulos con la misma alegría con la que los chinos echaban melamina en la leche para bebés. El problema es que los problemas continúan a lo largo del libro... excepto en las páginas que contienen información irrelevante, o en las que se limitan a tirar de la ayuda. Para no hacer esta masacre demasiado larga, aquí tiene un botón de muestra, sumamente divertido y revelador. El hermanito Vijay intenta explicarnos por qué prefiere no usar var para declarar variables locales con tipo implícito (p. 149):
The reason to be explicit with the types is the same reason that you strongly type variables in the world of software development: to make it easier to understand and gain a negligible performance increase.
Heeeelp meeee!Las negritas son mías, por supuesto: resulta que este señor no comprende un sencillísimo truco del lenguaje en que programa, y sin embargo, le recomienda pasar a un sistema que exige un conocimiento en profundidad de ese mismo lenguaje y de su modelo de objetos.
Claro, que si usted se siente molesto conmigo puede dar ejemplo de solidaridad y comprarse el engendro. Pero recuerde que, cada vez que alguien compra un libro malo, el Diablo aparece y mata un cachorrito.

La verdad es que me extrañó un poco el ejemplo de la comida para perros. Pero luego recordé que son los musulmanes quienes consideran que el perro es un animal impuro. Los hindúes, en realidad... bueno, no recuerdo si los consideran seres divinos o si se los comen.
Hat tip to Alfredo Novoa: se casan con ellos.

Etiquetas: , , , ,

146 Comments:

Blogger Tito said...

...
{
var Vijay = "Ouch that hurts!";

//Gracias Ian siempre te robas el show
}

miércoles, febrero 18, 2009 5:01:00 a. m.  
Blogger Ian Marteens said...

:) Es que el libro me costó su dinerillo... Además, a partir de la mitad del libro, los textos de las capturas de pantalla son ilegibles (aparecen muy pixelados). Claro, eso ya no es culpa del autor, sino de la editorial.

miércoles, febrero 18, 2009 10:14:00 a. m.  
Blogger Alfredo Novoa said...

Para evitar tirar el dinero están muy bien las "copias de evaluación" que dejan en el Emule :-)

A mi me han salvado de unos cuantos chascos.

Los de Apress son un peligro. Lo mismo publican un libro bueno que un truño. Pero con ese título ya no se podía esperar nada bueno.

La verdad es que me extrañó un poco el ejemplo de la comida para perros. Pero luego recordé que son los musulmanes quienes consideran que el perro es un animal impuro. Los hindúes, en realidad... bueno, no recuerdo si los consideran seres divinos o si se los comen.

Se casan con ellos :-)

miércoles, febrero 18, 2009 12:50:00 p. m.  
Blogger Barullo said...

¿Me perdí algo o no nombraste el libro?

De todas formas, me causó mucha gracia eso de que la consultora te resuelve los problemas. Lo que yo veo hacer a las consultoras, casi siempre, es hacer gastar montañas de dinero en resolver cosas que tienen defectos por no haber invertido en su momento algo de dinero.

miércoles, febrero 18, 2009 1:02:00 p. m.  
Blogger Ian Marteens said...

Se casan con ellos

¡Jo, cómo está el patio! Actualizo el post dentro de un rato.

La verdad es que me recuerda una escena con Homer y Apu. Homer intenta darle un cacahuete a la estatua de Ganesh que Apu tiene en el Kwik-e-mart. Apu se cabrea por la blasfemia, y Homer le responde:

- Apu, majete, se ve que cuando repartieron las religiones, tú habías salido a hacer pis.

miércoles, febrero 18, 2009 1:05:00 p. m.  
Blogger Barullo said...

Ahora me explico todo:
"Currently working as an Architect for a financial services software company in Indianapolis, Vijay spends the bulk of his time designing and implementing large, cutting-edge software systems."

Y después buscan a los causantes de la catástrofe financiera mundial...

miércoles, febrero 18, 2009 1:10:00 p. m.  
Blogger Ian Marteens said...

¿Me perdí algo o no nombraste el libro?

Pro LINQ Object Relational Mapping in C# 2008. ¡Puse incluso un enlace en el artículo!

me causó mucha gracia eso de que la consultora te resuelve los problemas

Esa parte fue la que terminó de cabrearme. Empecé a leerlo y, magia de la letra impresa, incluso me pareció razonable lo que decía. Volví a leerlo, porque algo me decía que aquello no cuadraba, y vi entonces que se trataba de un disparate de pies a cabeza. Así es como se forman las opiniones...

Esta semana, para rematar, he tenido un fuerte enfrentamiento con un presunto analista partidario de las claves primarias "semánticas", compuestas y que violan, de ser posible, la Primera Forma Normal (concatenando valores atómicos). Todo eso a la vez. Ah, y de los que consideran las claves externas como una concesión a estos confusos tiempos "modelnos". Los razonamientos del pobre Vijay me recordaron a los de este señor ("esto es así porque todo el mundo sabe que es así"), e hicieron de detonante.

Por supuesto que yo tampoco me he explicado... en el artículo: pero es que se trata de un artículo, no de un libro.

miércoles, febrero 18, 2009 1:13:00 p. m.  
Blogger Ian Marteens said...

cutting-edge software systems

:) Cutting-edge and pushing the envelope. Como cantaban los Beatles, sont des mots qui vont très bien ensemble.

miércoles, febrero 18, 2009 1:16:00 p. m.  
Blogger Barullo said...

¡Puse incluso un enlace en el artículo!

¿Me lo juras o le tengo que creer a mi tecla Tab?

miércoles, febrero 18, 2009 3:20:00 p. m.  
Blogger Ian Marteens said...

Coñe, hay un "peazo" de caja de Amazon justo a la izquierda del primer párrafo. ¿No se ve desde tu máquina? ¿Qué navegador es?

miércoles, febrero 18, 2009 3:40:00 p. m.  
Blogger Ian Marteens said...

Jo, Barullo, tienes buenos blogs en tu perfil. Hay incluso uno de los que sigues que también visito con cierta frecuencia (aunque con otro avatar).

miércoles, febrero 18, 2009 3:56:00 p. m.  
Blogger Alfredo Novoa said...

Me he bajado el libro y efectivamente es una buena porquería.

Lo del las claves primarias semánticas compuestas no se entiende muy bien.

Si consiste en combinar varios atributos en uno entonces es una buena burrada sean o no sean atributos de una clave. Pero no viola la 1ª FN por que es imposible violarla con SQL. Para eso habría que usar algo como el viejo PICK.

"Valor atómico" es un término ambiguo que no sirve para definir nada.

miércoles, febrero 18, 2009 4:34:00 p. m.  
Blogger Ian Marteens said...

Pero no viola la 1ª FN por que es imposible violarla con SQL.

Piensa en algo disparatadamente imposible, y siempre habrá un currito que lo logre.

¿Qué te parece meter un número serial más la fecha de entrada en un mismo campo... concatenados? ¿Y luego plantear consultas que extraigan trocitos de ese zurullo?

Lo del las claves primarias semánticas compuestas

Me burlaba. Lo de "clave semántica" es un invento mío para decir que no se trata de una clave artificial (y, por lo tanto, es altamente probable que sea modificable, y que te fastidie la organización de tablas en índices, en Oracle, o una "clustered table" en SQL Server). Que estas claves semánticas (concepto sacado del modelo) sean las claves primarias (concepto del diseño) es una de las cosas que más odio, por los problemas que dan. Si además, esas claves son compuestas (número de banco más número de sucursal, por ejemplo), es otra forma de complicar aún más las cosas... y otro motivo adicional para utilizar siempre claves primarias artificiales.

miércoles, febrero 18, 2009 4:41:00 p. m.  
Blogger Alfredo Novoa said...

Piensa en algo disparatadamente imposible, y siempre habrá un currito que lo logre.

Es imposible por definición. Aunque ahora que lo pienso creo que si se puede con las extensiones de objetos de SQL 1999 y 2003 :-(

¿Qué te parece meter un número serial más la fecha de entrada en un mismo campo...

Una burrada de las gordas.

Lo de "clave semántica" es un invento mío para decir que no se trata de una clave artificial

Ya, algo así me imaginaba.

(y, por lo tanto, es altamente probable que sea modificable, y que te fastidie la organización de tablas en índices, en Oracle, o una "clustered table" en SQL Server).

Cuando hablas de clave primaria parece que te refieres a un concepto del modelo físico.

Que estas claves semánticas (concepto sacado del modelo) sean las claves primarias (concepto del diseño)

Las claves son un concepto sacado del modelo como tu dices, pero el que unas claves al llamarlas primarias condicionen el orden físico de los datos si que es un aspecto físico, obviamente.

Es uno de los problemas de la mezcla chapucera de niveles que hace SQL.

. y otro motivo adicional para utilizar siempre claves primarias artificiales.

Siempre que las claves artificiales sean invisibles para los usuarios (programadores de aplicaciones incluidos). Si no le estás enseñando tus partes íntimas a quien no tiene que verlas :-)

Y aun así me parece bastante exagerado. Hay muchas claves naturales que no cambian nunca o casi nunca, y si cambiasen y la tabla fuese muy grande pues se arreglaría con la reestructuración periódica o forzada de los índices.

Muchas veces no está justificado el trabajo extra que suponen esas claves físicas artificiales. Sobre todo si las tablas no son muy grandes o no necesitas exprimir hasta el último microsegundo.

Yo las utilizo en ocasiones muy raras (y por supuesto siempre las oculto a los usuarios) por que no trabajo con grandes volúmenes de datos (pocos cientos de megas por base de datos) y lo que me interesa es reducir el tiempo de desarrollo.

miércoles, febrero 18, 2009 5:24:00 p. m.  
Blogger Barullo said...

Ian: disculpa lo del link que no veía. Tengo Firefox, pero el problema debe haber sido que estaba en una empresa que tiene bloqueadas algunas páginas. Ahora lo veo bien grandote.

miércoles, febrero 18, 2009 5:32:00 p. m.  
Blogger Barullo said...

Ah, por cierto, además de la mula hay un sitio la mar de interesante aquí, que busca y baja en segundos todo tipo de libros y música. Como dice Alfredo, sólo para echar una mirada antes de clavarse con el original.

miércoles, febrero 18, 2009 5:40:00 p. m.  
Blogger Ian Marteens said...

Siempre que las claves artificiales sean invisibles para los usuarios (programadores de aplicaciones incluidos).

Exacto.

Muchas veces no está justificado el trabajo extra que suponen esas claves físicas artificiales.

Es que a continuación mencionas otro motivo para usarlas: eficiencia. No es lo mismo crear y usar un índice basado en enteros que uno basado en cadenas: más claves por bloque en un b-tree implica más velocidad de acceso.

De todos modos, el enfrentamiento se produjo por querer utilizar nombres de usuarios como claves primarias.

miércoles, febrero 18, 2009 5:41:00 p. m.  
Blogger REDMAN- said...

Las claves artificiales simplifican el desarrollo y ahorran espacio.

miércoles, febrero 18, 2009 5:47:00 p. m.  
Blogger Alfredo Novoa said...

Es que a continuación mencionas otro motivo para usarlas: eficiencia. No es lo mismo crear y usar un índice basado en enteros que uno basado en cadenas: más claves por bloque en un b-tree implica más velocidad de acceso.

Ya, pero también había dicho que muchas veces la eficiencia importa bastante poco. Si me tiro 2 horas para hacer que un formulario que abría en 60 milisegundos abra en 40 milisegundos mi gerente me va a llamar idiota.

Además las claves artificiales muchas veces aumentan el número de "joins" que es una de las operaciones que suelen tardar más.

miércoles, febrero 18, 2009 5:47:00 p. m.  
Blogger Alfredo Novoa said...

Las claves artificales no siempre ahorran espacio. Si tienes una clave natural que es un entero y añades otra clave artificial que es otro entero entonces vas a ocupar más espacio.

Y lo que nunca hacen es simplificar el desarrollo. Lo complican. Aumentan la redundancia y obligan a "cruzar" muchos más datos.

miércoles, febrero 18, 2009 5:51:00 p. m.  
Blogger REDMAN- said...

1.- Ahorro de tiempo de desarrollo
Es más fácil poner WHERE id=1 que WHERE numFactura='10' and numserie = '07' and ejercicio = '09'

2.- Ahorro de espacio físico

Si hago una relación de una tabla con otra en una tabla aparte y la clave primaria tiene varios campos, será mas sencillo poner el IDTabla1,IdTabla2

3.- Eficiencia

Precisamente las JOINS son más rápidas con enteros que con otros tipos de dato.

4.- Estandarización

Puedo hacer procesos genéricos que afecten a tablas dispares si tods ellas tienen una clave ID

Conclusión:
No hay absolutamente ninguna desventaja en crear claves artificiales.

miércoles, febrero 18, 2009 5:56:00 p. m.  
Blogger REDMAN- said...

Lo que Alfredo dice puede ser cierto en un tipo muy concreto de aplicación, pero como norma general creo q es lo que expongo.

miércoles, febrero 18, 2009 5:58:00 p. m.  
Blogger Alfredo Novoa said...

Es más fácil poner WHERE id=1 que WHERE numFactura='10' and numserie = '07' and ejercicio = '09'

¿Y quien sabe que la factura numero 10 de la serie 7 y el ejercicio 9 tiene un "id" que vale 1?

Precisamente las JOINS son más rápidas con enteros que con otros tipos de dato.

Pero un join que no se hace es mucho más rápido :-)

No hay absolutamente ninguna desventaja en crear claves artificiales.

Ya, por eso prácticamente todos los expertos de bases en datos las desaconsejan.

miércoles, febrero 18, 2009 6:05:00 p. m.  
Blogger REDMAN- said...

¿Y quien sabe que la factura numero 10 de la serie 7 y el ejercicio 9 tiene un "id" que vale 1?

-> Es una de las facturas del mes q me toca procesar

Pero un join que no se hace es mucho más rápido :-)

-> De acuerdo

Ya, por eso prácticamente todos los expertos de bases en datos las desaconsejan.

-> Esto me suena a CALGONIT, "los expertos lo aconsejan"
¿Que expertos?
__________________________________

Ahora en serio, puede que lleves razón o no, tengo proyectos muy avanzados que los aprovechan una barbaridad pero que no voy a comentar aquí,porque quiero que sigan siendo mios, evidentemente son proyectos grandes, los pequeños quizá sea muy discutible es cuestión de ser practico lo cual es distinto a ESCALABLE.

miércoles, febrero 18, 2009 6:12:00 p. m.  
Blogger Ian Marteens said...

Si me tiro 2 horas para hacer que un formulario que abría en 60 milisegundos abra en 40 milisegundos mi gerente me va a llamar idiota.

:) pero puede que el cliente final te bendiga. Hombre, por 20 msegs es poco probable, porque es menor que el tiempo de reacción típico humano. Sin embargo, en la aplicación imaginaria de la empresa imaginaria que he estado destripando en estos días, ha habido llanto y crujir de dientes por una puñetera ventanita mal diseñada que se tiraba 300 msegs en mostrarse completamente.

Y 20 msegs no es nada para una ventana... pero para la respuesta de un servidor de capa intermedia pueden ser fundamentales.

De todos modos, reconozco que hay uso y puede haber abuso. Pero el concepto de abuso depende, en estos casos, de lo asimilado que tengas el concepto. Si a mí un señor como tú me discute el uso de claves artificiales, lo entiendo, justifico y puede que termine cediendo... porque sabes qué son y para qué se inventaron, y llevas tropecientos años produciendo resultados. Que me lo discuta un señorito que no tiene ni zorra idea (y que recela de los procedimientos almacenados por "problemas de compatibilidad potencial con otras BBDD" pero se traga un puñado de triggers sin rechistar) es algo que me da la risa floja.

miércoles, febrero 18, 2009 6:27:00 p. m.  
Blogger Ian Marteens said...

Pero el concepto de abuso depende, en estos casos, de lo asimilado que tengas el concepto

... sniff... y esto tendría que explicarlo. Pero me parece que se merece un post.

miércoles, febrero 18, 2009 6:28:00 p. m.  
Blogger Alfredo Novoa said...

Es una de las facturas del mes q me toca procesar

Lo siento pero no lo entiendo.

¿Procesas las facturas una por una usando consultas SQL ad-hoc?

¿Que expertos?

Pues desde Date hasta Celko y también todo quisque en comp.databases.theory

La única justificación para usar claves artificiales (con cuidado) es cuando los SGBD que tenemos son tan cutres que no queda otro remedio que hacer esa ñapa para que las consultas vayan lo suficientemente rápidas.

Con respecto a los índices "cluster", estos se van degradando con el tiempo y hay que rehacerlos de vez en cuando. Si cambias una clave primaria usando un índice cluster lo único que pasa es que el índice se degrada más, pero pasa lo mismo cuando añadimos nuevos datos.

Lo que también hay que tener claro es que una clave que tiene sentido para los usuarios ya no es una clave artificial. Si un tío te llama por teléfono y te dice soy el cliente ZZZ con número 666 entonces el 666 no es una clave artificial, es una clave de "negocio".

miércoles, febrero 18, 2009 6:29:00 p. m.  
Blogger Alfredo Novoa said...

Hombre, por 20 msegs es poco probable, porque es menor que el tiempo de reacción típico humano.

Ya por eso lo pongo. Y además el tiempo de reacción del típico usuario es todavía mucho más alto }:-)

Pero no solo importa el tiempo de reacción sino el porcentaje de mejora.

Por mi experiencia si bajo el tiempo de un proceso largo en un 10% nadie se entera, aunque sean bastantes segundos en total. En cambio si les facturo un 10% más vaya si se enteran :-)

miércoles, febrero 18, 2009 6:39:00 p. m.  
Blogger REDMAN- said...

"Lo siento pero no lo entiendo. "

Me explico mejor yo obtengo por ejemplo los albaranes del mes anterior (por ejemplo) para facturarlos, me refiero a que leo conjuntos de datos no un albarán concreto (con un ejercicio,numero,serie etc) y cuando obtengo ese conjunto traigo el ID de cada cabecera , luego decido que hacer con ese ID ( o lista de IDs) y si tengo que traer datos de líneas o hacer lo que sea mando la orden con el ID.

miércoles, febrero 18, 2009 6:41:00 p. m.  
Blogger REDMAN- said...

Si ese cambio que haces te supone el 10% del trabajo (que además es tu culpa por no hacerlo desde el principio asi), evidentemente que se cabrearán al ver la factra :)

miércoles, febrero 18, 2009 6:44:00 p. m.  
Blogger Alfredo Novoa said...

obtengo por ejemplo los albaranes del mes anterior (por ejemplo) para facturarlos, me refiero a que leo conjuntos de datos no un albarán concreto (con un ejercicio,numero,serie etc)

Estupendo.

y cuando obtengo ese conjunto traigo el ID de cada cabecera , luego decido que hacer con ese ID ( o lista de IDs) y si tengo que traer datos de líneas o hacer lo que sea mando la orden con el ID.

¿Y por que no sigues trabajando con conjuntos de datos?

Yo trabajo con conjuntos de datos todo el tiempo porque así lo aprendí yo :-)

miércoles, febrero 18, 2009 6:46:00 p. m.  
Blogger REDMAN- said...

En lo posible trabajo con conjunto de datos , pero si algo se pone demasiado complicado no merece la pena porque los cambios a largo plazo llevarán demasiados problemas y mi principal preocupación son los cambios.

miércoles, febrero 18, 2009 6:48:00 p. m.  
Blogger Alfredo Novoa said...

En lo posible trabajo con conjunto de datos , pero si algo se pone demasiado complicado no merece la pena

Pues no puedo estar menos de acuerdo. Cuanto más complicado más vale la pena.

Yo tengo mucha experiencia convirtiendo viejo código orientado a registros en código orientado a conjuntos (por que ya no hay quien le meta mano), y cuanto más grande y complejo es el código, mayor es el porcentaje de reducción al convertirlo.

A veces de más de 10 a 1.

miércoles, febrero 18, 2009 6:57:00 p. m.  
Blogger REDMAN- said...

Si el tiempo de proceso es menor por supuesto, pero la escalabilidad disminuye (porque aumenta la complejidad para la mente humana). Te pongo un ejemplo:Cuando haces la facturación mensual que te he comentado antes
Para calcular una factura ( con sus descuentos de cabecera,lineas , impuestos, impuestos especiales, envases, puntos verdes y leches )
¿la haces todas de golpe ?

miércoles, febrero 18, 2009 7:14:00 p. m.  
Blogger Alfredo Novoa said...

pero la escalabilidad disminuye (porque aumenta la complejidad para la mente humana).

Pues a mi me parece justo lo contrario y todos los libros que he leido sobre bases de datos confirman mi opinión.

Es mucho más fácil, más natural y productivo trabajar con conjuntos, lo que pasa es que muchos programadores tienen muy poca práctica trabajando con conjuntos y mucha trabajando con registros y punteros y ven el mundo al revés.

Y yo que a los 6 años estaba todo cabreado por que me parecía que eso de los conjuntos no servía para nada :-). Los punteros no los aprendí hasta 12 años después :-)

Para calcular una factura ( con sus descuentos de cabecera,lineas , impuestos, impuestos especiales, envases, puntos verdes y leches )
¿la haces todas de golpe ?


Pues claro, y también genero los asientos contables de un golpe.

A estas cosas me refería con lo de 10 a 1 :-)

miércoles, febrero 18, 2009 7:27:00 p. m.  
Blogger REDMAN- said...

Si tienes una mente privilegiada bien por ti pero mal por tu empresa, porque el que llegue detrás tendrá un problema!!

miércoles, febrero 18, 2009 7:39:00 p. m.  
Blogger Alfredo Novoa said...

Si tienes una mente privilegiada bien por ti

No es eso. En realidad es más fácil. Solo hay que dedicarle el tiempo suficiente para aprender. Los punteros y los objetos tampoco es que se aprendan en 2 días.

mal por tu empresa, porque el que llegue detrás tendrá un problema!!

Aquí tienes razón, porque es muy difícil encontrar a gente que vaya más allá del select * from tabla where condicion. Por eso existen los ORM esos.

miércoles, febrero 18, 2009 8:17:00 p. m.  
Blogger Freman said...

Si tienes una mente privilegiada bien por ti pero mal por tu empresa, porque el que llegue detrás tendrá un problema!!

... pero ahí coincido con Alfredo: la complejidad no puede ser criterio para excluir una tecnología. Hay empresas que han prohibido el uso de LINQ... ¡porque no todo el mundo lo entiende!

Yo soy un optimista respecto a la mente humana: la veo como un músculo, que mejora cuando se ejercita. Con cuarenta tacos a la espalda me he puesto a estudiar la teoría de las supercuerdas, y la verdad es que no descarto la posibilidad de escribir un libro en algún momento. Me parece incluso un insulto dar por sentado que alguien no podrá entender algo que yo haya programado... dándole el tiempo suficiente y asumiendo un mínimo interés por parte de la persona.

Por eso me permito ser tan crudo en mis críticas. Me gusta que la gente suba a mi nivel, en vez de descender yo al nivel que se presupone a la gente. Esa es, por cierto, otra de mis críticas al librillo de marras: cuando las cosas pueden ponerse interesantes, el autor pasa a otra cosa, bajo el pretexto de que se sale del guión.

miércoles, febrero 18, 2009 8:28:00 p. m.  
Blogger Alfredo Novoa said...

Si tienes una mente privilegiada bien por ti

Si lo dices por aprender teoría de conjuntos elemental a los 6 años, era lo que nos enseñaban a todos en mi colegio, por que hay pocas cosas tán fáciles por donde empezar a enseñar matemáticas.

miércoles, febrero 18, 2009 8:36:00 p. m.  
Blogger Tito said...

No soy muy experto, estoy mal informado o no se cual pero conjuntos de datos (DataSets no), estoy por leer este libro "Expert C# 2008 Business Objects" y no se si voy por mal camino quisiera me orienten

URL LIBRO: http://www.apress.com/book/view/9781430210191

Gracias de anticipadas

miércoles, febrero 18, 2009 10:00:00 p. m.  
Blogger Al González said...

¡Hola Ian! Y saludos a todos los demás también.

Primero que nada, sobre ese libro que compraste y tuviste el valor de devorar, con los párrafos que has citado parece haber sido escrito por alguien que desea vender una tecnología (o que le han pagado para intentar venderla) más que por alguien interesado en difundir un conocimiento útil de forma objetiva.

Por otra parte, debo confesar que me sorprendió el comentario de Alfredo en defensa del uso de campos semánticos (o que representan algo para el usuario) como llaves primarias. El argumento de que “prácticamente todos los expertos de bases en datos las desaconsejan”, en relación a las llaves internas de unicidad (o “artificiales”) me dejó realmente pasmado.

Se habla de espacio de almacenamiento, de velocidad de ejecución y de ahorrar código SQL. Muchos comenzamos usando campos visibles llamados “Clave” o “Numero” como llaves primarias, y, pasados algunos años, terminamos dando a cada tabla un campo llamado “ID” que el usuario no ve en pantalla. Y en este cambio argumentamos motivos de almacenamiento, normalización y velocidad que la Informática terminó dando por concebidos y aceptados. Pero no sé de nadie que, habiendo alcanzado este punto, “involucionara” y volviera a crear de forma regular llaves primarias con campos como “Clave” o “Numero” para sus tablas.

Esto, y la poca experiencia de unos cuantos años, me llevan a concluir que el uso de un ID en lugar del campo Numero, como llave primaria, es por lo general más eficiente y menos costoso en términos de desempeño y mantenimiento de las aplicaciones. Hasta antes de leer el comentario de Alfredo hubiese jurado que los conocedores de bases de datos recomendarían el uso de ID como regla general y Numero sólo en especiales excepciones. Pero en caso de ser verdad que dicha regla, que yo daba por “general”, es algo ampliamente “desaconsejado”, tendré que cuestionarme algunas cosas respecto a lo que el mundo considera un “experto en bases de datos”. :|

Un abrazo único.

Al González. :)

jueves, febrero 19, 2009 8:46:00 a. m.  
Blogger Alfredo Novoa said...

estoy por leer este libro "Expert C# 2008 Business Objects" y no se si voy por mal camino quisiera me orienten

Pues lo bajé hace tiempo y lo recuerdo como malísimo. El típico libro que te enseña como desaprovechar casi toda la potencia de una base de datos procesando los datos de registro en registro desde las aplicaciones.

jueves, febrero 19, 2009 10:49:00 a. m.  
Blogger Alfredo Novoa said...

El argumento de que “prácticamente todos los expertos de bases en datos las desaconsejan”, en relación a las llaves internas de unicidad (o “artificiales”) me dejó realmente pasmado.

Hombre, las desaconsejan como regla general, pero hay algunos casos en los que están justificadas por las limitaciones de la tecnología actual.

Pero no sé de nadie que, habiendo alcanzado este punto, “involucionara” y volviera a crear de forma regular llaves primarias con campos como “Clave” o “Numero” para sus tablas.

Yo mismo, y mucha más gente. Es un tema de los más discutidos en los foros de bases de datos.

En inglés se llaman "surrogate keys". Si buscas encontrarás montones de discusiones sobre el tema.

Por ejemplo otra de las desventajas es que tienes que aumentar el número de índices únicos, por que al crear una clave artificial las claves naturales siguen estando allí. Y eso supone más espacio ocupado y más tiempo de inserción y borrado de registros.

Algunos de los casos en los que suele haber más razones para una clave artificial son los que comentaba REDMAN de cuando la clave natural tiene muchos atributos.

Pero en los casos en los que ya tienes una clave numérica natural lo veo bastante difícil de justificar.

jueves, febrero 19, 2009 11:10:00 a. m.  
Blogger REDMAN- said...

Alvaro no estoy radicalmente en contra de ti en todo, evidentemente hacer las cosas bien (aunque sea complicado es lo suyo)pero ojo:

Hace unos años tenía un cliente que sacaba un listado de comisiones en base a rendimientos de trabajadores PATATIN PATATAN , tardaba 8 horas y con un proc.almacenado a base de trabajar con conjuntos lo dejé en 8 min. Te dejo a ti el cálculo de rendimiento que gané (seguro que mas de 10 a 1).
Este procedimiento almacenado se quedó bastante complejo, incluso para mi que lo hice, no digo yo que no hay niños de 6 años que no pueden con él pero lo dudo.
¿Quiere decir con esto que quedó amortizado el trabajo y el mantenimiento futuro?
Pues depende de muchos factores:
-Se lanza una vez al MES.
-Depende de las modificaciones q sufra
-Si falla algo le cortan el cuello al encargado!!

jueves, febrero 19, 2009 1:12:00 p. m.  
Blogger Alfredo Novoa said...

tardaba 8 horas y con un proc.almacenado a base de trabajar con conjuntos lo dejé en 8 min. Te dejo a ti el cálculo de rendimiento que gané (seguro que mas de 10 a 1).

60 a 1 :-)

Yo me refería a 10 a 1 en cantidad de código y tiempo de desarrollo, no en tiempo de ejecución, pero eso que dices también suele pasar :-)

Este procedimiento almacenado se quedó bastante complejo, incluso para mi que lo hice, no digo yo que no hay niños de 6 años que no pueden con él pero lo dudo.

Pues haberlo dejado más simple y documentado.

Yo heredé un enlace a contabilidad programado en Delphi y Dbase con muchos miles de líneas de código, y era completamente incomprensible. Cada vez que tocábamos una cosa rompíamos otra. Ahora es un procedimiento almacenado y hasta es capaz de actualizarlo el gerente que es el que sabe de contabilidad (según que cambios).

La diferencia de velocidad ni la he contado porque me la refanfinfla :-)

Si me dices que mucho código de bajo nivel es más fácil de mantener que poco código de alto nivel, pues me parece bastante raro.

jueves, febrero 19, 2009 1:32:00 p. m.  
Blogger REDMAN- said...

Me parece bien tu planteamiento, porque lo q pretende es hacer las cosas bien y documentadas y ahí no te puedo quitar la razón.

jueves, febrero 19, 2009 2:02:00 p. m.  
Blogger Alfredo Novoa said...

Hombre, es que los conjuntos tampoco son mágicos. Las operaciones de conjuntos son mucho más potentes y reducen mucho la cantidad de código, pero queda un código mucho más "denso", por lo que el porcentaje de líneas de comentarios también debe de aumentar mucho.

Si unas pocas líneas hacen muchas cosas pues hay que describir esas muchas cosas :-)

jueves, febrero 19, 2009 2:13:00 p. m.  
Blogger Tito said...

Despues de todo lo expuesto aqui y yo que soy solo un novato y vago estudiante sobre programacion quedo muy confundido que son todas unas cosas que recomiendan, no se si recomiendan sea el termino adecuado o muestran y venden en cierto modo www.codeplex.com, www.codeproject.com, www.dce2005.com, etc... que hay sobre MVC, EntLib para que es que sirven todas estas tecnologias frameworks... en el DCE estan mal informando a uno o que por favor recomiendenme algo bueno para ser productivo, desarrollar aplicaciones facil de mantener, escalables ...etc (ademas de los cursos de intsight, que claro con lo que gano no alcanza para pagar dichos cursos)

Agradezco toda su ayuda

Alfredo gracias por alejarme del libro malo como el Expert C# 2008 Business Objects

jueves, febrero 19, 2009 2:53:00 p. m.  
Blogger Ian Marteens said...

algo bueno para ser productivo

¿Estudiante? Aprende de todo... y luego elige. Si esto fuese astrología, o algo que no pudiese verificarse experimentalmente, la opinión de un veterano pesaría mucho más. Pero aquí es fácil comprobar qué funciona y qué no.

¿Mi recomendación?

- Buen nivel en ADO.NET. Todos los inventos posteriores utilizan, de una manera u otra, montón de código de ADO.NET.
- Buen nivel en SQL Server y Transact SQL. Luego, es bueno que le eches un vistazo a PL-SQL. Todos los demás sistemas se parecen bastante al uno o al otro.
- LINQ es útil, incluso aunque no te gusten demasiado (como a mí) los ORM.
- Ah, y La Cara Oculta de C# 4, cuando salga...

jueves, febrero 19, 2009 4:23:00 p. m.  
Blogger REDMAN- said...

Yo añadiría XML al asunto!

jueves, febrero 19, 2009 6:01:00 p. m.  
Blogger Ian Marteens said...

Yo añadiría XML al asunto!

Preferiblemente, a través de los libros de Dino Esposito. Soy fan del amigo Dino.

Este otro libro es ya un poco viejo:

Microsoft .NET Distributed Applications: Integrating XML Web Services and .NET Remoting (Pro-Developer)

Pero te puede dar una idea global de por dónde van los tiros en .NET. Por desgracia, el autor se ha dedicado, después de éste, a escribir libros como churros. Eso sí: éste es el caso de manual para tirar de copia "no regular".

Y si eres estudiante, please, descarga e imprime el libro de Hejlsberg sobre C# como lenguaje (está en Word, en la web de Microsoft). No es que vayas a aprender muchos trucos prácticos estudiándote a fondo la definición del lenguaje, pero es bueno que te acostumbres a este tipo de especificaciones más o menos formales. Y por supuesto, cualquier pequeña ventaja en el dominio del lenguaje, se nota más adelante.

jueves, febrero 19, 2009 7:33:00 p. m.  
Blogger Alfredo Novoa said...

Yo añadiría XML al asunto!

Pues se me acaba de occurrir buscar XML con Google Trends y me he llevado una pequeña alegría.

Creo que XML es una de las peores plagas que sufre la informática.

jueves, febrero 19, 2009 8:07:00 p. m.  
Blogger Andrés Ortíz said...

Hola Ian

Pues estos libracos amarillo-negro, de verdad son un desfiladero de torpes, que intentan vender el libro a punta de título. Con el apogeo de la cosa SOA, me compré: Service-Oriented Architecture in C# 2005 y Ajax and the .NET 2.0 Platform...del primero ni que hablar, y el segundo me consuela para pensar que no soy botaratas.

Ahora estoy con la cosa Sharepoint, y aprovecho para recomendarles este increible libro, apenas llevo unas cuantas páginas, pero da gusto: Mastering Windows Sharepoint Services. 1K de páginas de puro tip, teoría y ejemplos claros y al grano.

Gracias Ian por tus recomendaciones bibliograficas!!

PD. No pierdas tú tiempo leyendo a esos blasfemos autores, escribe un nuevo libro, y así salga caro mando por el!! Lo que decias antes, un libro más de tú experiencia, un conjuro de arquitectura, buenas prácticas, o que se yo, algo que realmente sirva. Todavía recuerdo la cara oculta de CPPB, lo pongo entre los primeros mejores libros que he leido, aun aveces le hecho un ojo!!

Un abrazo desde Colombia

viernes, febrero 20, 2009 3:18:00 a. m.  
Blogger REDMAN- said...

Explica eso Alfredo!!

viernes, febrero 20, 2009 11:32:00 a. m.  
Blogger Andrés Ortíz said...

Al amigo anti XML, el problema no es la tecnología, es la forma como nos desbocamos por algo, olvidamos lo esencial y luego pagamos caro. Mira el estado actual de los proyectos de software en general, mira las arquitecturas, cada día más complejas, supuestamente tratando de enfocarse en procesos y estrategias organizacionales, TOGAF, ITIL, n mil cosas, que uno ya no sabe ni que hacer... Les recomiendo esto:

http://apsblog.burtongroup.com/2009/01/soa-is-dead-long-live-services.html

Un abrazo y sigan con estos buenos debates!!

lunes, febrero 23, 2009 1:08:00 a. m.  
Blogger Alfredo Novoa said...

Eso está claro. La culpa no la tiene XML sino los que lo usan para lo que no sirve. Y sirve para bien poco.

Top 10 "Why XML Sucks" Articles

Pues si que ha durado poco la moda del SOA. A ver cuantos meses dura la de la nube esa.

Esto es igual que la industria de la moda.

Ahora la penúltima tontería de M$ parece que se llama Oslo. No vale la pena ni molestarse en echarle un vistazo. Total para lo que duran estas cosas.

lunes, febrero 23, 2009 1:29:00 a. m.  
Blogger Ramsees said...

Pues lo bajé hace tiempo y lo recuerdo como malísimo. El típico libro que te enseña como desaprovechar casi toda la potencia de una base de datos procesando los datos de registro en registro desde las aplicaciones.

El libro es malo (yo leì los primeros 4 capítulos pero no por "desaprovechar la potencia de las bases de datos" en DDD (Domain driven developement) el uso de ignorancia de persistencia es lo mejor, asi puedes cambiar de base de datos fácilmente.

El libro es malo por poner lógica de más en la entidad y hacerla demasiado dependiente de CSLA. Es uno de esos frameworks que prometen hacerlo todo por ti pero tienes que al menos machacarte meses en su dominio.

Otro aspecto malo del libro es que es demasiado técnico, mal redactado y con poca fluidez, de repente el autor mezcla unas cosas con otras sin previo aviso o al menos advirtiendo "hablaremos de esto mas adelante".

lunes, febrero 23, 2009 1:42:00 a. m.  
Blogger Alfredo Novoa said...

en DDD (Domain driven developement) el uso de ignorancia de persistencia es lo mejor, asi puedes cambiar de base de datos fácilmente.

Si usas un SGBD ya te puedes olvidar de la persistencia por que todo lo que metas en tablas ya persiste sin hacer nada más.

El problema del DDD ese es que la persistencia automática no es ni el 1% de lo que ofrece un SGBD. Lo que promueve ese tipo de libros es la persistente ignorancia de para que sirve un SGBD además de para la persistencia :)

El libro es malo por poner lógica de más en la entidad

Que es lo mismo que no aprovechar el SGBD para poner la lógica de negocio allí. Que para eso se inventaron.

lunes, febrero 23, 2009 2:02:00 a. m.  
Blogger Ramsees said...

Si usas un SGBD ya te puedes olvidar de la persistencia por que todo lo que metas en tablas ya persiste sin hacer nada más.

Cuestión de gustos, poner lógica en la BD no es agradable a mi gusto, toma por hecho que el almacenamiento va a tener triggers, store procedures, etc. cuando la persistencia puede ser cualquier cosa que no sea un BD relacional.

Pero eso no lo voy a discutir.

Al decir que pone demasiado lógica en la clase digo que inclusive cosas como derechos e usuario, modificación, etc. lo pone en la entidad sin auxiliarse de servicios haciendo la clase demasiado gorda.

lunes, febrero 23, 2009 2:46:00 a. m.  
Blogger Alfredo Novoa said...

Eso es como decir que la velocidad de la luz en el vacío es cuestión de gustos.

lunes, febrero 23, 2009 2:50:00 a. m.  
Blogger Ramsees said...

Eso es como decir que la velocidad de la luz en el vacío es cuestión de gustos.

He discutido el punto de la lógica en triggers y en store procedures con gente que lo ve de manera religiosa y no es nada agradable, y no voy a hacerlo ahora.

lunes, febrero 23, 2009 2:56:00 a. m.  
Blogger Alfredo Novoa said...

Ni la velocidad de la luz en el vacío ni la teoría elemental de bases de datos son cuestiones religiosas.

lunes, febrero 23, 2009 3:02:00 a. m.  
Blogger Ramsees said...

Ni la velocidad de la luz en el vacío ni la teoría elemental de bases de datos son cuestiones religiosas

Era en sentido figurado, ¿No lo captaste?

lunes, febrero 23, 2009 3:37:00 a. m.  
Blogger Ian Marteens said...

toma por hecho que el almacenamiento va a tener triggers, store procedures

Hum, tengo una teoría que hasta ahora me ha funcionado: cuando un cliente no quiere usar una base de datos decente, puede ser por una de dos razones:

1- Porque no quiera gastarse las pelas. ¿Le quedará dinero para pagarme?
2- Por prejuicios ideológicos. ¿Querrá gastarse dinero en un programador?

Todas las bases de datos decentes tienen stored procedures y triggers. MySql es una birria, no una base de datos decente.

lunes, febrero 23, 2009 9:41:00 a. m.  
Blogger Ian Marteens said...

Por otra parte, el principal problema de poner la lógica en clases, del DDD y otras chorradicas martinfowlerescas es que las aplicaciones de BBDD (las de verdad, no los ejemplos para libros) son sistemas en cambio continuo. Es relativamente más fácil (nunca lo es del todo) meter las reglas de negocio en la capa SQL: incluso lo de usar una capa intermedia para ello termina costando el triple, por desgracia.

Y hay varias razones para ello. Cuatro líneas de SQL hacen, por ejemplo, lo mismo o más que cuarenta líneas de código imperativo. Pero también me evitan tener que abrir el melón del código, recompilarlo y redistribuirlo sólo porque la empresa cliente quiere que, cada vez que alguien compre una cuchufleta, se lleve también un disco del Fary, que en gloria esté.

lunes, febrero 23, 2009 9:48:00 a. m.  
Blogger Alfredo Novoa said...

1- Porque no quiera gastarse las pelas. ¿Le quedará dinero para pagarme?

2- Por prejuicios ideológicos. ¿Querrá gastarse dinero en un programador?

Tienes Postgres, Firebird, SQL Server Express, etc.

3- Por pura ignorancia. ¿Me vale la pena trabajar para este tio?

Todas las bases de datos decentes tienen stored procedures y triggers. MySql es una birria, no una base de datos decente.

Y ya no es tanta birria porque hace tiempo que tiene estas cosas.

Y además ya no es que hablen de poder cambiar Oracle por Dbase, es que hablan de poder cambiar Oracle por un archivo XML así por las buenas. Es completamente ridículo.

incluso lo de usar una capa intermedia para ello termina costando el triple, por desgracia.

Depende de como se programen las reglas en la capa intermedia. Si en la capa intermedia puedes usar un lenguaje mejor que SQL pues entonces te costará menos. Lo que pasa es que esto se ha intentado muy pocas veces y es muy difícil hacerlo bien.

lunes, febrero 23, 2009 11:03:00 a. m.  
Blogger Ian Marteens said...

Lo que pasa es que esto se ha intentado muy pocas veces y es muy difícil hacerlo bien.

Inventemos entonces el lenguaje e implementémoslo. Tenemos la tecnología de compilación, y tenemos la experiencia.

(lo digo en serio)

lunes, febrero 23, 2009 12:02:00 p. m.  
Blogger REDMAN- said...

Mi Opinión:

1.- Sobre la capa de negocio en la base de datos o en una DLL:

1A La mayoría de los temas los pondría en una DLL por el tema de que la carga de trabajo no recaiga 100% en el servidor , yo prefiero servidores intermedios de manera que según creza la demanda se puedan ampliar.
1B Además pienso que determinadas operaciones conviene gestionarlas como lo hace nuestro cerebro (q no siempre piensa en conjuuntos) puesto que serán más fáciles las modificaciones.

1C Otro punto importante es la integración con los gestores de fuentes, si programo por ejemplo en c#, al ser ficheros externos será más fácil de gestionar la integración con gestores de fuentes, aunque algunas bases de datos lo permitan de aquella manera otras no.

EVIDENTEMENTE TODO ESTO HACER REFERENCIA A PROYECTOS MEDIOS- GRANDES, PARA HACER CHORRADAS ESTÁ CLARO QUE NO MERECE LA PENA MONTAR ESTRUCTURAS TAN GRANDES SALVO QUE SEA TENGA CLARO QUE EL PROYECTO VA A CRECER.

lunes, febrero 23, 2009 12:10:00 p. m.  
Blogger REDMAN- said...

2.- En cuanto al XML.

2A No me pronuncio en cuanto a que la gente no sepa lo que es, ni usarlo.

2B Me parece un gran avance tecnológico, hasta ahora lo que hacía de intermedio entre aplicaciones dispares eran los ficheros de texto ( las famosas integraciones), el cual requería una documentación muy especifica al respecto. Ahora tenemos el XML (con los datos) y su ESQUEMA (que es la documentación) que no sólo nos permite ESTANDARIZAR la DOCUMENTACIÓN sino además AUTOMATIZAR la lectura de los datos (incluso hacer consultas) y transformar los datos vía herramientas de XML/XSL.

2C Por otro lado también es verdad que no será del todo útil mientras no sea entendido asi por todo el mundo, quizá salga otra cosa antes de que todo el mundo se ponga las pilas con él. Creo que será un importantísimo paso el día que todas las aplicaciones EXPORTEN e IMPORTEN XML (quizá no llegue ese día).

lunes, febrero 23, 2009 12:21:00 p. m.  
Blogger REDMAN- said...

3.- En cuanto al tema del lenguaje de la capa intermedia.

Las cosas que permite SQL no las permite Oracle o las hace de otra forma, el mínimo COMÚN entre algunas de ellas es la especificación SQL de turno, que quiero decir con todo esto, que el problema es de estandarización o especialización en bases de datos concretas no el lenguaje en si.

Otra cosa sería por ejemplo REDEFINIR
Transct/SQL mezclado con C#
pero siempre estaríamos hablando de un lenguje específico para SQLSERVER

lunes, febrero 23, 2009 12:42:00 p. m.  
Blogger Alfredo Novoa said...

Inventemos entonces el lenguaje e implementémoslo. Tenemos la tecnología de compilación, y tenemos la experiencia.

¿Y la financiación? :-)

Hay muchos problemas. Todos los que han intentado hacer servidores intermedios que funcionen con los SGBD actuales han fracasado.

Si te inventas un lenguaje muy bueno y bonito pero al final tienes que traducirlo a PL-SQL o Transact SQL tampoco has ganado mucho para todo el esfuerzo que se necesita, y tampoco vas a ganar mucho rendimiento. Lo se por que lo he hecho.

Haría falta una reescritura completa de todo lo que no son las aplicaciones.

Hubo un intento hace unos años de una empresa que se llamaba Required Technologies que parece que fracasó por problemas de patentes.

El padre de Postgres, Michael Stonebraker está metido en otro proyecto pero que solo está dirigido al datawarehousing y con un lenguaje bastante cutre.

Y por supuesto una reescritura completa de las capas de servidor ya son palabras mayores. No es una cosa que puedan hacer uno par de tíos en unos pocos fines de semana :-)

¿Sigues animado después de esto? :-)

lunes, febrero 23, 2009 1:01:00 p. m.  
Blogger Ian Marteens said...

¿Y la financiación?

Suscripción al producto. Eso sí, mientras no haya una versión funcional, es trabajo a fondo perdido. Y en todo caso, se cubrirán costes, a duras penas. C'est la vie.

Técnicamente, estaba pensando en "interceptores", AOP y esas cosas. Claro, habría que comenzar por definir qué es una capa intermedia, y eso no lo veo muy claro. Podría plantearse como una forma de usar el puñetero ADO.NET EF, o incluso ADO.NET a secas.

lunes, febrero 23, 2009 1:25:00 p. m.  
Blogger REDMAN- said...

¿No se puede hacer todo esto como ADDINS( o algo asi) para C#?

-> Por ejemplo un OBJETO -BASE DE DATOS SQL SERVER-
que al refrescarlo obtenga todos los objetos de la base
de datos representados como una CLASE C#
ejemplo:

MiObjetoBd.ProcedmientoAlmacenado1.Init();
MiObjetoBd.ProcedmientoAlmacenado1.p1 = "valor1";
MiObjetoBd.ProcedmientoAlmacenado1.p2 = 2;
MiObjetoBd.ProcedmientoAlmacenado1.Exec();

MiObjetoBd.Salida.Tables[0].campoDelConjunto1
MiObjetoBd.Salida.Tables[1].campoDelConjunto2

lunes, febrero 23, 2009 1:57:00 p. m.  
Blogger REDMAN- said...

Mejor dicho:

SalidaProcedimientoAlmacenado1 = MiObjetoBd.ProcedmientoAlmacenado1.Exec();

y luego

SalidaProcedimientoAlmacenado1.Tables[0].campoDelConjunto1
SalidaProcedimientoAlmacenado1.Tables[1].campoDelConjunto2

lunes, febrero 23, 2009 2:00:00 p. m.  
Blogger REDMAN- said...

De esta manera acercamos ambas capas y no tenemos que inventar nada nuevo!

lunes, febrero 23, 2009 2:01:00 p. m.  
Blogger Alfredo Novoa said...

Eso sí, mientras no haya una versión funcional, es trabajo a fondo perdido.

Ahí está el problema.

Y en todo caso, se cubrirán costes, a duras penas.

En esto no estoy de acuerdo :-)

Claro, habría que comenzar por definir qué es una capa intermedia, y eso no lo veo muy claro.

Yo sí. Una capa intermedia es un SGBD virtual o la capa externa de un SGBD distribuido.

Y ADO.NET se parece a lo que digo como el tocino a la velocidad :-)

lunes, febrero 23, 2009 2:07:00 p. m.  
Blogger Alfredo Novoa said...

Redman, eso que dices es casi igual a ADO.NET

lunes, febrero 23, 2009 2:20:00 p. m.  
Blogger REDMAN- said...

Sí claro, pero es una clase c# y la base de datos está traducida a los tipos del framework.
(usando ado.net)

lunes, febrero 23, 2009 3:56:00 p. m.  
Blogger Ramsees said...

Cuando dije que la fuente de datos no necesariamente es una base de datos relacional no me refiero exclusivamente a archivos XML, inclusive se pueden otros servicios, al decir GrabaEntidad(MiEntidad) a la capa de persistencia esta se va a hacer bolas solas, ya sabra si la persiste en la clasica BD, XML o inclusive y lo mas valuoso para mi, invoca otro servicio en la nube, mi lógica de negocios ni se enteró ni le interesa y por lo tanto no se harán mas modificaciones en esa capa.

lunes, febrero 23, 2009 4:00:00 p. m.  
Blogger Alfredo Novoa said...

Redman, dices unas cosas muy raras sobre XML.

Antes teníamos archivos de texto con su esquema (como los archivos de texto del BDE) y ahora seguimos teniendo archivos de texto XML con su esquema, pero más difíciles de leer, más complicados y menos eficientes. No hemos ganado nada.

Te recomiendo el enlace que puse.

lunes, febrero 23, 2009 4:02:00 p. m.  
Blogger Alfredo Novoa said...

Redman, sigo sin ver la diferencia con ADO.NET, aunque ahora estábamos hablando de la capa intermedia que no tiene que ver con esto.

Pero ya puestos yo prefiero algo como:

grid.DataSource = a join b order (c)

lunes, febrero 23, 2009 4:09:00 p. m.  
Blogger Alfredo Novoa said...

Y por supuesto pasar de 2 a 3 o más capas simplemente cambiando la configuración.

lunes, febrero 23, 2009 4:14:00 p. m.  
Blogger REDMAN- said...

Yo hablo de un interface para acercar sql server a c# ( o sea de utilizar sql para lógica de negocio si interesa) y tu de juntar todas las capas en la de presentación, pero eso ya fracasó hace tiempo

lunes, febrero 23, 2009 4:37:00 p. m.  
Blogger Alfredo Novoa said...

la capa intermedia que no tiene que ver con esto.

Bueno, claro que tiene que ver, porque las aplicaciones se tienen que comunicar con la capa intermedia.

Redman, creo que no has entendido nada. De lo que hablo es de que las capas sean transparentes para las aplicaciones. Las aplicaciones se deben de hacer exactamente igual sean de 1 capa, 2 o las que quieras.

Y también hablo de tirar a la basura C# y SQL Server.

Para acercar SQL Server a C# está LINQ, pero LINQ está muy mal hecho, y el único que lo puede hacer mejor es M$ y no lo va a hacer.

lunes, febrero 23, 2009 4:52:00 p. m.  
Blogger REDMAN- said...

Totalmente en desacuerdo!!
Yo utilizo un código muy parecido a lo que escrito arriba (sólo que no lo tengo como un addin sino que es un programa aparte que ejecuto y me genera clases) y me funciona de maravilla, no tiene nada que ver con linq sino con poner la base de datos sql server en linea con C# y consigo abstraerme de ADO.NET y el SQLClient (el cual utilizan las clases por dentro)

lunes, febrero 23, 2009 4:58:00 p. m.  
Blogger REDMAN- said...

Lo que está quedando claro aqui es que hay tantas arquitecturas posibles como programadores y programas existen, y nadie se pone de acuerdo con nadie, por eso estamos como estamos!

lunes, febrero 23, 2009 5:02:00 p. m.  
Blogger REDMAN- said...

No se lo q son archivos de texto del BDE, pero desde luego no son un estandar con lo cual nadie puede pretender que esa sea la salvación.

lunes, febrero 23, 2009 5:05:00 p. m.  
Blogger Alfredo Novoa said...

MiObjetoBd.ProcedmientoAlmacenado1.Init();
MiObjetoBd.ProcedmientoAlmacenado1.p1 = "valor1";
MiObjetoBd.ProcedmientoAlmacenado1.p2 = 2;
MiObjetoBd.ProcedmientoAlmacenado1.Exec();


En lugar de esto yo ahora hago esto:

db.Execute("Procedmiento1('valor', 2)");

Pero quiero poder hacer:

Procedmiento1("valor", 2);

lunes, febrero 23, 2009 5:07:00 p. m.  
Blogger Alfredo Novoa said...

Y cada formato XML es de su padre y de su madre.

lunes, febrero 23, 2009 5:15:00 p. m.  
Blogger REDMAN- said...

Pero existe su esquema. Y no te digo que no sea lo mismo (que un esquema de un fichero BDE), te digo que con XML se ha dado el paso de que sea un estandar y no me parece mal seguirlo. Esto substituye a los ficheros del bde , a los txt, y algún día puede ser que a EDI etc,etc

Si ahora mismo tengo que hacer algo para hacienda o una remesa bancaria , me tienen que pasar unos documentos , imprimirlos y seguirlos al dedillo y utilizar un programa suministrado por ellos para comprobar q está todo ok, si me pasaran un un XMLSchema , podría validarmelos yo mismo con una herramienta ESTANDAR DE MANIPULACIÓN XML

lunes, febrero 23, 2009 5:22:00 p. m.  
Blogger Alfredo Novoa said...

Pues con los archivos de texto del BDE ni siquiera tenías que validar nada. Te pasaban el esquema y a los 5 segundos estabas escribiendo datos. Y eso que eran una cosa super cutre.

Está bien que haya un estandar, pero XML no le aporta nada. No hay ningún avance tecnológico sino más bien todo lo contrario.

En donde si hay avances es en la estandarización, aunque sea con malas tecnologías.

Por ejemplo también hay validadores automáticos de JSON y supongo que también de LJS.

lunes, febrero 23, 2009 5:36:00 p. m.  
Blogger REDMAN- said...

Me gusta aprovechar lo que hay

me gusta la seguridad de SQL SERVER es buena y bonita¿ por que hacerme yo otra ?

me gusta el estandar SQL ( evidentemente hay muchas cosas mejorables !!SI ME DEJARAN A MI!! )

me gusta c# y hasta ado.net si me apuras

lo que no me gusta es la manera que los utiliza M$ (entiendo que su tarea ees vender motos pero con tanto cambio radical estamos creando engendros que no se entienden unos con otros) dentro de 20 años si consiguen ponerse de acuerdo tendrán que tirarlo de nuevo todo a la basura y empezar una vez más de CERO

lunes, febrero 23, 2009 5:44:00 p. m.  
Blogger Alfredo Novoa said...

Rehacer la seguridad sola no tiene sentido y además es de las mejores cosas que tiene SQL Server. Pero si que hay muchas razones para rehacer SQL Server.

El estandar SQL es bastante desastre. SQL fue un sucio experimento de laboratorio que nunca pensaron en comercializar hasta que Larry Ellison lo copió y se puso a venderlo.

C# es un lenguaje mediocre y en cada versión lo enguarran más.

De ADO.NET solo se aprovechan los SqlCommand.

Y tienes razón en que lo peor de todo es como utiliza todo esto M$.

lunes, febrero 23, 2009 6:00:00 p. m.  
Blogger REDMAN- said...

¿En q crees tu que hay q apoyarse de cara a los 5 próximos años?

lunes, febrero 23, 2009 6:06:00 p. m.  
Blogger Alfredo Novoa said...

Pues depende de tus circunstancias, por que bueno no hay casi nada.

Lo que se puede hacer es usar lo que hay de la mejor forma posible.

Y para eso hay que saber como deberían de ser las cosas si estuviesen bien hechas, para poder acercarse a eso y rodear los peligros lo mejor posible.

De lo que hay que huir como de la peste es de las guias de M$ y de la gente como Fowler y Lhotka.

lunes, febrero 23, 2009 6:20:00 p. m.  
Blogger Tito said...

En los ultimos dias y tras todo lo aqui expuesto he estado pensando seriamente comprarme el curso a distancia de intsight sobre ADO.NET/C#, pero no estoy seguro de si el momento adecuado sea ahora o cuando este lista la Cara Oculta de C#4, de cualquier modo, como dijo Benjamin Franklin "Vacia tu bolsillo en tu mente, y tu mente llenara tu bolsillo." la cuestion es vaciarlo por este curso realmente lo llenara o depende en que % de mi, del medio, la realidad actual ...etc ¿?

Sobre los conflictos y la polemica de Alfredo y REDMAN no hay mucho que decir creo que es un asunto meramente de naturaleza humana cada quien defiende o se enfoca en intereses particulares (aqui en Dominicana alguien diria cada quien jala pa' su lao') sea MS, Oracle, IBM, Borland o como se llame, entre otros, somos por naturaleza humanos EGOistas y mucho mas cuando se trata de asuntos EGOnomicos ...dura realidad.

Saludos desde Republica Dominicana!

PD: Espero no herir ninguna alma sensible, no es lo que intento.

lunes, febrero 23, 2009 8:47:00 p. m.  
Blogger Ian Marteens said...

pero no estoy seguro de si el momento adecuado sea ahora

Escríbeme. Los emails los tienes aquí.

lunes, febrero 23, 2009 9:34:00 p. m.  
Blogger Ian Marteens said...

Rehacer la seguridad sola no tiene sentido y además es de las mejores cosas que tiene SQL Server.

Depende del tamaño de la aplicación. Si quieres conectar 700 usuarios a un mismo servidor, te tienes que saltar la seguridad SQL: o eso, o usar un servicio intermedio "stateless". Un servicio "stateless" debe usar siempre un mismo usuario: si "impersonas", se acabó lo de reutilizar objetos en la capa intermedia.

Una capa intermedia es un SGBD virtual o la capa externa de un SGBD distribuido.

Yo sigo a lo mío. Entonces, ¿algo como SQL para comunicarse con la capa intermedia? ¿Modo texto, o por medio de algo parecido a los árboles de expresiones?

lunes, febrero 23, 2009 9:38:00 p. m.  
Blogger Junior said...

Que bueno que en mi país se están interesendo por comprar cursos como los ofrecidos por intsight por que cada día más hacen falta personas que conozcan las herramientas por lo que hacen y entender como ellas nos pueden ayudar mejor no por lo que ellos dicen y discuten sin realmente conocerlas...

lunes, febrero 23, 2009 10:26:00 p. m.  
Blogger Tito said...

Junior eres Dominicano?

...y si estas en este blog posiblemente tambien programador, bueno de cualquier modo estamos en contacto cualquier cosa este es mi correo bbhorus@gmail.com

lunes, febrero 23, 2009 10:44:00 p. m.  
Blogger Alfredo Novoa said...

Depende del tamaño de la aplicación. Si quieres conectar 700 usuarios a un mismo servidor

¿SQL Server ya cruje con solo 700 conexiones que no hacen nada?

Pues son muy pocas. Los servidores de Emule aguantan millones de conexiones con estado.

Otra de las razones para jubilar a SQL Server es lo poco escalable que es.

Como solución ligera eso se podría arreglar con servidores intermedios que repartiesen la carga y se ocupasen de mantener la sincronización de diferentes servidores de SQL Server.

¿algo como SQL para comunicarse con la capa intermedia?

Lo vas pillando :-)

¿Modo texto, o por medio de algo parecido a los árboles de expresiones?

Yo uso árboles de expresión en un formato binario muy eficiente. En Delphi los mandaba super comprimidos usando un diccionario que se mantenía toda la sesión. Con .Net aun no he tenido tiempo para comprimirlos bien.

lunes, febrero 23, 2009 10:49:00 p. m.  
Blogger Tito said...

Ian ya te escribi, TITO es mi apodo mi nombre es RAMON ARGELYS GARCIA PEREZ debe haberte salido asi en tu correo.

lunes, febrero 23, 2009 10:57:00 p. m.  
Blogger REDMAN- said...

Alfredo yo utilizo la capa intermedia para tomar los datos de la presentación , APLICAR reglas negociando con la capa de datos y finalmente devolviendo un resultado a la capa de presentación.


Para mi la capa intermedia es un WebService (llamalo como quieras) que recibe un conjunto de datos (para mi un DataSet, pero llamalo X ) y devuelve otro conjunto de datos (otro DataSet por ejemplo).

Esto se puede montar con lo que ya hay, al fin y al cabo el problema es definir los conjuntos de datos que utilizan pero eso te lo puedes montar como una especie de DOCUMENTADOR que termine generando una CLASE que a su vez GENERA UN DATASET.

martes, febrero 24, 2009 6:03:00 p. m.  
Blogger REDMAN- said...

la CLASE se genera en base al tipo de Cliente, yo uso .net pero la podría generar para un cliente JAVA y finalmente enviaría el DataSet a mi WS y listo

martes, febrero 24, 2009 6:16:00 p. m.  
Blogger Alfredo Novoa said...

Redman, estamos hablando de cosas totalmente diferentes.

Yo estoy hablando de capas físicas, es decir de máquinas.

Si usas SQL Server y tienes un número de conexiones que un servidor de SQL Server es capaz de aguantar entonces no necesitas ninguna capa intermedia que lo único que va a hacer es complicarte las cosas y hacer que todo vaya más lento.

Si no quieres conectar directamente con SQL Server por supuestas razones de seguridad o para esquivar un cortafuegos pues te montas un tunel y listo. Si quieres acceder al tunel como a un Web Service pues tú mismo.

En cambio si tienes miles de conexiones simultaneas entonces no te queda otra que montar un grupo de servidores de SQL Server y una capa intermedia para coordinarlos y repartir el trabajo.

El conjunto de la capa intermedia y los servidores es lo que se conoce como un Sistema de Gestión de Bases de Datos Distribuido.

Si usas Oracle probablemente no te haga falta hacer nada por que ya tienen soluciones para esto.

La cuestión está en como resolver los problemas de escalabilidad sin afectar a las aplicaciones. La mayoría de las soluciones que hay por ahí hacen que los programadores tengan que trabajar el triple.

martes, febrero 24, 2009 6:39:00 p. m.  
Blogger REDMAN- said...

Tu no hablas de proyectos GRANDES, hablas de MEGAPROYECTOS entonces!

martes, febrero 24, 2009 6:49:00 p. m.  
Blogger Alfredo Novoa said...

Y la otra razón para poner un servidor intermedio es poder utilizar tu producto con diferentes SGBD.

Y la cuestión está en como conseguir esto sin dejar de aprovechar toda la potencia que te ofrecen los SGBD.

Es decir poder usar: consultas complejas, vistas, triggers, procedimientos almacenados, vistas materializadas, el mecanismo de seguridad, etc.

Resolver bien este problema es bastante difícil.

Por cierto, que le acabo de meter una consultita de 1700 líneas a la bírria del SQL Server y mirad que me dice:

El procesador de consultas se quedó sin recursos internos y no pudo producir un plan de consulta. Esto ocurre en raras ocasiones y sólo se espera en consultas extremadamente complejas o consultas que hacen referencia a un número muy grande de tablas o particiones. Simplifique la consulta. Si cree que ha recibido este mensaje por error, póngase en contacto con los servicios de soporte al cliente para obtener más información.
:-(

martes, febrero 24, 2009 6:50:00 p. m.  
Blogger REDMAN- said...

¿quien gestiona 700 conexiones simultanes?
Se me ocurren WEB EXTRAGRANDES
o
La Admin.Pública

martes, febrero 24, 2009 6:51:00 p. m.  
Blogger REDMAN- said...

Lo digo porque el que necesite eso que se pague un ORACLE!

martes, febrero 24, 2009 6:53:00 p. m.  
Blogger REDMAN- said...

Empezamos hablando por LINQ y seguimos por un alguien que está empezando y quiere montarse una arquitectura fiable para programar y ahora estamos hablando de GOOGLE o ALGO ASI

martes, febrero 24, 2009 6:57:00 p. m.  
Blogger Alfredo Novoa said...

Supongo que mucha gente que se empeña en montar cosas con 3 capas realmente no lo necesita, pero tampoco es tan raro necesitar cientos o miles de conexiones.

Además con lo de la moda de tener los datos en "la nube" cada vez va a ser más frecuente.

Imagínate que desarrollas un ERP al que solo se puede acceder por Internet y vendes miles de suscripciones.

martes, febrero 24, 2009 7:42:00 p. m.  
Blogger Ian Marteens said...

¿quien gestiona 700 conexiones simultanes?

Citifinancial España. Aplicación: Lince. Que me perdone mi abuelita. Otra cosa interesante que tiene el sistema: un brutal proceso "overnight" programado en Transact SQL.

Lo digo porque el que necesite eso que se pague un ORACLE!

Es probable que el "light client" aguante un poco más, pero al final se muere igual (lo he visto en otros sistemas).

No hay servidor "stateful" que aguante tantas conexiones. Estoy, además, trabajando ahora con sockets, "a lo bestia"... con los servidores programados en Java, para más gloria. Algunos, los de menos tráfico, aguantan el tirón. Otros se ahogan en cuanto sube la marea. Los IO Completion Ports de Windows y .NET ayudarían, pero es un concepto extraño en Java, que en el mejor de los casos se intenta implementar sin plena conciencia. Naturalmente: hablas del problema con los "expertos" de Java, y te miran como a un marciano. El problema no existe. Punto. Se arreglará con más hardware, en cuanto esté disponible.

Ian ya te escribi

No lo he recibido, e incluso he mirado en el "junk mail" por si las moscas. Te escribo yo a la dirección que has dado.

martes, febrero 24, 2009 10:21:00 p. m.  
Blogger Ian Marteens said...

Imagínate que desarrollas un ERP al que solo se puede acceder por Internet y vendes miles de suscripciones.

A los cursos de Delphi que daba en el 2000-2002, llevaba un portatil y un viejo teléfono con módem (nada de 3G, UMTS ni esas moderneces). Arrancaba una aplicación GUI en mi portátil y hacía que se conectase a un servidor de capa intermedia remoto, de uno de mis clientes. Y empezaba a traer registros a lo bestia.

A veces tenía que apagar el móvil para convencer a la gente de que realmente el acceso estaba teniendo lugar a través del teléfono.

martes, febrero 24, 2009 10:26:00 p. m.  
Blogger Ian Marteens said...

Además con lo de la moda de tener los datos en "la nube"

Hay un detalle "físico", de muy bajo nivel para el gusto del programador medio, que se suele ignorar: la mayoría de los servidores SQL son bastante verbosos. Cuando ejecutas un procedimiento almacenado en Transact SQL, por ejemplo, el servidor envía notificaciones periódicas al cliente del tipo "0 registros actualizados"... cada vez que el procedimiento termina las instrucciones individuales que contiene.

Esas notificaciones, en particular, se pueden apagar con el SET NOCOUNT ON, pero hay muchas otras notificaciones parecidas en danza. Cuando el InterBase se popularizó lo suficiente, la gente intentaba acceder remotamente a servidores InterBase, a través de RDSI e inventos parecidos... y fracasaba, por la terrible lentitud de la técnica. Un servidor de capa intermedia evita la cháchara innecesaria.

Por eso mencionaba el "light client" de Oracle.

martes, febrero 24, 2009 10:30:00 p. m.  
Blogger Tito said...

Ian no hay problema puedes escribirme a ese email pero te escribi al de ian@marteens.com especificamente

martes, febrero 24, 2009 10:37:00 p. m.  
Blogger Tito said...

Oops! mi nombre completo es algo largo y complejo (RAMON ARGELYS GARCIA PEREZ) TITO es solo mi apodo!

Espero por ti Ian no se si revisaste ambos correos, los que tienes en el area de contacto de intsight

martes, febrero 24, 2009 10:44:00 p. m.  
Blogger Alfredo Novoa said...

Con lo de Oracle me refería a las bases de datos distribuidas para repartir las conexiones entre diferentes servidores.

Yo también usaba un servidor intermedios con Delphi e Interbase por esa época y también funcionaba muy bien con un modem por la eficiencia del formato de intercambio y por la compresión con un diccionario que duraba toda la sesión.

Aunque me arrepentí de usar conexiones "stataless" con TCP/IP porque la latencia en red local era bastante más alta de lo que me hubiese gustado.

Una capa intermedia que solo hace de tunel es bastante sencilla de programar y con eso solucionas bastante fácilmente los problemas de "verbosidad".

Por cierto, una cosa para la que sí que me animaría enseguida para colaborar y compartir es un servidor TCP/IP multihilo muy eficiente y muy básico en C# para que cada uno lo use para lo que le de la gana. He buscado bastante por ahí y nunca he encontrado nada interesante.

Yo tengo algo a medio hacer, pero ahora en el trabajo tengo otras prioridades.

Por cierto Ian ¿Para las conexiones "stateless" usas UDP?

martes, febrero 24, 2009 11:19:00 p. m.  
Blogger Ian Marteens said...

Lo propuse a mi actual cliente (imaginario, se entiende). Me echó tremenda bronca (porque no se les había ocurrido a ellos). Seguro que, cuando termine mi contrato, o seis meses después, a alguno de los jefes se le ocurrirá milagrosamente la idea.

servidor TCP/IP multihilo

Piece of cake.

miércoles, febrero 25, 2009 12:13:00 a. m.  
Blogger Alfredo Novoa said...

Lo siento, no me quedó muy claro lo que les propusiste ni lo que quieres decir del servidor TCP/IP multihilo

miércoles, febrero 25, 2009 12:24:00 a. m.  
Blogger Ian Marteens said...

Les propuse un sistema de notificación vía UDP. Stateless, por supuesto.

"Piece of cake" informalmente significa "está chupado" (parece una frase de la Lewinsky). Quiero decir, que me parece buena idea. El código sería muy simple: el truco es dejar que el thread pool haga su trabajo. El sistema de IO Completion Ports viene incorporado en el sistema del thread pool y la E/S asíncrona de los sockets. Donde la veo la oportunidad de hacer algo útil es en el poner a prueba la teoría en circunstancias más o menos reales. Podría pedirle una IP fija a Ono (y montar una DMZ en mi router: DMZ = Zona Desmilitarizada, es decir, un puerto IP con acceso libre desde el exterior), para hacer pruebas de carga con voluntarios.

miércoles, febrero 25, 2009 1:13:00 a. m.  
Blogger REDMAN- said...

En cuanto al ERP por internet si tienes miles de clientes pon 3 servidores.

En cuanto a la aplicación LINCE, ese si puede pagarse una buena programación a medida y salirse de los estandar.

Creo que sería más bonito pensar en una aplicación para 3 a 100 usuarios que en mi PUEBLO ya está muy bien!

miércoles, febrero 25, 2009 9:48:00 a. m.  
Blogger Alfredo Novoa said...

Quiero decir, que me parece buena idea. El código sería muy simple: el truco es dejar que el thread pool haga su trabajo. El sistema de IO Completion Ports viene incorporado en el sistema del thread pool y la E/S asíncrona de los sockets.

Ya, tampoco hay que empezar por lo más difícil :-) y eso es algo que se necesita de todas todas.

Claro que es fácil aunque .Net para esto no es muy bueno y hasta el SP1 del .NET 2 iba de pena.

Ahora es cosa de seguir el ejemplo de SocketAsyncEventArgs sin el bug que tiene que hace que casque enseguida.

Y luego hay que añadir compresión y cifrado y todo eso.

Donde la veo la oportunidad de hacer algo útil es en el poner a prueba la teoría en circunstancias más o menos reales.

Sí claro, eso es fundamental.

Podría pedirle una IP fija a Ono (y montar una DMZ en mi router: DMZ = Zona Desmilitarizada, es decir, un puerto IP con acceso libre desde el exterior), para hacer pruebas de carga con voluntarios.

Yo tengo varias IP fijas, pero había pensado en probarlo primero en red local donde se le puede dar mucha más caña. Por que para bombardear el servidor a través de Internet como mucho dispongo de 3 Mbps de subida.

¿Donde puedo subir las fuentes para empezar? :-)

miércoles, febrero 25, 2009 11:05:00 a. m.  
Blogger Alfredo Novoa said...

Redman, con 3 servidores no haces nada, y si pones muchos servidores descoordinados desaprovechas mucha potencia y tampoco te sirve si le vendes muchas suscripciones a un solo cliente.

Para de 3 a 100 clientes pones un servidor gordo y un middleware basado en mensajes y listo. O incluso 2 "tiers" y ya está.

Otra cosa es si necesitas poder cambiar de fabricante SGBD.

miércoles, febrero 25, 2009 11:11:00 a. m.  
Blogger REDMAN- said...

"Redman, con 3 servidores no haces nada, y si pones muchos servidores descoordinados desaprovechas mucha potencia y tampoco te sirve si le vendes muchas suscripciones a un solo cliente."

Tu me has vendido un SERIVODR compartido con 1000 conexiones, si pones 3 servidores serán 300 y pico conexiones por servidor.

¿Un mismo cliente va a abrir 300 conexiones simultáneas a un servidor compartido? Alguien con esa capacidad va a poner sus datos en un SERVIDOR COMPARTIDO, !!Ni LOCO

miércoles, febrero 25, 2009 11:45:00 a. m.  
Blogger REDMAN- said...

Yo no hablo de coordinar esos tres servidores!!

miércoles, febrero 25, 2009 11:46:00 a. m.  
Blogger REDMAN- said...

YO creo que tu realidad es otra completamente distinta y argumentas cosas que son lógicas pero IRREALES

miércoles, febrero 25, 2009 11:47:00 a. m.  
Blogger REDMAN- said...

Vosotros estais hablando de un tema muy concreto para un cliente/s muy GRANDE y listo! Yo nunca he tenido un cliente con nisiquiera 100 conexiones simultáneas!!

miércoles, febrero 25, 2009 11:50:00 a. m.  
Blogger Alfredo Novoa said...

Un mismo cliente va a abrir 300 conexiones simultáneas a un servidor compartido? Alguien con esa capacidad va a poner sus datos en un SERVIDOR COMPARTIDO

Claro que sí.

miércoles, febrero 25, 2009 11:51:00 a. m.  
Blogger Alfredo Novoa said...

También queda el asunto de poder programar la lógica de negocio en algo mejor que PL-SQL y Transact SQL.

Y de poder comunicarte con el SGBD con algo mejor que LINQ

miércoles, febrero 25, 2009 12:14:00 p. m.  
Blogger REDMAN- said...

Vale ese asunto me gusta más.

miércoles, febrero 25, 2009 12:43:00 p. m.  
Blogger REDMAN- said...

Tenemos el SGBD por un lado -SQLSERVER para cosas medianitas y ORACLE para las GORDAS-


Y nuestro lenguaje de toda la vida(o su evolución) por otro, c# por ejemplo.

Ahora mismo tenemos en medio LINQ o ADO.net

Yo propongo un lenguaje intermedio PSEUDO/ADO.NET que se basa en el uso de PROC.ALMACENADOS.
(en un principio por simplificar para SQL SERVER)

Cuando tiene que tomar DATOS del SGBD lo hace por un SP y cuando tiene que guardarlos también.

Lo importante es que la entrada del SP sea un DataSet y la Salida tb.

¿No hace?

miércoles, febrero 25, 2009 12:50:00 p. m.  
Blogger REDMAN- said...

Algo como
CREATE PROCEDURE FiltrarClientes
(
@idDelDataSetEntrada BIGINT
)
{
declare Parametroprovincia varchar(2)

set ParametroProvincia = dbo.Tabla_0_Fila_0_ASINTEGER( @idDelDataSet )

SELECT CODIGO,NOMBRE
FROM CLIENTES
WHERE (PAR1='0') OR PROVINCIA = PAR1
}

miércoles, febrero 25, 2009 12:56:00 p. m.  
Blogger Alfredo Novoa said...

Problemas:

Los procedimientos almacenados como ese no aportan nada.

Mejor hacer algo como:

grid.Datasource :=
with X as Clientes { Codigo, Provincia } :
if Par1 = "0" then X else X where Provincia = Par1;

Y para esto no necesito crear ningún procedimiento almacenado.

2º Si usas Transact SQL olvídate de Oracle :-)

3º Los datasets son una castaña.

miércoles, febrero 25, 2009 1:31:00 p. m.  
Blogger REDMAN- said...

Yo me referia crear una "infraestructura de comunicacion" de c con sql mediante unos objetos fijos en sql ( en oracle sería otro script disitnto y otro interfaz ) pero el mismo código en c.

Tampoco al proc. almacenado concreto q he escrito era LA IDEA:

Tomar datos que me vienen de c procesarlos en (t/sql o pl/sql) y devolverselos a c, TODO ESO SIN tener que poner muchas líneas, otra cosa es que los DataSet sean una castaña ,C tambien y Sql también.

La idea es , tengo unos datos en c , los manipulo en sql y los sigo manipulando en c y para ello no he tenido que crear ningún lenguje nuevo ni nada!

miércoles, febrero 25, 2009 2:02:00 p. m.  
Blogger Alfredo Novoa said...

La idea es , tengo unos datos en c , los manipulo en sql y los sigo manipulando en c y para ello no he tenido que crear ningún lenguje nuevo ni nada!

Ni nada de nada :-)

Para eso usas ADO.NET tal cual está y listo.

miércoles, febrero 25, 2009 2:09:00 p. m.  
Blogger Ninex said...

Hola a Todos:

Impresionado las cantidad de mensajes, cuando ultimamente habia poco movimiento x aca. Veo que hay mucho entusiasmo y pasion defendiendo cada uno sus punto de vista. Celebro esto.
Pero permitanme decirles que, al menos para lso que pretendemos vivir de desarrollar aplicaciones, que echen un vistazo a GENEXUS (www.genexus.com).

No soy vendedor de ello ni mucho menos, solo que entendiendo, desde mi particular punto de vista, que no se puede ya ser un programador a la antigua por los conocimientos que las aplicaciones de hoy en dia requieren y que el modelo de programacion declarativa es el camino (hasta elquerido Bill Gates lo admitio ya), me parece que discutir si claves artificiales o no, no tiene mucho sentido. Esto cuando me parece nuestros esfuerzos deben estar dirigidos en otros sentidos, desarrollando aplicaciones con este tipo de herramientas que perduren a traves de los cambios tecnologicos.
Se que mi comentario generará una andanada de opiniones en contrario, es mas, reconozcono no tener mucha experiencia sobre el mundo Genexus,pero humildemente me permito compartirlo, y de paso escuchar a quienes lo hayan probado o saben de él.

miércoles, febrero 25, 2009 2:23:00 p. m.  
Blogger Alfredo Novoa said...

Me he bajado los manuales de Genexus y parece que no es más que otra reencarnación del arcaico PICK.

Mirad que me he encontrado:

Comando FOR EACH
Este comando es fudamental(sic), ya que es el único comando que permite recuperar información de la base de datos.

Creo que no hay más que añadir :-(

miércoles, febrero 25, 2009 3:31:00 p. m.  
Blogger Alfredo Novoa said...

Con respecto a todo lo demás sobre la programación declarativa que dice Ninex, estoy completamente de acuerdo.

Lo que pasa es que hay que apoyarse en algo más sólido que el vetusto PICK.

miércoles, febrero 25, 2009 4:48:00 p. m.  
Blogger Cesar Guzman said...

Ian, hay fecha de salida para tu proximo libro ?

Yo tengo la fortuna de haber comprado La cara oculta de Delphi 4(aqui en Mexico) y La cara oculta de Delphi 6 y de C# (a traves de tu pagina) y me parecen lo mejor que he leido.

Al igual que Tito estoy con la intencion de adquirir el curso en linea, pero la posible salida de tu libro es algo que me llama mucho la atencion.

jueves, febrero 26, 2009 5:25:00 a. m.  
Blogger Ninex said...

Gracias Alfredo por tu aporte, desconozco que es PICK. De todas maneras eso del comando FOR EACH tampoco entiendo que quieres decir con ello. Tengo entendido que el "lenguaje" de Genexus luego se traduce a .NET, Java o el compilador que desees, por lo que no se como será dicho código.
Lo unico que tengo para aportar es que en mi trabajo estan viendo de comprar un sistema, bastante grande, y los oferentes que se han presentado todos lo tienen desarrollado con esta herramienta.
De ahi mi inquietud por conocer un poco de Genexus y por lo que pude ver en lso videos del encuentro internacional del 2008, les diré que me convencieron bastante que ese es el camino, con Genexus u otro similar, pero por ahi van los tiros como dicen Uds los españoles.
Les dejo un par de enlaces a algunos de esos videos por si les interesan, en la pag estan de casi todas las charlas.
Genexus for Dummies
http://www.genexus.com/portal/hgxpp001.aspx?2,55,945,O,S,0,,1482

Genexus X overview
http://www.genexus.com/portal/hgxpp001.aspx?2,55,945,O,S,0,,1444

Un saludo a todos.

jueves, febrero 26, 2009 3:27:00 p. m.  
Blogger Alfredo Novoa said...

Ninex, PICK era un sistema operativo de los años 60 y 70 que tenía un primitivo sistema de procesamiento de registros del tipo de Genexus.

El problema de que con Genexus solo se puedan recuperar datos con un FOREACH es que es un sistema muy primitivo y obsoleto. Le faltan las operaciones de conjuntos del Modelo Relacional y SQL.

Yo me puse a mirar los manuales y no encontré por ninguna parte todas las cosas que tiene que tener un lenguaje de bases de datos como juntas, proyecciones, extensiones, uniones y diferencias de conjuntos, agregados, etc. Es decir que su lenguaje es muchísimo menos potente que SQL.

Espero que tu empresa no caiga en el error garrafal de apostar por una tecnología que lleva décadas obsoleta.

jueves, febrero 26, 2009 3:51:00 p. m.  
Blogger Ninex said...

Me parece que lo que dices que le falta del modelo relacional y SQL, no lo tiene el lenguaje es porque con dicho lenguaje se "declara" lo que se quiere hacer, luego el compilador que uses, C# para .NET o Java empleara eso que dices que le falta para hacer lo que declaraste con Genexus.
Genexus es un generador de codigo, el codigo Genexus no se ejecuta ni mucho menos interactua con la base de datos. Habria que ver como se traduce ese FOR EACH en los lenguajes finales.

jueves, febrero 26, 2009 4:07:00 p. m.  
Blogger Alfredo Novoa said...

No, todo eso falta de verdad y no te deja "declarar" casi nada. Solo fórmulas sencillas que hacen referencia al mismo registro o a los registros contenidos dentro del registro.

Esto está a años luz por detrás de SQL.

El generador de código no puede hacer milagros. Si estás obligado a crear código procedimental y procesar de registro en registro el código generado por fuerza va a hacer lo mismo.

jueves, febrero 26, 2009 4:15:00 p. m.  
Blogger Tito said...

Ian aun no se si recibiste mi correo de repuesta!!!

viernes, febrero 27, 2009 1:03:00 a. m.  
Blogger Tito said...

Hola Ian!

Espero no ser desesperado ni fastidioso pero me gustaria saber si recibiste mi mail en respuesta al tuyo solo eso.

Gracias a la espera de tu respuesta

sábado, febrero 28, 2009 9:22:00 p. m.  
Blogger Mau said...

Me parece una burla que este tipo de libros salgan al mercado.
Es una mentira vulgar y que confunde mucho al novato.
Excelente tu blog. Saludos.

jueves, septiembre 03, 2009 12:22:00 a. m.  

Publicar un comentario

<< Home