On Wed, 30 Nov 2005 14:54:04 -0300 "Ricardo Mun~oz A." <[EMAIL PROTECTED]> wrote:
> podrias entregar mas detalles al respecto?? Puedes encontrar algo de info en modsecuriry y otros sitios relacionados. Salu2 From [EMAIL PROTECTED] Wed Nov 30 16:16:08 2005 From: [EMAIL PROTECTED] (Alvaro Herrera) Date: Wed Nov 30 16:10:50 2005 Subject: sitio hackeado In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> Juan Sagardia escribió: > Disculpa Alvaro Herrera, pero no olvides que la version 5.0 de MySQL > tambien se implementaron los Procedimientos Almacenados y Vistas entre > otros objetos por lo tanto no la miremos como una BD menor. No leiste mi otro mail donde comentaba las limitaciones de los triggers en MySQL? Esta bien, han implementado algunas cosas (basicas!), pero muchas otras siguen siendo primitivas. Para mi, sigue siendo no una BD menor, sino un juguete. Oye, si hasta SQLite tiene triggers hoy en dia. Mas avanzados que los de MySQL. > En todo caso el esquema de modelo de capas es el mas adecuado para la > construccion de sistemas por el concepto de encapsular la logica en el > cliente. No he negado eso (ni he dicho que sea cierto), pero no veo que tiene que ver en este flamefe^W hilo de discusion. -- Alvaro Herrera http://www.PlanetPostgreSQL.org La web junta la gente porque no importa que clase de mutante sexual seas, tienes millones de posibles parejas. Pon "buscar gente que tengan sexo con ciervos incendiándose", y el computador dirá "especifique el tipo de ciervo" (Jason Alexander) From [EMAIL PROTECTED] Wed Nov 30 16:27:33 2005 From: [EMAIL PROTECTED] (PEIRANO ALVARADO, GINO PAOLO) Date: Wed Nov 30 16:19:21 2005 Subject: sitio hackeado In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> El mié, 30-11-2005 a las 14:25 -0300, Alvaro Herrera escribió: > PEIRANO ALVARADO, GINO PAOLO escribió: > > > que hay de Mysql 5??? alguna experiencia...benchmarks?? > > se supone que mejoraron muchas cosas, entre ellas, la posibilidad > > de consultas, triggers y proc. almacenados... quizas sea una pequenna > > alternativa, habra que hecharle un ojo y ver como se porta... > > Hola, desde hace un tiempo no me gusta meterme en guerras santas, asi > que voy a omitir comentarios que no sean totalmente objetivos. El > comentario objetivo que puedo hacer es que el soporte para estas cosas > en MySQL 5 esta mucho mas que muy verde; como por ejemplo el tema de que > en los triggers no puedes hacer accesos a tablas; o como que las llaves > foraneas no soportan la capacidad de ser disparadas "mas tarde" en la > transaccion ("deferred") ni soportan clausulas ON UPDATE. > > Tu diras, ah, pero eso son "tonteras" o pelos de la cola, o son > "caracteristicas mas avanzadas para las que podemos esperar un poco > mas". Pero la verdad es que sin eso, la gente que dice "los triggers no > sirven para nada que no se pueda hacer en la aplicacion" tiene mucha > razon -- asi como estan, no sirven para nada. Cuando estan bien > implementados la cosa es muy distinta. > > > La verdad es que todas estas limitaciones hablan de caracteristicas que > fueron implementadas a la rapida, para satisfacer los "buzzwords" y a la > prensa, no para darle herramientas utiles a los usuarios. Estaran estas > cosas implementadas _bien_ en el futuro? Es muy posible que si, pero > por que no decir _ahora_ que el soporte de triggers aun es "alpha" o > "experimental", cuando realmente eso es lo que es? > > Postgres tiene todas estas cosas implementadas desde hace _años_. En > todo este tiempo se han ido afinando, mejorando, ajustando; ese proceso > largo y tedioso MySQL aun no lo ha hecho y no lo va a hacer de un dia > para otro. > > > Quieres hacer mediciones de rendimiento? Haz todas las que quieras; > pero se justo y usa tablas InnoDB en MySQL, comparando cosas > interesantes. Creo que puedo prever el resultado: el rendimiento para > consultas triviales sera equivalente entre MySQL y Postgres, mientras > que en consultas complejas PostgreSQL lo deja muy atras porque el > optimizador de consultas de MySQL esta aun muy verde (como casi todo lo > demas). > > Pero francamente a mi no me interesan los resultados del rendimiento. > _Primero_ quiero un sistema que funcione bien. Las optimizaciones se > pueden hacer despues. Pero si empiezas haciendo un sistema que ande muy > rapido y despues lo modificas para que haga cosas, entonces se va a ir > haciendo cada vez mas lento ... lo cual hace que no tenga mucho sentido, > verdad? Con Postgres esto ha dado excelentes resultados. El sistema > hacia muchas cosas al principio, pero era muy lento. Hoy en dia es > muchisimo mas rapido, y sigue haciendo las mismas cosas, y hace otras > nuevas con las que MySQL ni sueña. nada mas claro en tu explicacion... la verdad que no he visto a Mysql 5 en accion, por eso la pregunta de "que tal"... y al parecer, y muy objetivamente tienes muchos fundamentos en los cuales basarte... pero bueno, el topico se fue para otro lado, y este tema da para conversarlo tomando un cafe o algun bebestible a gusto, o bien en un rico asado.. En respuesta al muchacho que fue "hackeado" o victima de un scriptkiddie... utiliza mod_security de apache bien sazonado de acuerdo a lo que tu ocupas.. mas info en http://www.modsecurity.org Saludos! Gino > ------------ próxima parte ------------ Se ha borrado un mensaje que no está en formato texto plano... Nombre : smime.p7s Tipo : application/x-pkcs7-signature Tamaño : 4199 bytes Descripción: no disponible Url : http://listas.inf.utfsm.cl/pipermail/linux/attachments/20051130/97a246ac/smime.bin From [EMAIL PROTECTED] Wed Nov 30 16:19:02 2005 From: [EMAIL PROTECTED] (Ubaldo Taladriz) Date: Wed Nov 30 16:57:48 2005 Subject: sitio hackeado In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> > En todo caso el esquema de modelo de capas es el mas adecuado para la > construccion de sistemas por el concepto de encapsular la logica en el > cliente. La lógica en el cliente en un modelo de capas¿? Plop. Será por eso que hoy en día estamos hablando de SOA. Definitivamente la lógica no está en el cliente y ojo que la lógica no son las validaciones de los campos de entrada. Esto es así áun cuando hoy están de vuelta los clientes con mayores capacidades, ocupando modelos AJAX o productos como Flex de macromedia. El otro comentario que a mi modo de ver tampoco aplica, fue una referencia a extreme programming "Y no es una decision fija, _ahora_ se necesita en MySQL si despues alguien mas lo necesita en otro tipo de sistema se modifica" http://en.wikipedia.org/wiki/Extreme_Programming " Que es algo tan vago como decir, bueno ahora se necesita como aplicación web, mañana como web services integrados a otras compañías y ahí veremos como lo hacemos. ¿Qué tiene que ver eso con Extreme programming? Supongo que tiene ver con el valor de la simplicidad, que al parecer al traducirlo en Chileno suena como el valor de la improvisación del maestro chasquilla o puede ser que tenga ver con el principio de "aceptar los cambios" el cual hace referencia a cambios funcionales. En mi opinión el tratar de mantener la simplicidad del sistema, que se resume en la vieja regla KISS (Keep it simple stupid), que es bastante anterior a XP, no abarca y por lo tanto no se hace cargo, de requerimientos no funcionales tales como la flexibilidad, la mantenibilidad y la portabilidad. Estas "bilidades" son resueltas por la arquitectura del sistema, y no por un valor, que este caso más bien suena a una apuesta o a una decisión de negocio, ahora en el corto plazo se necesita en MySQL, hagamos caja, después vemos si sale algo más. Mi último punto tiene que ver con el origen de la discusión. Mientras menos dependo de la BD, pierdo en eficiencia, pero gano en portabilidad. Es teniendo en cuenta esto que discrepo de Alvaro. La pega de la BD son los datos, y por lo tanto habitualmente lo que dejo a cargo de la bd, son movimientos masivos de datos. El resto, todo a la capa intermedia. Es decir, triggers, stored procedures, son bienvenidos para resolver la problemática de datos, nada más Saludos -- Ubaldo Taladriz EXE Ingeniería -------------------- http://www.exe.cl Exe Ingeniería & Software Ltda. Europa 1935 Providencia - Santiago Código Postal : 750-0568 Tel (56-2) 2049366 Fax (56-2) 2040897 counter.linux.org #274593