Mensajes

Dios CarlosWaldo me haces sentir demasiado vieja por aca 

Solo espero que este nuevo IRC sea... bueno sea decente, bueno y que entren muchos usuarios y no abusen del poder ni dejen a la novia que solo sabe encender el PC sentada en el ordenador con operador al lado del nick y banee a todo dios que entre y diga Hola solo porque a ella no le cayese bien....

Un saludo.

Yo tengo 29 


10 años no CarlosWaldo... dirias 8 años    hubo chat IRC anteriormente.

^TiFa^, no entiendo entonces porque dices que SQLite tiene problemas de seguridad. Es un archivo binario en servidor que tan siquiera es accesible por url. Lo pregunto porque no había oído antes críticas en ese sentido y me dejas preocupadx. Es cierto que habías dicho que era binario, no te había entendido.

Tiene problemas de seguridad fisicamente, ya que si alguien tiene acceso a tu PC podria modificar registros de las tablas sin necesidad de autentificarse con un usuario y contraseña. Tambien aunque no te lo confirmo, ya que se maneja esta situacion en SQLite podrian ser mas rapidas y efectivas las inyecciones SQL sobre SQLite, pero no lo confirmo no es mi area ni me dedico a ello. Desconozco porque no se ha expandido criticas negativas en cuanto a seguridad sobre SQLite, puede ser porque los proyectos donde se le ha utilizado no requieran seguridad de este tipo, o son proyectos muy pequenios o algo similar. Particularmente yo solo he visto uso de SQLite en firefox y al nivel de uso no requiere seguridad de ningun tipo ya que lo que guarda es algo personal del usuario que usa firefox en ese PC.

Por otro lado, tengo entendido que el consumo de MySQL no es tan bajo

Sigue siendo un consumo reducido, mira el consumo de un MySQL en uno de los servidores donde trabajo:

[root@cubo-RepDom2 ~]# top -U mysql
top - 16:14:12 up 2 days,  2:21,  1 user,  load average: 0.37, 0.32, 0.22
Tasks:  64 total,   1 running,  63 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.5%us, 25.3%sy,  0.0%ni, 74.2%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   2065920k total,  2013148k used,    52772k free,    10484k buffers
Swap:  2088440k total,       92k used,  2088348k free,  1852600k cached

 PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
2211 mysql     20   0  133m  17m 3640 S  0.0  0.5   0:00.35 mysqld

En total el servidor tiene 2GB de ram fisica, donde el motor MySQL y sus subprocesos consume un 0.5% de 2GB de ram. El calculo es:

2000 X 0.5 / 100 = 100KB

100KB de 2GB es el total que consume el motor de MySQL   obviamente, el porcentaje incrementaria si hubieran decenas de usuarios conectados haciendo constantes peticiones de I/O al servidor, ya que no solo MySQL abre 1 subproceso por usuario, sino que debe aplicarle a ese usuario toda la funcionalidad y permisos (que consumen ram) que posee ese usuario sobre su esquema.

En el caso de SQLite todo lo anterior no aplica, se obvia, porque SQLite no maneja nada de permisos, funcionalidades, distribucion de memoria en buffer cache propio, entre otras cosas... SQLite solo maneja su lectura y escritura sin condiciones sobre su archivo binario    SQLite no tiene 1 motor ejecutandose siempre, SQLite no tiene necesidad de evaluar ninguna condiciones como otros motores si hacen.

Me parece que aunque quieras evitarlo, si vas a tener que considerar el Benchmarking, sobretodo para tu codigo fuente... y no se si SQLite lo tenga disponible, pero puedes pasarle profiling para ver que consumo tiene este al recibir o hacer una consulta SQL... te puedes ayudar de EXPLAIN si es que existe en SQLite.


Entonces te conviene SQLite? si, te conviene si es un proyecto reducido como expones, si el hardware que dispones es el que comentas, y sobretodo por seguridad? averigua mas sobre inyecciones SQL y como evitarlas    es lo que mas deberia preocuparte y no darle acceso de ningun tipo fisico a tu PC a nadie.

necesitamos personas que nos ayuden a algo para el IRC

   

[SQLite es mas un manejador de archivos para mi que una base de datos. Es ligero por el hecho de ser una libreria que llamas, utilizas, creas un archivo binario]

Por otro lado, SQLite no usa un archivo de texto plano (flat-file) como me parece entender que sugieres, sino un binario. Prueba a abrir con un editor de textos.

En eso estamos mas que de acuerdo    relee lo que postee mas arriba, cuando comente:

