23 replies to this topic

[Koutarou]

¿Alguien me puede recomendar un programa de base de datos que sea ligero, acepte unicode y sea fácil de configurar? Quiero hacer un diccionario de japo, y usar un monstruo como mysql sería un desperdicio de recursos. No necesito conexión a internet, ni cliente-servidor ni nada de eso, solo algo sencillo y funcional.

[NeoRagod]

Excel??

[Koutarou]

Excel??

Oye, que este es el foro de GNU/Linux. Aunque aquí luzca el sol y todo parezca seguro y apacible, yo no mencionaría a la Sombra por su verdadero nombre, ni nada que tenga que ver con ella XDD

[Petrus]

Puedes usar las hojas de cálculo Gnumeric u OpenOffice Calc; luego exportas los datos y ya está. CSV es un formato bastante estándar.

También hay un "clon" de Access llamado Rekall, pero no se si guarda los datos en una BBDD externa o en un fichero local. Echale un vistazo...

¿Y Gaby? igual es lo que buscas.

Este tema ha sido editado por Petrus: 19 June 2006 - 04:20 AM

[Koutarou]

Preferiría un programa ligero, si puede ser de consola. Mis prioridades son por este orden: unicode, ligereza y facilidad. Gaby tiene buena pinta. Si hay versión de consola me vendría perfecto.

Este tema ha sido editado por Koutarou: 19 June 2006 - 05:02 AM

[NeoRagod]

Oye, que este es el foro de GNU/Linux. Aunque aquí luzca el sol y todo parezca seguro y apacible, yo no mencionaría a la Sombra por su verdadero nombre, ni nada que tenga que ver con ella XDD

Coño XD ahora me doy cuenta como solo le di click directamente en la pagina de inicio del foro si buscar por subforos, no pense que fuese Linux, de cualquier forma con el Open Offica lo puedes hacer XD

/me se auto golpea

[vimora]

/me se auto golpea

Lo que tienes que hacer es auto golpearte en serio. --->

T4|u3

Este tema ha sido editado por vimora: 21 June 2006 - 05:00 AM

[emulation]

ia ia dejen de autoflagelarse xDDD con el mysql puede si usas la version de consola..

[Koutarou]

con el mysql puede si usas la version de consola..

Ya ¿y lo que chupa eso? (si os gusta recibir, no nos engañemos XD). Pues el gaby parece que no tiene versión de consola. He estado usándolo un poco pero al final me he dado cuenta de que necesito tipos de datos más generales, asi que intentaré hacerme un pequeño programita para mi diccionario. Por ahora no importa que sea lento o poco general. Gracias a todos por la ayuda.

Este tema ha sido editado por Koutarou: 21 June 2006 - 06:38 AM

[Dhampir]

vi ftw xD

[Maeghith]

existe SQLite, por el nombre, yo diría que es un motor de SQL pequeño, y según esta tabla sí soporta unicode


lo que no se es si será por linea de comandos

[Bad_CRC]

vi ftw xD

i
ugh agg kk, lo jodido es que me estoy acostumbrando(Esc)
:wq

[Koutarou]

Donde esté mi emacs que se quite eso, por diox.

How to move the cursor one character forward in vi

The correct answer is:

<ESC>la

which works in all modes. Except at the beginning of a line, where the above command will move the cursor two characters forward. If it did anything else, it would not be vi. So at the beginning of the line, this answer is the correct one:

<ESC>li

And of course neither will work at the end of the line. At the end of the line, the correct command is:

<ESC>j^i

The topic of the next two lectures will be ``how to move the cursor one character backward in vi''.

[Petrus]

Real }{4x0rz use vim

[Koutarou]

and Real Programmers write in machine code XDD

[Maeghith]

esa expicación no es correcta, ya que mezcla el modo de edición (el cursor está entre los caracteres) y el modo comando (el cursor está sobre los caracteres).

En cualquiera de los 2 modos, el cursor se puede mover un caracter hacia adelante o hacia atrás con las flechas del teclado

pero este hilo no va de vim vs emacs, va de bases de datos ligeras, ¿probaste SQLite?

[Petrus]

Acabo de acordarme de que en este artículo hacen referencia a DB3 y se usa en modo comando. ¿Alguien de aquí lo conoce y/o ha trabajado con ello?

Más información aquí

[Takamura]

Humm, no tengo mucha experiencia con bases de datos y no estoy seguro de si me servirán. El problema es que cada entrada del diccionario no se puede representar como una lista de campos de texto, tiene más estructura. Cada entrada sería más o menos así:

1) Escritura en kanji o katakana. Puede haber 0 o varias.
2) Escritura en hiragana. Puede haber varias.
3) Tipo de palabra japonesa (nombre, adjetivo, etc.). Puede haber 0 o varios.
4) Significado. Puede haber varios. Cada uno incluye:
4.1) Tipo de palabra japonesa. Puede haber 0 o varios.
4.2) Tipo de palabra española. Puede haber 0 o varios.
4.3) Significado propiamente dicho. Solo hay uno.
4.4) Ejemplos. Puede haber 0 o varios.

Para mí lo más natural para representar esto es una lista de listas (de listas...) de longitud variable, o un árbol. Por eso estoy dudando si usar una base de datos o directamente hacerme un programita específico para mi diccionario en un lenguaje que maneje bien las listas o los árboles, o que me permita definir mis propios tipos de datos. Lo que me parece más problemático para meter el diccionario en una base de datos es que las listas son de longitud variable (a lo mejor hay una forma sencilla de hacerlo, no sé).

Vaya, acabo de encontrar esto. Quizás me sirva algo de ahí.

Este tema ha sido editado por Takamura: 26 June 2006 - 09:10 AM

[takeda]

Lo de las listas variables usando las reglas de normalizacion se tendria que solucionar (una tabla con todos los kanjis y una clave externa indicando a que palabra pertenece cada kanji puede valer, por ejemplo). Pilla la estructura de un registro (lo que tu has puesto) y vete aplicando las reglas de normalizacion y asi supongo que conseguiras algo.

[Takamura]

Gracias, ya me he informado de las reglas de normalización y funcionarían. Lo malo es que desperdician bastante espacio. La clave primaria de cada entrada del diccionario es la pareja formada por 1) y 2), que a su vez son listas. Con la 5ª regla de normalización se puede arreglar algo, ya que los hiraganas están determinados por los kanjis, cuando los hay, pero aun así la tabla de kanjis desperdicia memoria. En los significados es peor. La clave primaria de 4) es 4.3), que es bastante grande. Repetir esa clave para cada ejemplo sería un desperdicio enorme (para los tipos de palabra la mayoría de las veces no habrá que repetirla). Esto se podría arreglar juntando todos los ejemplos en un solo campo de texto, aunque no me gusta mucho la idea, es poco flexible. En fin, veré qué me compensa más, usar una base de datos relacional, una jerárquica o programar algo.

[takeda]

Las reglas de normalizacion normalmente no hay que aplicarlas todas. Con aplicar las 3 primeras vale.

Con las claves lo que puedes hacer es crearte un campo autonumerico como clave primaria y ya. Es un poco guarrada, pero no tienes que repetir tanto.

Este tema ha sido editado por takeda: 26 June 2006 - 01:44 PM