Creo que el sistema de foros, ya sean phpbb o cualquier otro, pueden no ser siempre la mejor opción en el renglón del orden de la información.
En los foros abiertos (con los cuales ya no estoy tan de acuerdo) de cualquier temática es muy común encontrarse con los siguientes casos:
1.- Muchos noobs (novatos) en el tema tratado en los foros suelen crear posts (temas) con títulos no muy explicativos como "AYUDAAA" ó "URGENTEEE".
2.- La mayoria de ese tipo de posts contienen dudas anteriormente respondidas en otros posts.
3.- La respuesta clásica por parte de otros usuarios, en ese tipo de circunstancias, suele ser "Busca en el foro" ó "Lee bien la sección de tutoriales".
4.- El post que contiene la respuesta que ocupa el noob tiene fecha muy antigua y no tiene un título descriptivo que ayude a su fácil localización mediante la búsqueda.
Si bien es cierto que en la mayoría de las veces la culpa suele ser del noob (por flojera de no querer buscar ni leer) también debemos de aceptar que parte de esa culpa corresponde al sistema de foros o a la inexperiencia en la configuración del mismo por parte de los administradores (y también a la flojera de responder algo que ya ha sido respondido varias veces).
A falta de un sistema alterno, los administradores o moderadores deben localizar las preguntas más frecuentes y hacer una sección propiamente denominada como tal (o FAQ por sus siglas en inglés). A su vez, siendo los expertos en los temas del foro, deben renombrar los títulos de los posts.
Si la intención de un foro es enseñar o dar soporte, o ambas, se debe entonces crear un temario (índice) donde se enumeren los posts denominados TUTORIALES y donde cada tema lleve el orden correcto, y una descripción del mismo, para que el noob (o cualquier usuario) sepa en que nivel va y hasta donde quiere llegar. Cada tutorial debe mencionar además los posts que deben leer antes de continuar con el proceso descrito en el mismo.
La sección de TUTORIALES no debe estar abierta a respuestas (comentarios) por parte de los usuarios ya que sólo generan páginas y más páginas de comentarios que no llevan a nada. Una mejor opción es actualizar el tutorial en base a las verdaderas discusiones del tema llevadas a cabo una sección de SOPORTE.
Ahora, ya tendríamos 2 secciones las cuales se deben interrelacionar. La sección FAQ debe ligarse a la sección de TUTORIALES.
Los keywords (palabras llave) en ambas secciones son muy importantes para realizar búsquedas más exactas. El uso de un campo en nuestra base de datos que lleve el conteo de las visitas a ciertos posts también ayuda a la hora de mostrar los resultados de las búsquedas (al estilo google).
La constante actualización de los posts ya creados en la sección de FAQ también es importante. El sistema de notificaciones de actualización de facebook es un excelente ejemplo de como organizar la información, ya que permite a los usuarios consultar la nueva información en posts de fechas pasadas sin tener que alterar el orden en que los posts se muestran al ingresar al foro correspondiente (eso es algo malo en los foros cuando estan ordenados por fecha).
El uso de un GLOSARIO también es indispensable, porque quienes no dominan el tema encontrarán términos que no comprendan en los posts.
Todo esto lleva a la simplificación del proceso de enseñanza mediante foros, así como a la reducción de posts innecesarios por parte de noobs (y a una mejor base de datos). Aunque como menciona el dicho: "Haz algo a prueba de idiotas y encontrarás a un idiota mejor" LOL.
Bien se puede crear un sistema nuevo que lleve a una organización como la presentada en líneas anteriores, pero también es cierto que podemos configurar nuestros foros de dicha forma. Sólo bastan 4 secciones para hacerlo: FAQ, TUTORIALES, SOPORTE y GLOSARIO.
Una sección siempre controversial (por políticas de hosting, país, etc.) es el de las descargas. Para ello creo que siempre será mejor un FTP privado. El comprimir los archivos con contraseña y cuyos nombres de archivo no sean TAN descriptivos ayudarán a la privacidad del mismo.
Pero esto es sólo una opinión personal.
martes, 11 de enero de 2011
lunes, 10 de enero de 2011
Búsquedas concatenadas en SQLite3
La forma habitual de buscar 1 parámetro en más de 2 campos de una tabla sería por ejemplo:
[code]SELECT * FROM tabla WHERE campo1='parametro' OR campo2='parametro'[/code]
Pero hoy les muestro como hacer una búsqueda concatenada para un mismo parámetro.
Primero comenzaré recordando la forma de concatenar (unir) campos en una consulta. Para concatenar 2 o más campos deben usar este doble signo ||. Ejemplo:
[code]SELECT nombre||apellido FROM tabla[/code]
Esto nos arrojaría un resultado como RamónPérez (noten que no hay espacio entre el apellido y el nombre).
Así que para dejar el espacio entre ambos campos debemos concatenarlo (sin olvidar las tildes):
[code]SELECT nombre||' '||apellido FROM tabla[/code]
Estos nos arrojaría un resultado como Ramón Pérez (noten que el espacio ahora si aparece). Podemos poner lo que sea dentro de ' ' y crear concatenaciones mejores, como por ejemplo: ||'Nombre: '||nombre||' Apellido: '||apellido
Bueno, pues es similar para cuando queremos concatenar campos posterior a la cláusula WHERE en una consulta de selección. Ejemplo:
[code]SELECT * FROM tabla WHERE nombre||apellido='Alonso'[/code]
En esta consulta en lugar de hacer algo como "select * from tabla where nombre='alonso' or apellido='alonso'" estamos concatenando el campo de búsqueda (nombre||apellido). Esto nos ahorra líneas de código y ya en usos un poco más complejos podemos realizar consultas en campos multiples campos keywords con simples scripts.
Espero les agrade esa pequeña info de sqlite.
[code]SELECT * FROM tabla WHERE campo1='parametro' OR campo2='parametro'[/code]
Pero hoy les muestro como hacer una búsqueda concatenada para un mismo parámetro.
Primero comenzaré recordando la forma de concatenar (unir) campos en una consulta. Para concatenar 2 o más campos deben usar este doble signo ||. Ejemplo:
[code]SELECT nombre||apellido FROM tabla[/code]
Esto nos arrojaría un resultado como RamónPérez (noten que no hay espacio entre el apellido y el nombre).
Así que para dejar el espacio entre ambos campos debemos concatenarlo (sin olvidar las tildes):
[code]SELECT nombre||' '||apellido FROM tabla[/code]
Estos nos arrojaría un resultado como Ramón Pérez (noten que el espacio ahora si aparece). Podemos poner lo que sea dentro de ' ' y crear concatenaciones mejores, como por ejemplo: ||'Nombre: '||nombre||' Apellido: '||apellido
Bueno, pues es similar para cuando queremos concatenar campos posterior a la cláusula WHERE en una consulta de selección. Ejemplo:
[code]SELECT * FROM tabla WHERE nombre||apellido='Alonso'[/code]
En esta consulta en lugar de hacer algo como "select * from tabla where nombre='alonso' or apellido='alonso'" estamos concatenando el campo de búsqueda (nombre||apellido). Esto nos ahorra líneas de código y ya en usos un poco más complejos podemos realizar consultas en campos multiples campos keywords con simples scripts.
Espero les agrade esa pequeña info de sqlite.
Una buena estructura de base de datos
El tener una buena estructura en nuestra base de datos es imprescindible no sólo por orden, sino también para reducir el peso de la misma así como poder brindar mejores reportes (con más detalles autocalculables por ejemplo). Ah, y la rápidez con que se hagan las consultas también dependerá de ello.
Aunque el tener una sola tabla donde acumular ciertos registros que luego puedan ser agrupados para mostrar resumenes o concentrados de la misma puede llegar a ser tentador, no en todos los casos es viable.
Un ejemplo sería el sólo contar con una tabla para registros de facturas donde se ingresan todos los artículos de dicha factura y cuando se quiere ver en forma de concentrado (por folio) sólo se agrupasen los registros. El error en este tipo de tablas y usos es que pueden llegarse a repetir datos en ciertos campos de forma innecesaria (como el número de folio, nombre del cliente, RFC, etc.), provocando el incremento en el peso de nuestra base de datos.
Una solución a esto es contar con 2 tablas interrelacionadas donde la primera sólo sea un control del ID de la factura con detalles como folio, fecha, cliente, RFC, etc. Y la segunda tabla con los registros de los artículos y precios de los mismos.
De esta forma evitamos repetir los datos de RFC, cliente, fecha y otros, en el registro de cada artículo que constituye la factura. Esto sin mencionar que a veces se usa un campo para comentarios que suelen extenderse bastante.
Un consejo es que recuerden que múltiples tablas pueden accederse en una sola consulta mendiante el uso de left join, full join o consultas en formato ANSI. Por ello a veces es necesario manejar más de un índice único para cada registro en nuestras tablas.
Aunque el tener una sola tabla donde acumular ciertos registros que luego puedan ser agrupados para mostrar resumenes o concentrados de la misma puede llegar a ser tentador, no en todos los casos es viable.
Un ejemplo sería el sólo contar con una tabla para registros de facturas donde se ingresan todos los artículos de dicha factura y cuando se quiere ver en forma de concentrado (por folio) sólo se agrupasen los registros. El error en este tipo de tablas y usos es que pueden llegarse a repetir datos en ciertos campos de forma innecesaria (como el número de folio, nombre del cliente, RFC, etc.), provocando el incremento en el peso de nuestra base de datos.
Una solución a esto es contar con 2 tablas interrelacionadas donde la primera sólo sea un control del ID de la factura con detalles como folio, fecha, cliente, RFC, etc. Y la segunda tabla con los registros de los artículos y precios de los mismos.
De esta forma evitamos repetir los datos de RFC, cliente, fecha y otros, en el registro de cada artículo que constituye la factura. Esto sin mencionar que a veces se usa un campo para comentarios que suelen extenderse bastante.
Un consejo es que recuerden que múltiples tablas pueden accederse en una sola consulta mendiante el uso de left join, full join o consultas en formato ANSI. Por ello a veces es necesario manejar más de un índice único para cada registro en nuestras tablas.
Suscribirse a:
Entradas (Atom)