SQLite es mas un manejador de archivos para mi que una base de datos. Es ligero por el hecho de ser una libreria que llamas, utilizas, creas un archivo binario

Y cuando retorne a repetirlo:

Recuerda que en SQLite se crea 1 archivo binario que guarda todo, indices, datas, vistas, todo...

Si te sirve, vuelvo y te aclaro los SGDB como Oracle, MySQL me conscierne que tambien crean sus archivos fisicos, no de texto sino binarios  aunque lo subdividan acorde a sus necesidades de desempeno 

El caso es que no va a haber cientos de usuarios conectándose a la base de datos simultáneamente, van a ser proyectos de enfoque local en los que mayormente solo la administración modificará el modelo y las consultas simultáneas a este rara vez superarán la docena.

No superaran la docena?? con esto quieres decir que mas de 1 solo usuario estara conectado a la vez en la aplicacion??? Relee cuando te decia:

Cuando intentan realizar modificaciones simultaneas en SQLite, el primer proceso bloqueara la base de datos, evitando cualquier otra modificacion, y se la libera al siguiente proceso solo hasta al terminar. Ademas, el archivo entero solo puede llegar a medir 2 Gigabytes (o asi era cuando maneje este motor, pero estaras mas informado en su website principal)

Cuando te dije esto, me referia a que SQLite solo permitira 1 solo usuario modificando, actualizando registros de una tabla a la vez, la tabla sera bloqueada para evitar que otro usuario modifique, actualize algo... solo hasta que finaliza el primer proceso se le da paso al segundo... entonces depende la cantidad de usuarios que deseen trabajar a la vez en la informacion de una misma tabla.. suponte que solamente son 2 usuarios que estan conectados y quieren actualizar el campo PAIS de una tabla... hasta que el primer usuario que envio la peticion de actualizacion, hasta que esa actualizacion no finalize... la peticion del segundo usuario quedara en cola  y si hablamos de 5 o mas usuarios ya sabes.. una fila india de procesos en espera que termina el primero, para darle seguimiento al segundo, luego al tercero, etc...

Es más, lo que yo me preguntaba es si habría una ganancia de rendimiento si, en ocasiones, decidiera usar un modelo de datos flat-file en lugar de sqlite. Quiero saber hasta que punto podría llegar a valer la pena.

Ganancias de rendimiento? si lo hay, pero de unos cuantos bytes o KB nada mas, ya que no existe un motor o servicio de SQLite ejecutandose, como ocurre con MySQL. Entonces si consideras ganarte unos bytes minimos en memoria si.... SQLite te los ahorraria. Pero ten pendiente lo anterior, y ten mas pendiente que cualquier usuario podra acceder a tus base de datos sin dar uso de usuario o contrasena (ya que SQLite no maneja este tipo de seguridad). O al menos era asi cuando lo utilize.

Un saludo 

AHh!! Entendido... Digamos que solo se utiliza para filtrar los datos que devuelve el SELECT... pero e guarda el dato entero que ha entrado...
Me quedó claro

Eso mismo, aunque no se en que lenguaje es que aplica... tengo amigos programadores webs que usan ese tipo de filtros para limitar la salida presentada finalmente en su proyecto. Pero ciertamente adentro del motor, esto no aplica seguira como bien dices guardandose datos hasta su limite 

y si en un tinyint ingreso el numero '300', se guarda '255'? o '0'?

Si ingresas '300' y es un unsigned tinyint, se resetea y se guarda 255 + un warning por parte de MySQL    si es un tinyint negativo se resetea y se guarda 127 + el warning 

Por cierto, yo tengo la Biblia de MySQL en la PC de mi trabajo, me lo descargue aunque no recuerdo de donde    si tanto quieres el PDF puedo subirlo a un servidorcito que hay alli y pasarte el acceso por ftp y lo bajas...

No hice referencia a cuantos te deja ingresar... porque si el tipo de datos soporta 255 aunque pongas tinyint(1) podras insertar cualquier valor hasta 255 y se guardara, decia que si pones tinyint(1) aunque se guarde 123 se mostrara por pantalla en un programa el valor 1 es mas para filtrar la salida de datos como se mostraran que la entrada de datos y su capacidad.

Que declares un campo como tinyint(2) no quiere decir que soporte una cantidad maxima de valores doble veces (nada de 255*255) seguira soportando lo mismo de siempre de 0 a 255 positivo y de 0 a 127 negativos.

