Hagamos que México crezca..
Prefiere el consumo de lo Hecho en México
|
Programacion
-
Un interesante Post de Robert Simpson desarrollador del Ado Net Provider para SQLite y Visual Studio .NET 2005, dónde explica el porqué usar transacciones es importante, la principal a mi gusto es que disminuye considerablemente el tiempo de ejecución de las consultas, ya anotada en la lista de mis mejores prácticas.. La información fué tomada de la siguiente URL http://petesbloggerama.blogspot.com/2007/02/sqlite-adonet-prepared-statements.html
If you are inserting data in SQLite without first starting a
transaction: DO NOT PASS GO! Call BeginTransaction() right now, and
finish with Commit()! If you think I'm kidding, think again. SQLite's A.C.I.D. design means that every single time you insert any data
outside a transaction, an implicit transaction is constructed, the
insert made, and the transaction destructed. EVERY TIME. If you're
wondering why in the world your inserts are taking 100x longer than you
think they should, look no further.
Prepared Statements
Lets have a quick look at the following code and evaluate its performance:
</em></em>
using (SQLiteCommand mycommand = new SQLiteCommand(myconnection))
{
int n;
for (n = 0; n < 100000; n ++)
{
mycommand.CommandText = String.Format("INSERT INTO [MyTable] ([MyId]) VALUES({0})", n + 1);
mycommand.ExecuteNonQuery();
}
}
<em><em>
The
CLR is calling "new" implicitly 100,000 times because I am formatting a
string in the loop for every insert Since SQLite precompiles SQL
statements, the engine is constructing and deconstructing 100,000 SQL
statements and allocating/deallocating their memory All this
construction and destruction is involving about 300,000 more native to
managed interop calls than an optimized insert.
So lets rewrite that code slightly:
</em></em>
using (SQLiteTransaction mytransaction = myconnection.BeginTransaction())
{
using (SQLiteCommand mycommand = new SQLiteCommand(myconnection))
{
SQLiteParameter myparam = new SQLiteParameter();
int n;
mycommand.CommandText = "INSERT INTO [MyTable] ([MyId]) VALUES(?)";
mycommand.Parameters.Add(myparam);
for (n = 0; n < 100000; n ++)
{
myparam.Value = n + 1;
mycommand.ExecuteNonQuery();
}
}
mytransaction.Commit();
}<em> </em><em><em> </em><em>
this is a blazing fast insert for any database engine, not just SQLite.
The SQL statement is prepared one time -- on the first call to
ExecuteNonQuery(). Once prepared, it never needs re-evaluating.
Furthermore, we're allocating no memory in the loop and doing a very
minimal number of interop transitions. Surround the entire thing with a
transaction, and the performance of this insert is so far and away
faster than the original that it merits a hands-on-the-hips pirate-like
laugh.
Every database engine worth its salt utilizes prepared
statements. If you're not coding for this, you're not writing optimized
SQL, and that's the bottom line.
Many developers do not
fully understand the importance of using prepared statements with
parameters where stored procedures (the preferred method in almost all
cases) cannot or should not be used. The importance of this, combined
with the practice of wrapping repeating inserts or updates in a
transaction, cannot be underestimated. If the above all makes sense,
then you'll like my next installment, "Did Chuck Norris kill SOA?".
-
Hace unos meses durante el análisis de una aplicación que está corriendo ya ahora en Dispositivos Móviles con Windows Mobile 2005 y desarrollada en C# con Visual Studio, estuve buscando información sobre diversas bases de datos que corrieran en Windows Móbile 2005 y tuvieran bastantes fortalezas como :
- Poca Administración debido a las características de los Dispositivos Móviles.
- Soporte de SQL Stándar.
- MultiPlataforma para poder desarrollar interfaces vía Web así como aplicaciones de escritorio tanto en Linux, Windows u otra plataforma sin tener que hacer procedimientos de migración.
- Mayor Velocidad en ejecución de Querys.
- Herramientas de Monitoreo multiplataforma.
- Portabilidad, esto significaría que yo pudiera procesar un archivo de la base de datos en un sitio remoto vía web con Php, Python, Perl, java o alguna otra herramienta, descargarla al dispositivo móvil y operar la base de datos sin tener que hacer un proceso de importación o migración en la PDA.En la búsqueda encontré un BenchMark mostrado por PocketMagazine en la siguiente URL
http://www.pocketpcmag.com/_archives/Aug06/databases.aspx
Pero cómo dice Microsoft Vayamos a los hechos
De todas las bases de datos referenciadas solo pude probar Microsoft SQL Server CE y SQLite
Con respecto a SQL Server CE
- Los archivos SDF de la Base de datos de SQL Server CE no pueden ser consultados cómo tal en Windows XP ya no se diga en otras versiones anteriores de Windows.
- Para importar un catálogo necesitamos hacer una replicación de la BD, la cual el servidor debe ser MS SQL Server.
- Para poder hacer la replicación de cada terminal con el servidor, se requiere una Licencia por cada dispositivo móvil, esto si no se cuenta con una licencia por Procesador. El servidor para Windows Mobile no tiene costo.
- La replicación de MS SQL Server a SQL Server CE implicaría tener una conexión directa Vía Active Sync o TCP/IP al servidor, aparte que la importación de las transacciones consume 100 registros por minuto, lo que importar un catálogo de 30,000 registros nos llevaría 300 Minutoslo que equivale a tener 5 horas al operador esperando apróximadamente.
- El footprint de la base de datos va de 2-3Mb por lo que la capacidad de almacenamiento en la terminal portátil disminuiría considerablemente.
- Exportar la información de la PDA al servidor requiere otra replicación y conexión al servidor MS SQL Server.
- El desarrollo bajo SQL Server CE es propietario y solo se puede realizar desde Microsoft Visual Studio .Net 2003 ó 2005.
Con respecto a SQLite
- Si tenemos la información en una base de datos MySQL, PostgreSQL, MS SQL Server, Oracle, existen herramientas que pueden exportar el esquema y los datos de la base de datos al formato de SQLite véase http://www.sqlite.org/cvstrac/wiki?p=ConverterTools
- La Base de datos puede ser creada en Linux, Windows, Mac, FreeBSD, etc.. y con solo copiar el archivo a la terminal vía Active Sync, podemos usarla en la PDA sin ningún problema, una copia de un archivo con cerca de 500,000 registros en 35 tablas diferentes nos costaría aproximadamente 1 minuto.
- Podemos procesar el archivo de SQLite con diversas herramientas, por ejemplo que una terminal se conecte a un Servicio Web, en dónde se tienen catálogos de clientes, proveedores, productos y otros catálogos, la terminal podría conectarse y descargar esa base de datos y tener todo el esquema y datos en la PDA en tan solo segundos.
- SQLite soporta Querys de SQL Estándar lo que la hace muy poderosa al realizar las consultas para diversos procesos.
- No tiene costo pero mejor aún es Software Libre.
- El desarrollo con SQLite puede ser realizado en diversas herramientas tanto propietarias como libres Véase la multitud de opciones Aquí
Despues de este breve análisis añado al BenchMark de Pocket Magazine otras características a considerar de SQLite interesantes si no es que únicas en comparación a otras Bases de datos tanto libres como propietarias corriendo bajo Dispositivos Móviles.
BenchMark para Dispositivos Móviles desde mi punto de Vista
Aquí un comentario de Robert Simpson desarrollador del Ado Net Provider para SQLite y Visual Studio 2005 .Net y el Compact Framework 2.0 de Microsoft.
"SQLite is faster than SQL Mobile, and SQLite's database files are smaller.In a couple of simple tests inserting, selecting and updating an Int64,SQLite was more than 10x faster. Inserts/updates that took minutes in SQLMobile took seconds in SQLite."
http://phylevn.mexrom.net/data/files/SQLitebyRobertSimpson.txt
Otras referencias:
- http://www.sqlite.org
- http://sqlite.phxsoftware.com/
- http://phylevn.mexrom.net/data/files/files/SqLiteCoNSoL2007.pdf
- http://www.microsoft.com/sql/editions/sqlmobile/sqlmobileresources.mspx
- Litebase - an embedded database management system
|
|
Comentarios Recientes