Juan Céspedes - SQL 

Para aprender cómo implementar búsquedas sencillas en campos de texto de una base de datos PostgreSQL hay que utilizar dos funciones: to_tsvector() y plainto_tsquery(), y un operador binario, @@.

• to_tsvector() convierte una lista de palabras en una lista de lexemas significativos con las que poder hacer operaciones de búsqueda. Ejemplo:

  postgres=> SELECT to_tsvector('spanish','cómo cazar un león');
         to_tsvector
  --------------------------
   'caz':2 'com':1 'leon':4
  (1 row)
  

  Para evitar tener que estar poniendo 'spanish' continuamente, si nuestra base de datos tiene información únicamente en español, podemos cambiar el lenguaje de búsquedas por defecto de la base de datos, con:

  ALTER DATABASE cuevasysimas set default_text_search_config = 'spanish';
  

• plainto_tsquery() se utiliza para convertir una cadena en un patrón de búsqueda
• @@ se usa para comprobar si se encuentra un patrón de búsqueda en una lista de lexemas:

  postgres=> SELECT to_tsvector('cómo cazar un león') @@ plainto_tsquery('cazando leones');
   ?column?
  ----------
   t
  (1 row)
  

Por ejemplo, si tenemos una tabla de libros, con las columnas 'titulo' y 'resumen', y queremos mostrar el título de los libros que concuerdan con una búsqueda en el resumen, podemos hacer:

postgres=> SELECT titulo FROM libro WHERE to_tsvector(resumen) @@ plainto_tsquery('palabra');

(o cómo usar Tablas de Historia en PostgreSQL)

Si quieres guardar en algún lugar la historia completa de todas las inserciones, modificaciones y eliminaciones de columnas en tus tablas (para mantener una base de datos estilo wiki), no hay ninguna manera directa de hacerlo... pero aquí puedes ver cómo hacerlo, en un artículo escrito por Thomas Liske.

Funciona con PostgreSQL, creando un trigger escrito en PL/Perl llamado log_history() que añade una línea a una tabla llamada history.<SCHEMA>_<TABLENAME> con un instante de tiempo (hist_ts), la operación realizada (hist_op) y el contenido de todas las columnas, cada vez que se ejecuta un INSERT, UPDATE o DELETE. Esto realmente almacena toda la historia de las tablas en las que se use este trigger.

Aquí puedes ver el trigger log_history, y una función sencilla que activa el trigger en todas las tablas de un schema, history_create_triggers. Puedes llamar a esta función para el schema "public" usando SELECT history_create_triggers('public');

Estas dos funciones están escritas en PL/Perl y PL/pgSQL, respectivamente, así que tendrás que añadir esos dos lenguajes a tu base de datos PostgreSQL, si no lo has hecho ya, con CREATE LANGUAGE plperl; y CREATE LANGUAGE plpgsql;

Los últimos días he estado trabajando en mejorar mis páginas web (www.cespedes.org y juancespedes.es), en concreto las partes relativas al blog y las fotos (de hecho, he eliminado todas las demás páginas).

Acerca del blog, bueno, ahora es realmente un blog :-). Ya puedo añadir entradas (como esta misma) y editar las antiguas desde un navegador. Todas las entradas se almacenan en una base de datos PostgreSQL. Cada entrada tiene su propio enlace, permanente. La gente puede añadir comentarios, y todos ellos se pueden ver desde la página de cada entrada.

Acerca de las fotos, he simplificado las URLs que se usan para navegar por ellas, de manera que se acelere la navegación y para facilitar el trabajo a los robots web. La lista de todas las fotos (más de 64,000) también está almacenada en la base de datos, y he añadido pies de foto a las fotos con localización (para poder mostrar diferentes textos en español y el inglés), y además hay una lista de etiquetas para poner en cada foto.

Tareas pendientes: mejorar / automarizar la manera en la que añado fotos, almacenar y mostrar imágenes escaneadas, cortar y rotar imágenes, crear álbumes, almacenar lista de gente en cada foto, postrar información Exif, guardar el lugar en el que cada foto ha sido realizada...