Esto que haces de tinyint(valor) valor significa la cantidad de numeros o caracteres si fuese un tipo de dato alfanumerico a mostrar por pantalla, no la cantidad de datos a guardar dentro de si. Los tipos de datos numericos (tinyint, int, smallint, bigint, etc) tienen un tamanio fijo establecido dentro de si mismo, no lo filtras tu ni le indicas tu el tamano de valores a guardar como harias en un dato alfanumerico como (varchar, char, varbinary, etc). No funcionan iguales los tipos de datos....

Si quieres un campo que soporte 65,000 valores y son numericos enteros pues, puedes optar por SMALLINT que soporte de 0 a 60,000 valores unsigned, si lo quieres mayor tendras que optar por MEDIUMINT que soporta de 0 a 160,000 valores unsigned.

Un saludito 

Se resetea al valor maximo soportado por el tipo de datos tinyint    si es negativo 127  si es positivo 255  de ahi no pasara.

Vamos a ver...

SQLite es mas un manejador de archivos para mi que una base de datos. Es ligero por el hecho de ser una libreria que llamas, utilizas, creas un archivo binario y ya... por ende un comando no te consume memoria al menos que lo llames cierto?    en cambio otro motor mas profesional como MySQL consume unos KB en memoria puesto que hay un servicio ejecutandose en tu sistema.

Ahora bien, en cuanto a consumo quien ocupa menos? obviamente SQLite por lo que te acabo de exponer. Pero.. te intento persuadir otra vez, va a crecer tu proyecto??? Te lo intento repetir porque tienes que considerar varios puntos (No solo cuanto consume o no una aplicacion).

Mysql es un servidor robusto, y en parte bastante ligero en consumo de memoria en comparacion con otros motores relacionales populares de gran uso como es Oracle o SQL Server, MySQL puede tener centenas de conexiones al mismo tiempo y es capaz de hacer modificaciones casi simultaneas en fracion de milisegundos. Para usarlo tienes que conectarte a este por tcp/ip. Puedes manejar bases de datos de un extenso tamano que rondan por los terabytes inclusive....

MySQL fue optimizado para eso y es por eso que es tan ampliamente usado en proyectos webs. De hecho las modificaciones realizadas en las tablas de Mysql no llegan a tocar el disco duro sino hasta despues de unos segundos... se quedan en memoria hasta que vea que ya no son necesarios. Ademas, al tener las tablas en distintos archivos puede manejar modificaciones simultaneas sin preocuparse por corromper los datos, tambien te permite distribuir la carga de consultas y esas cosas en distintos servidores..

Sin embargo todo lo anterior no es tan posible en el amigo SQLite. SQLite no deja de ser un manejador de archivos, y el  proposito principal de todo proyecto que trabaje con base de datos son las modificaciones de registros simultaneas (Ya que hablas de CMS vas a querer que mas de 1 usuario a la vez este conectado a tu proyecto). Cuando intentan realizar modificaciones simultaneas en SQLite, el primer proceso bloqueara la base de datos, evitando cualquier otra modificacion, y se la libera al siguiente proceso solo hasta al terminar. Ademas, el archivo entero solo puede llegar a medir 2 Gigabytes (o asi era cuando maneje este motor, pero estaras mas informado en su website principal), y si intentas acceder desde otra aplicacion en internet, tendras que dar uso de webservices, o tendras que descargarla completa...

Por ende piensa mucho cual es tu proposito final con tu proyecto, no solamente es que me economiza unos ligeros KB en memoria, sino que sera tu proyecto y con que funcionalidad. SQLite esta extremadamente bueno para aplicaciones de escritorio, que necesiten acceso a data local o similar, no para proyectos asi donde habran varios usuarios trabajando algo sobretodo web (que repito no todos los hostings en un caso futuro desees migrar, soportan SQLite).

Recuerda que en SQLite se crea 1 archivo binario que guarda todo, indices, datas, vistas, todo... y para acceder a ese archivito nisiquiera requiere alguien contrasena.. o sea cualquiera puede modificarte informacion de alguna tabla porque es de acceso publico y libre. Todas las bases de datos generan archivos binarios, algunas de manera distribuida como te explicaba en las profesionales, y otras 1 solo archivo para todo... pero son binarios. Y es mas rapido para el sistema operativo o el motor, leer datos binarios que leer datos de texto en un archivo plano como sugieres alias excel o XML, que hay que convertir y eso...

Piensalo, el servicio MySQL apenas te consume unos pocos KB en memoria, y si optas por Postgresql lo mismo... son unos ligeros KB en memoria, pero manejan la data y protegen la info de una manera que SQLite precae.