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
