Mr. Butters (I)
Mr. Butters es un "experto" imaginario, que trabaja en una empresa imaginaria, y que "controla mogollón" sobre bases de datos, aunque la única base de datos con la que ha trabajado en su puñetera vida es Oracle 9, utilizando sólo los trucos que aprendió para Oracle 7. Es un tipo que desconfía de las foreign keys, que considera peligrosos los triggers y los procedimientos almacenados, y que prefiere que el acceso a datos se haga con ODBC... sobre todo por compatibilidad, coño, que somos una empresa seria.
Mr. Butters, por supuesto, es sólo un producto de mi febril imaginación. Cualquier coincidencia con la realidad, es un mero resbalón de mis neuronas.
The Waste Brain
Mr. Butters is the silliest dork, breeding
Incompetence out from the dead land, mixing
Idiocy and arrogance, stirring
Foolishness with an amazing lack of common sense.
Visual Basic kept us warm, covering
Bugs in forgetful snow, feeding...
(etc, etc)
Mr. Butters is the silliest dork, breeding
Incompetence out from the dead land, mixing
Idiocy and arrogance, stirring
Foolishness with an amazing lack of common sense.
Visual Basic kept us warm, covering
Bugs in forgetful snow, feeding...
(etc, etc)
Etiquetas: Mr. Butters
Ian Marteens, 6:53 p. m.
47 Comments:
Ian lo siento pero no tengo de otra mas que escribir en el blog.
Mis emails:
mtitos@msn.com
bbhorus@gmail.com
TITO es mi apodo y mi nombre completo es Ramón Argelys García Pérez.
Aun sigo sin saber si recibiste mi correo en respuesta al que me enviaste.
PD: Recientemente te escribi otro. El MR. este como fue que se volvio tan experto ignorando las mejores practicas y las buenas costumbres de las BD, a menos claro que si sea experto pero no en BD ni nada parecido.
Ian yo también lo siento pero estoy en la misma situación que tito. Me quede en espera de tú respuesta para la compra del curso. Te escribí varios correos incluso te llame por teléfono pero no obtuve respuesta. ¿Quisiera saber que paso?
Hola a los dos.
El problema de Tito es que parece que GMail pierde mensajes. El día en que me envío los primeros, hubo un fallo sonado (salió en periódicos) en un centro europeo de GMail. Parece que se ha perdido también uno que te envié el fin de semana. Te lo reenvío dentro de un rato.
Marco Antonio: probablemente se me perdió el mensaje en la bandeja de entrada. Escríbeme, y te hago una buena oferta.
Ian prueba con mi cuenta de MSN
mtitos@msn.com en tal caso mi cuenta de gmail sigue sin recibir comienzo a averiguar si es algun problema de configuracion.
¿Quién puede decir lo que está bien y mal?
Según el caso y el entorno MR.Butters puede hasta tener razón!!
Necesitamos ESTANDARIZAR cosas, OPTIMIZAR puede ser un paso posterior pero primero necesitamos que las distintas herramientas se entindan entre sí, para poder complementarse, sino (LOS PROGRAMADORES) terminaremos quedando como lo que aparentamos (y se demuestra que somos) UNOS RAROS QUE NO SABEMOS COMUNICARNOS CON LOS DEMÁS.
Hay un concepto por el que me guío, en el que parece que nadie piensa: se llama calidad de código. Entiendo que una persona que se pelea con su primera aplicación de BBDDs (o de lo que sea) intente primero que funcione... y luego ya veremos que vaya bien.
Lo que es absurdo es que, una vez que ya conoces lo que va bien y lo que no, te limites en aras de una pretendida "estandarización", que en el 99 por cien de los casos es pura "mindturbation". O que un programador que se supone que lleva desde el 2003 Visual C# programe chapuceramente porque "ya optimizaremos más adelante". Un buen programador, escribe de corrido código decente, igual que un buen programador no tiene que esperar al compilador para escribir código que compile. Eso te lo da la experiencia y el uso de la herramienta.
En el caso (imaginario) de Mr. Butters, por cierto, la "estandarización" se le fue a hacer puñetas por la sencillísima razón de que utilizaba Oracle 9 para el desarrollo... y su cliente ejecutaba Oracle 10. Y de repente empezaron a saltar problemas en el cliente que no se producían en el entorno de desarrollo.
Moraleja: cada decisión que tomamos, nos ata de una manera u otra. Es absurdo mantener una "posible" compatibilidad con SQL Server, si nuestro cliente está casado con Larry Ellison hasta que la muerte o la próxima crisis los separe.
UNOS RAROS QUE NO SABEMOS COMUNICARNOS CON LOS DEMÁS
:) ¿Quiénes son "los demás"? Que yo sepa, el mundo es un producto de mi imaginación...
Usar "foreign keys" cuando hace falta no es ninguna optimización. Y lo mismo con los procedimientos almacenados y los triggers.
A mi no me cabe en la cabeza que alguien pueda desconfiar de las "foreign keys" y confíe en que se van a asegurar esas restricciones en todas las aplicaciones de forma procedimental.
Y es totalmente cierto que la calidad del código es un concepto que apenas se conoce en España, y así nos va. La empresa de software más importante de españa es Panda.
Respecto a triggers y procedimientos almacenados yo lo que suelo ver es todo lo contrario, que se abusa mucho de ellos o se utilizan para construir una interfaz orientada a registros por encima de SQL.
No me he explicado bien, voy a intentar hacerlo mejor:
Cuando digo estandarizar no me refiero a poner código q funcione en todas las Bases de datos (porque para empezar no hay muchas en las que confíe) ni a las Claves Foráneas (que están aceptadísimas por todos).
Pero a partir de ahí YA NO LO TENGO TAN CLARO, no lo veo cuestión de código bueno o malo SINO que sea ENTENDIBLE por alguien más q uno mismo.
Caso concreto : ¿Procedimientos almacenados para todo (incluso cuando se hace algo orientado a registro) ? o SQL DINÁMICO ( como se controla la seguridad con él!!! y definirla de cara a usuarios)
u otro:
UN TRIGGER ¿no se puede implementar mejor como una llamada a un proc.almacenado?, lo digo porque siempre se termina dando el caso QUE ME LO QUIERO SALTAR !!
Ya sé q estais pensando entonces no pongas un trigger, pero es que esto siempre surge después. Por mi experiencia prefiero enfocarlo como un almacenado e invocarlo desde el TRIGGER
¿que pensais?
Personalmente prefiero tener un proc.alamcenado que SUBSTITUYA al INSERT INTO desde el primer momento (aunque sea orientado a un registro) y centralizar ahí el uso como si fuera un OBJETO y no una TABLA y asi centralizo el uso de mis tablas (lanzo "triggers" y hago lo q quiero con mi pelo)
¿Procedimientos almacenados para todo (incluso cuando se hace algo orientado a registro) ?
Una burrada.
SQL DINÁMICO ( como se controla la seguridad con él!!!
Igual que sin él.
UN TRIGGER ¿no se puede implementar mejor como una llamada a un proc.almacenado?
Un trigger es un procedimiento almacenado que es "llamado" automáticamente. Muchísimas veces se puede implementar mejor usando una vista.
lo digo porque siempre se termina dando el caso QUE ME LO QUIERO SALTAR !!
Que cosa más rara. ¿Puedes poner un ejemplo? No me imagino un caso donde pueda pasar esto.
Personalmente prefiero tener un proc.alamcenado que SUBSTITUYA al INSERT INTO desde el primer momento
Yo rara vez hago un INSERT INTO. Para eso están las IBindingList.
y centralizar ahí el uso como si fuera un OBJETO y no una TABLA
Una tabla es un objeto.
"Una burrada."
Será para ti que piensas que lo sabes todo!
"SQL DINÁMICO ( como se controla la seguridad con él!!! -> Igual que sin él."
Pues no, porque no es lo mismo dar permisos a TABLAS y CAMPOS que a procedimientos almacenados.
Dar permisos a tablas y campos yo lo veo ANTI-NATURAL para el usuario (sería igual que dejar
ver los autonúmericos q comentabas tu hace tiempo), el usuario quiere PERMITIR Procesos o Acciones
más que acceder por ejemplo a las 20 tablas que pueden representar 1 cliente.
Está claro q tu trabajas con vistas y está muy bien, pero deja de opinar como si lo supieras todo!
"Muchísimas veces se puede implementar mejor usando una vista."
Ni idea de lo que te refieres pero exponlo para el que trabaje como tú seguro que le interesa!!
"¿Puedes poner un ejemplo?"
Pues en mi empresa se han hecho muchos triggers con muchos propositos y todos me los quiero saltar en momentos
determinados, no me vengas ahora conque no eran adecuados porque entonces habrá que darte la razón como siempre:
1.- Un trigger que crea un histórico de valores -> Cuando quiero hacer un update NO QUIERO QUE SE LANCE y me cree mil históricos.
2.- Cuando inserto datos con procesos especiales -> No quiero que se hagan recálculos que se hacen en ciertos triggers y que tardan un huevo.
"Para eso están las IBindingList."
No tengo ni idea de lo que es eso , pero seguro que soy el único.
"Una tabla es un objeto."
Me refería a representar el proc.almacenado (como una interfaz de un objeto de una clase -PROGRAMCIÓN
ORIENTADA A OBJETOS), con una tabla puede hacerse lo mismo pero puede tener 1.000 peculiaridades relacionadas
con el diseño relacional, que es lo que pretendo enmascarar en el SP. CADA VEZ QUE ENTRA UN REGISTRO ENTRA POR
AHÍ Y TENGO CENTRALIZADO TODO LO QUE QUIERO HACER A NIVEL DE DATOS. Un SP puede meter datos en 20 tablas distintas
y lanzar EVENTOS (como si fueran triggers), si mañana cambio la estructura de datos me AFECTA sólo en esa capa!
;) No os peguéis chicos. La verdad es que las broncas le dan vidilla al blog, pero lo cierto es que, después de ver los disparates de Mr. Butters, me he vuelto mucho más tolerante respecto a las diferencias técnicas.
Será para ti que piensas que lo sabes todo!
Para mí y para cualquiera que entienda mínimamente lo que es una base de datos relacional, y me has dejado muy claro que no es tu caso.
Por cierto, os recuerdo que aquí sí se puede hacer spam (técnico). Yo, en caso de exasperación, suelo desahogarme escribiendo manifiestos. En la mayoría de los casos, es una pérdida de tiempo, pero si os da por ahí, os enlazo desde un post (que es más visible).
Redman, te he añadido al blog roll. Si me falta alguien, que lo diga: ya sabéis que actualizo con no mucha frecuencia.
No salió el enlace.
VALE DE MOMENTO EL CONSENSO DE MÍNIMOS ES:
CLAVES FORÁNEAS-> SI
Y POR OTRO LADO PERSONALMENTE
TRIGGERS -> Sí pero derivándolos a proc. almacenados en lo posible.
SPS-> Si por supuesto, incluso orientados a REGISTRO.
VISTAS-> Salvo vistas PARTICIONADAS (por rendimiento) , NO, pues lo que pueda hacer una vista lo hace también un SP y es más ESCALABLE.
SEGURIDAD-> Muchas de estas decisiones vienen por ahí, la oriento a SPs.
-------- NIVEL DE C#
ADO.NET/DataSets: si principalmente porque desconozco otras tecnologías y la mayoría de COMPONENTES-HERRAMIENTAS-DOCUMENTACIÓN van orientados a ELLOS.
Redman ¿Que libros de teoría de bases de datos has leído?
Lo que dices va completamente en contra del espíritu de las bases de datos relacionales.
Yo me he leido la mayoría y te cuento lo que se deduce de ellos:
Los triggers se deben de usar solo cuando no se pueden usar vistas.
Por ejemplo si tienes una tabla de últimos precios mantenida usando un trigger, entonces borras la tabla y haces una vista que te saque los precios con la mayor fecha.
Con respecto a saltarte los triggers cuando haces cargas de datos masivas, SQL Server tiene opciones para hacer justo eso.
Los SP se deben de usar para encapsular instrucciones de actualización complejas y para consultas de lectura solo en casos muy raros cuando no haya otra forma de hacerlo.
Las vistas se usan muchísimo. Son un recurso completamente fundamental y son la primera opción para muchísimas cosas.
Seguridad. De perogrullo: usar el mecanismo de seguridad del SGBD para dar los permisos adecuados.
He leido bastante y sé para que esta concebida cada cosa, lo que ocurre es que en ningún sitio dan importancia la LEGIBILIDAD DEL CÓDIGO O LA ESCALABILIDAD es más muchas veces TIEMPO DE DESARROLLO, OPTIMIZACIÓN Y ESCALABILIDAD forman parte de un triángulo en el cual una variable va en detrimento de la otra.
La mayoría de veces las consultas que hago son en base a parámetros y a veces son los parámetros quien determinan si un USUARIO puede ver
esos datos o no, por ejemplo:
Supongamos que un Usuario Comercial no puede ver los Clientes asignados a los demás Usuarios Comerciales , si hago una vista "CLIENTES_COMERCIAL" y otorgo permiso a esa vista, si entra al SGBD directamente tendrá permiso físico en la base de datos para verlos TODOS sin embargo si creo un SP CLIENTES_COMERCIAL que internamente coge el CURRENT_USER(o como sea) y obtiene el código de comercial asignado a dicho usuario y filtra por ahí, sólo podrá ver los clientes suyos, incluso aunque conecte irectamente al SGBD,pues su permiso es EJECUTAR UN SP, incluso aunque conecte directamente con el SGBD no tendrá acceso.
¿como harías tu eso?
Pero no es eso sólo, la mayoría de las veces anido proc.almacenados, anidar vistas termina siendo una maraña indescifrable.
Las vistas particiones si que están muy bien porque optimizan las consultas a lo BESTIA y hay cosas que las requieren, pero no como norma general.
En definitiva los procedimientos son más flexibles.
He leido bastante y sé para que esta concebida cada cosa
Lo dudo muchísimo. Dime los títulos de los libros, por favor.
lo que ocurre es que en ningún sitio dan importancia la LEGIBILIDAD DEL CÓDIGO O LA ESCALABILIDAD es más muchas veces TIEMPO DE DESARROLLO, OPTIMIZACIÓN Y ESCALABILIDAD forman parte de un triángulo en el cual una variable va en detrimento de la otra.
Claro que sí que se la dan. Te vuelvo a preguntar que cosas lees, por que lo que dicen los libros de teoría sobre como mejorar la legibilidad y el tiempo de desarrollo es justo lo contrario de lo que dices tú.
Supongamos que un Usuario Comercial no puede ver los Clientes asignados a los demás Usuarios Comerciales
Haces una vista que solo saque los clientes del usuario de la sesión y listo. Trivial. Supongo que tus reticencias vienen de que tienes problemas para escribir consultas no triviales e incluso algunas que son triviales.
Anidar vistas es una forma muy buena y muy eficiente de encapsular. La optimización de la consulta se aplica a la consulta completa y no a los resultados intermedios como ocurre usando procedimientos almacenados.
Las vistas con particiones son una utilización de las vistas como otra cualquiera.
Los SP se deben de usar para encapsular instrucciones de actualización complejas y[...]
Humm, hay un caso importante adicional. Los procedimientos almacenados son la forma más rápida de consultar casi todas las bases de datos que conozco, incluso cuando la alternativa es un simple SELECT. Motivo: precompilación. Es curioso que sea SQL Server, precisamente, quien menos tenga problemas en este sentido, porque tiene un "detector" de consultas paramétricas que permite factorizar planes de ejecución "dinámicos". Pero pásate a Oracle, y cada consultita o actualización generada por la herramienta que sea, tendrá que compilarse por separado en el servidor.
Precisamente, el propio Oracle aconseja que cada trigger se reduzca a una llamada a un procedimiento almacenado, porque el trigger no puede precompilarse (y compartirse entre conexiones), mientras que los procedimientos almacenados sí.
Los procedimientos almacenados son la forma más rápida de consultar casi todas las bases de datos que conozco, incluso cuando la alternativa es un simple SELECT. Motivo: precompilación.
Esto es un mito.
Las consultas se pueden precompilar con la instrucción Prepare.
Con SQL Server y sus "cachés" de consultas no hay diferencias significativas de rendimiento entre las consultas y los procedimientos almacenados.
Puedes encontrar referencias a esto en muchos sitios incluida la propia MSDN. Por ejemplo mira esto:
http://geeks.ms/blogs/quintas/archive/2007/11/13/cach-233-de-planes-de-ejecuci-243-n-en-sql-server-2005-y-comportamiento-de-los-procedimientos-almacenados.aspx
¿Lo que dices de Oracle se aplica a las últimas versiones?
Me extraña un poco que Oracle esté tan por detrás de SQL Server en estos aspectos.
Pero en todo caso estamos hablando de optimizaciones marginales y como dice Knuth: premature optimization is the root of all evil :-)
Y como dice Hoare:
We should forget about small efficiencies, say about 97% of the time
Alfredo quieres títulos de libros, pues ahí va uno, "TU USA VISTAS QUE YO USARÉ SPS" ¿Contento?
Redman, supongo que eso significa que no has leido ninguno que era lo que me imaginaba desde el principio.
Efectivamente me has pillado no he leido ningún libro, todo viene del PRUEBA/ERROR que tampoco es un mal método.
Si quieres creer que una vista es más escalable que un SP tu mismo, ¿que es más óptima? pues dependerá del optimizador que los desoptimice!!
¿más escalable? NARANJAS DE LA CHINA
Por cierto con el ejemplo "TRIVIAL" ese que dices tú, me refería a que las vistas tienen limitaciones, lo que pasa es que yo no me las sé porque no me las he leido y hace siglos que no las utilizo.
todo viene del PRUEBA/ERROR que tampoco es un mal método.
No sabes cuanto te equivocas. Es un método horrible.
No es que quiera creer lo que digo sino que sé de lo que hablo. Y ahora resulta que no tienes ni idea de lo que se puede hacer con una vista.
Por supuesto que no lo sé todo, pero estas cosas tan elementales sí que las conozco muy bien.
Lo del prueba/error era IRÓNICO, pero al final tu me pones ejemplos concretos de escenarios HIPOTÉTICOS y EN EL EJEMPLO CONCRETO NADA COMO EL PRUEBA/ERROR, el largo plazo es otro cantar.
Está claro siempre será más fácil optimizar una vista (que es una única consulta) que un proc.almacenado, precismante porque te deja hacer más cosas. Si Oracle no optimiza las consultas en los SPS, pues es un problema serio, pero tampoco uso otras bases de datos por otras muchas y DIVERSAS RAZONES. Eso por desgracia te lo da a veces el PRUEBA/ERROR, porque uno cuando decidió usar SQL SERVER 2000 (y se casó con él) no sabía lo que hacían todas las bases de datos del mundo mundial, y menos lo que harían en el futuro ( SQL 2008 ó ORACLE 10) lo que sí sabía es que entonces MICROSOFT,IBM,ORACLE etc no eran lo mismo que BORLAND ó EL MUNDO FREE (no sé q futuro tendrá cada cosa).
Estaremos muertos cuando los optimizadores mejoren a la mente humana (evitar el chiste fácil en referencia a la mía)...
He venido siguiendo todos los comentarios, pero según lo que dice Alfredo ¿Es mejor usar una vista que un store procedure de selección(vista parametrica)?, quisiera ver más explicaciones al respecto. Comparado con ustedes me considero muy novato pero no me gusta estancarme y me gustaria siempre encontrar personas con mas conocimientos como los que encuentro en este blogs.
Bueno que conozco de las vistas Sql Server. Estas se crean como una tabla virtual hecha de una consulta que puede ser de una o varias tablas y las cuales se almacenan dentro de la base de datos y se actualizan cada vez que una tabla de la consulta se actualiza, las cuales puedo convertirlas en actualizables mediante triggers.
Por otro lado los Store Procedure de selección me dan mucha flexibilidad a la hora de hacer consulta complejas a las cuales le puedo pasar parametros y solo me devuelven los registros que necesito. Se que con la vista yo podria seleccionar desde el cliente los registros que necesito pero yo he seguido trabajado con dephi por creer que se me haria muy dificil traducir todo lo que he hecho con esta herramienta a C# lenguaje en el cual sería mas integrado trabajar con los objetos de Sql Server. Trabajando con delphi creo que seria mas facil hacer un Store procedure de selección que una vista por las interfaces de acceso que utiliza delphi. No se si las nuevas versiones de delphi han cambiado yo uso la versión 7. Y según sus comentarios todo tiene que ver con las referidad interfaces de acceso en mi caso ADO
Gracias por sus comentarios...
Por otro lado mi opinión sobre los que estan desesperados por ver la Cara Oculta de C# 4. yo creo que no deberian desesperarse con este lanzamiento y darle tiempo suficiente a Ian para sacar un libro con todo el buen contenido que el nos sabe ofrecer. Además esperar de Microsoft que nos ofreca nuevas cosas que mejoren el desarrollo para que Ian nos la pueda explicar a su estilo. Creo que Ian debiria hacer como forma de Bonos para ayudarlo en cualquier caso con la impresion de estos libros y asi hacer un proyecto mas ambisioso y que se puedan poner mas temas que son de nuestro interes. Así aunque haya que hacer dos tomos si Ian tiene la disposicion estos hirian ayudados por esos bonos y podriamos veneficiarnos más.
Perdón que me meta en la controversia Redman-Alfredo.
Redman: en los pocos ejemplos que diste, Alfredo te contestó correctamente desde el punto de vista técnico, así que creo que estás escapándote por la tangente al eludir "irónicamente" los puntos que él te plantea.
Alfredo tiene una forma algo altiva de expresarse pero contesta de forma técnicamente correcta, aunque te parezca fundamentalista. Pero deja esos formalismos de lado y reconsidera lo que él te está diciendo porque, a mi criterio, está en lo cierto.
Me alegra ver que alguien más está interesado en este tema, porque parece que estamos acaparando demasiado la conversación, pero sigo en mis trece (al menos en SQL SERVER) SP mejor que VISTA como norma general. VISTAS PARTICIONADAS (para el que tenga una versión que las soporte) son una muy buena opción en sitios que demanden OPTIMIZACIÓN.
Perdon, estoy cambiando un concepto todo el rato que quizá haya llevado a confusión, quiero decir VISTAS INDEXADAS, no vistas particionadas, me refiero a las que SE GRABAN EN DISCO!!!
Las VISTAS PARTICIONADAS son las que se usan con servidores distribuidos!!
Mira acabo de hacer memoria y una vez me leí un TEST (o sea que algo si he leido), cuando me saque la certificación de M$ de DISEÑO E IMPLEMENTACION DE BASES DE DATOS CON SQL SERVER 2000
Esto es un mito.
Observa que el artículo se refiere a SQL Server, y que es la misma aclaración que hago en mi comentario (y que aparece también, si no recuerdo mal, en La Cara Oculta de C# desde 2003).
Pero, a pesar de que SQL Server es, por ésta y muchas otras razones, mi favorito, hay vida más allá de SQL Server.
El problema del Prepare es que, cuando funciona (depende del SGBD), no te garantiza que el plan sea compartido entre sesiones. Eso lo medí, reloj en mano, en los viejos tiempos de Delphi con InterBase.
Observa que el artículo se refiere a SQL Server, y que es la misma aclaración que hago en mi comentario
Ya, pero escribiste que SQL Server es el que tiene menos problema cuando no tiene ningún problema en absoluto. :-)
El problema del Prepare es que, cuando funciona (depende del SGBD), no te garantiza que el plan sea compartido entre sesiones.
Funciona con todos los SGBD decentes, y no me parece un problema muy grave que no se compartan los planes entre sesiones.
Si no se comparten los planes entre sesiones eso quiere decir que hay que precompilar las consultas en cada sesión. En un sistema "stateless" las sesiones de la piscina de conexiones pueden durar meses, así que el coste es como mucho infinitesimal (milisegundos a repartir entre millones de consultas).
Además conviene recompilar las consultas de vez en cuando por que los planes óptimos van cambiando con el tiempo, y eso es más fácil cuando no se usan SP.
Bueno pero quien ha ganado? quien ha ganado? Alfredo o Redman ? yo es que estoy en ascuas!!!!!
P.D. A ver si se rie la gente un poco coñe :)
Si se ríen, tienen que abrir la boca, y se les escapará la presa...
Por cierto, si este fin de semana me queda algo de tiempo libre, voy a escribir un artículo desde mi punto de vista, sobre estos temas. Adelanto los puntos principales:
1- Shit happens.
2- Show must go on.
3- Intel es la culpable (cántese con melodía de bolero).
Esto último lo digo en serio. En realidad no se trata tanto de Intel como del puñetero formato OBJ, y de la inercia de Sun, Oracle, Microsoft y demás, que han seguido adorando sin darse cuenta (probablemente) al Becerro de Oro... quiero decir, de silicio.
Ah, y hay una buena noticia para Delphi Prism, aunque no soy yo el protagonista. Pero tengo que pedirle permiso al verdadero protagonista antes de desvelarla.
Pues a ver si tienes tiempo por que eso no hay quien lo entienda :-)
Yo creo que no hay mucho que añadir a todo lo que ha escrito Dijkstra.
Alfredo, por favor nos puede ilustrar con unos cuantos titulos de bases de datos.
Alfredo Novoa va de listillo sabelotodo
Me se casi todo de la asignatura de bases de datos de segundo. ¿Por qué os parecerá tan increible?
Publicar un comentario
<< Home