Pasar datos CSV del CNE a DB (Era: OpenData en Venezuela)

[Milton Mazzarri]

2012/10/14 Jesús Jerez <listas...@gmail.com>:
> poco antes de las elecciones me descargué lo que está disponible del RE en
> el CNE, para tratar de pasarlo a SQL y sea mas fácil consultar, era algo
> simple, no muy elaborado, pero luego me enteré de la idea de openData para
> aplicarlo acá en .ve, así que me decidí a pulir un poco más lo que había
> hecho y compartirlo, espero se pueda ir mejorando con el tiempo entre todos
>
> el código en cuestión está en: https://bitbucket.org/jhuss/re-csv2sql/

Jesús, primero darte las gracias por compartir, ayer precisamente
subía algunos cambios[0] al repositorio de OpenData[1] en donde
mejoraba lo hecho inicialmente por William Cabrera, básicamente hago
uso de los mismos módulos que tú, la diferencia más radical es que no
me voy al driver nativo de la DB si no que apelo al core (nótese que
no hablo del módulo ORM) de SQLAlchemy. Por lo tanto, el script habla
los mismos dialectos que habla SQLAlchemy al cambiar el string de
conexión (Ver TODO en script). Otro punto que cabe resaltar es que al
hacer uso del módulo core las inserciones masivas son muy rápidas, no
escribo un fichero SQL como resultado, inserto los registros a la DB
directamente.

Que conste, la versión que he subido solo incluye la lectura de
electores, falta ampliarlo a los centros[2], pero lo hecho puede
servir de base para tener una versión sucinta de las conversiones del
horrible formato del CNE.

Jesús, si puedes revisa el script publicado en OpenData, cualquier
aporte es bienvenido.

Para finalizar, creo que sería importante concentrarnos en definir una
buena estructura y relaciones entre tablas, por ejemplo, a efectos de
los mencionado previamente por Simón Garcia, en este proceso de
conversión no hemos considerado las migraciones de los electores
publicados por el CNE, o los cambios en años electorales de los
centros de votación.

[0] https://github.com/OpenVE/OpenData/commit/f85666164c0dd3250b3140bd859954b47565c704
[1] https://github.com/openve/opendata
[2] Tal vez haciendo manejo de un parámetro en la línea de comando (-t
--type electores|centros)

Un saludo, feliz día,

--
Milton Mazzarri, a.k.a. [milmazz]
Usuario de GNU/Linux: #369158
http://blog.milmazz.com.ve

[Jesús Jerez]

gracias,

en su momento consider� SQLAlchemy, pero como buscaba generar solo el
SQL y no llevarlo directamente a una BD, me pareci� m�s f�cil
simplemente escribir un archivo.

ahora, ser�a ideal poder hacer las dos cosas, elegir generar el SQL o
llevarlo directamente a una BD, estoy dispuesto a colaborar en eso, pero
tengo algunas inc�gnitas:

no soy un DBA, y con �sto me refiero a que, supongamos, llevando
adelante el programa, no est� eligiendo la manera mas �ptima de
normalizar la estructura de la BD, y no solo eso, podr�a elegir la forma
que m�s me parezca de migrar esos datos. En mi opini�n se debe llegar a
un consenso en que expertos en BD nos propongan un "as� deber�a ser" la
estructura, relaciones, lineamientos y convenciones de la estructura
para esos datos, as� como la mejor forma en que se pueda llevar un
versionado(�por fecha?) a medida que se actualizan, y como llevar a cabo
esa actualizaci�n.

�por qu�? lo veo de de la siguiente manera, en un ecosistema de
aplicaciones, existen muchas maneras de como acceder a los datos, pero
deber�amos mantener una estructura o convenci�n que todas esas
aplicaciones entiendan.

por ejemplo, propongo, mantener una convenci�n de nombres de tablas y
campos, relaciones y tipos de datos, de manera que no importa si la BD
sea sqlite, MySQL, Postgresql, etc., solo se necesiten peque�os ajustes
y de esa forma evitar una posible fragmentaci�n.

�c�mo es eso? supongamos, que, programa A maneja los datos del Registro
Electoral(RE) en una BD A, luego, programa B que hace otra cosa con los
mismos datos del RE, pero no tenga nada que ver con programa A, y usa el
mismo tipo de BD que usa programa A, si en alg�n momento necesito tanto
el programa A y B, no deber�a tener que copiar la BD de B donde est� A,
si en teor�a es el mismo RE, tal vez solo lo necesario inherente a la
naturaleza para lo que fue hecho, si �stos programas se entienden con
una hipot�tica estructura OpenData para el RE no tendr�a mayores
problemas para manejar otras BDs que sigan esa convenci�n.

me parece que �sto es clave, as� poder construir todo lo que se necesita
en un futuro en lo concerniente a �stos datos como OpenData.

saludos

[Jesús Jerez]

no se que paso con la codificación, reenvió de nuevo:

en su momento consideré SQLAlchemy, pero como buscaba generar solo el
SQL y no llevarlo directamente a una BD, me pareció más fácil
simplemente escribir un archivo.

ahora, sería ideal poder hacer las dos cosas, elegir generar el SQL o

llevarlo directamente a una BD, estoy dispuesto a colaborar en eso, pero

tengo algunas incógnitas:

no soy un DBA, y con ésto me refiero a que, supongamos, llevando
adelante el programa, no esté eligiendo la manera mas óptima de
normalizar la estructura de la BD, y no solo eso, podría elegir la forma
que más me parezca de migrar esos datos. En mi opinión se debe llegar a
un consenso en que expertos en BD nos propongan un "así debería ser" la

estructura, relaciones, lineamientos y convenciones de la estructura

para esos datos, así como la mejor forma en que se pueda llevar un

versionado(¿por fecha?) a medida que se actualizan, y como llevar a cabo

esa actualización.

¿por qué? lo veo de de la siguiente manera, en un ecosistema de

aplicaciones, existen muchas maneras de como acceder a los datos, pero

deberíamos mantener una estructura o convención que todas esas
aplicaciones entiendan.

por ejemplo, propongo, mantener una convención de nombres de tablas y

campos, relaciones y tipos de datos, de manera que no importa si la BD

sea sqlite, MySQL, Postgresql, etc., solo se necesiten pequeños ajustes
y de esa forma evitar una posible fragmentación.

¿cómo es eso? supongamos, que, programa A maneja los datos del Registro

Electoral(RE) en una BD A, luego, programa B que hace otra cosa con los
mismos datos del RE, pero no tenga nada que ver con programa A, y usa el

mismo tipo de BD que usa programa A, si en algún momento necesito tanto
el programa A y B, no debería tener que copiar la BD de B donde está A,
si en teoría es el mismo RE, tal vez solo lo necesario inherente a la
naturaleza para lo que fue hecho, si éstos programas se entienden con
una hipotética estructura OpenData para el RE no tendría mayores
problemas para manejar otras BDs que sigan esa convención.

me parece que ésto es clave, así poder construir todo lo que se necesita
en un futuro en lo concerniente a éstos datos como OpenData.

[ilookforyou...@gmail.com]

Pueden publicar el link de descarga de ña data compelta porfavor . y me gustaria sabr si toda la data se puede hacer un ejecutable un setup parecido al de santa ines saludos