Cambios
Antes que nada quisiera aclarar que mi objetivo principal no es hacer una serie de vídeo tutoriales. Mi objetivo es hacer una serie de vídeo artículos.
Debido a que muchas veces lo que se presenta en un vídeo no es 100% entendible decidí hacer vídeos acompañados por artículos. Cada artículo explicaría con más detalle lo que se pretende enseñar en el vídeo. De esa forma un mayor número de viewers saldría beneficiado.
Aún así más de una persona comentó que el texto que acompañaba a cada vídeo era muy largo. Y es por eso que decidí hacer algunos cambios en la forma de mostrar cada pieza de esta serie de vídeo artículos.
Primero decidí mostrar el vídeo al inicio de cada artículo y no al final. Y segundo decidí que el artículo ya no mostraría el mismo contenido del vídeo. Ahora el artículo mostrará solo aquellas partes consideradas relevantes y aquellas partes en las que es necesario aumentar la explicación (explicación que no puede ser aumentada en el vídeo debido al límite de tiempo).
Gracias por la comprensión. Y sin más...
Flexibilidad
En palabras sencillas se podría decir que una base de datos es más flexible cuando un desarrollador tiene que modificar o nada o muy poco de la misma para lograr sus objetivos. Si un desarrollador tiene que hacerle muchas modificaciones a la base de datos para que su plugin funcione al 100% entonces se puede decir que la base de datos no es una base de datos flexible.
Una de las preguntas más recurrentes en aplicaciones como WordPress (en las cuales desarrolladores externos crearán un sin número de extensiones tocando en algunas ocasiones la base de datos) es: ¿cómo le podemos dar mayor flexibilidad a nuestra base de datos?.
Si ustedes quieren darle mayor flexibilidad a las bases de datos de sus aplicaciones entonces traten de imitar la "técnica" que WordPress ha aplicado con sus tablas "wp_users" y "wp_usermeta".
Para aquellos que no lo sabían hubo un tiempo en el que WordPress usaba UNA sola tabla para almacenar la información de los usuarios. La tabla "wp_users". Sin embargo los problemas comenzaron cuando los desarrolladores empezaron a crear plugins que requerían manejar mayor información de los usuarios. Para lograrlo algunos desarrolladores decidieron crearle nuevos campos a la tabla "wp_users"; y algunos otros decidieron no tocar la tabla "wp_users" y crear otra tabla que almacene la información adicional de los usuarios (por ejemplo "wp_user_extended_data"). Pero en ambos casos siempre se tendría que crear nuevos campos en alguna de las 2 tablas.
Teniendo en cuenta este caso y la definición que dimos en el primer párrafo, se podía concluir lógicamente que la tabla "wp_users" no era popular por su flexibilidad.
"wp_users" y su flexible amigo "wp_usermeta"
La "técnica" que aplicó WordPress para darle mayor flexibilidad a su tabla "wp_users" es algo que ya había visto con anterioridad en otras bases de datos. Y personalmente me alegró mucho ver que una aplicación como WordPress se decidiera por adoptar tal "técnica".
Lo que WordPress decidió hacer fue dividir su tabla "wp_users" en dos tablas: "wp_users" y "wp_usermeta". La tabla "wp_users" es la misma de siempre pero con menos campos. Los pocos campos de la tabla "wp_users" son campos prioritarios que WordPress necesita para su aplicación (como por ejemplo "user_login" o "user_pass"). El resto de campos no prioritarios no han desaparecido. Simplemente se reubicaron dentro de la nueva tabla "wp_usermeta".
La nueva tabla "wp_usermeta" es aquella que trajo la flexibilidad a la tabla "wp_users". Esta nueva tabla contiene solo cuatro campos de los cuales dos con los que realmente nos interesan: "meta_key" y "meta_value". El campo "meta_key" fue hecho para contener los nombres de los campos eliminados de la tabla "wp_users"; y el campo "meta_value" fue hecho para contener el valor de los campos eliminados de la tabla "wp_users".
Así, lo que antes era:
wp_users
first_name ..... last_name
Juan ................ Perez
Ahora es:
wp_usermeta
meta_key .......... meta_value
first_name .......... Juan
last_name .......... Perez
En palabras sencillas lo que antes era un campo dentro de la tabla "wp_users" ahora es una fila dentro de la tabla "wp_usermeta". Una solución sencilla pero ingeniosa. Ahora si un desarrollador quiere agregar un dato a los usuarios ya no tendrá que crear un nuevo campo dentro de "wp_users" sino que tendrá que crear una nueva fila dentro de "wp_usermeta". Y como al hacerlo no tendrá que modificar la estructura original de la base de datos pues se puede decir que es una solucón que le ha brindado flexibilidad a la misma.
Entonces, lo que antes podría ser:
wp_users
first_name ..... last_name ..... telefono
Juan ................ Perez ............. 222222
Ahora sería:
wp_usermeta
meta_key .......... meta_value
first_name .......... Juan
last_name .......... Perez
telefono ............. 222222
Lo mejor de todo para los desarrolladores es que tendremos que escribir menos código en nuestros plugins. ¿No les parece que WordPress merece demasiados puntos por hacer que nosotros los desarrolladores trabajemos menos?.
user_nicename
Me pareció obligatorio resaltar dos cosas importantes sobre este campo ubicado dentro de la tabla "wp_users".
Primero, que es posible que el "user_nicename" de un usuario sea igual al de otro. Por ejemplo, si el usuario número uno ingresa dentro del input "username" el texto "usuario nuevo" WordPress almacenará como "user_nicename" el texto "usuario-nuevo"; y si el usuario número dos ingresa dentro del input "username" el texto "usuario.nuevo" WordPress almacenará como "user_nicename" el texto "usuario-nuevo". Conclusión: CONFLICTO.
Para evitar este tipo de eventualidades es que WordPress, antes de almacenar el "user_nicename" del usuario, primero se asegura que este no exista. Si ya existe entonces WordPress le asigna un número al final del texto. Así, si ya existe el "user_nicename" "usuario-nuevo" entonces el siguiente "user_nicename" será "usuario-nuevo2". Y si ya existe "usuario-nuevo2" entonces WordPress almacenará el texto "usuario-nuevo3". Y así consecutivamente.
Y segundo, que el valor del campo "user_nicename" se usará para la url del usuario. Por ejemplo, si activamos la opción de urls amigables dentro de la configuración de WordPress uno de los formatos posibles para la url de los usuarios sería "www.website.com/author/valor_del_campo_user_nicename/". El formato de la url puede variar pero siempre contendrá el valor del campo "user_nicename". Obviamente la razón por la que se usa el valor del campo "user_nicename" dentro de la url y no el valor del campo "user_login" es porque el valo del campo "user_login" puede contener caracteres inválidos para una url tal como los espacios. Para evitar este tipo de conflictos es que WordPress inventó el campo "user_nicename" que viene a ser una modificación bonita (nice) de "user_login".
user_status
Quizá la razón más exacta por la que WordPress ya no usa el campo "user_status" es porque todas sus capacidades pueden ser reemplazadas y hasta aumentadas por el rol ("Role") de cada usuario. Por ejemplo, si quiere bloquear a un usuario basta con que seleccionemos el rol "No role for this site". Al hacerlo el usuario no podrá ingresar al panel de administración de WordPress.
a:1:{s:10:"subscriber"; s:1:"1";}
¿Porqué WordPress almacena de esta forma el valor del "Role" de cada usuario?. Para responder a esta pregunta hay que tener en cuenta 2 cosas.
En primer lugar que WordPress es capaz de trabajar con multisitios. Y debido a esto es que cada usuario va a tener un rol por cada sitio. Así, si existen dos sitios usando la misma base de datos cada usuario tendrá dos roles. Y sin embargo, cada usuario seguirá teniendo una sola fila "wp_capabilities" dentro de la tabla "wp_usermeta".
Y en segundo lugar que el campo "meta_value", dentro de la tabla "wp_usermeta", es un campo del tipo VARCHAR (lo cual es lógico ya que va a almacenar variables de todo tipo). Debido a esto es que cualquier valor que se va a ingresar dentro de este campo primero tendrá que ser convertido a texto y luego podrá ser almacenado.
Ante estas dos razones la pregunta que surge es: ¿cómo hará WordPress para almacenar más de una valor dentro de una sola fila?. La respuesta se la brindó una capacidad de PHP: la serialización.
WordPress antes de almacenar los valores del rol de cada usuario los ingresa dentro de un array. Luego usa la función "serialize" de PHP. Esta función permite convertir cualquier tipo de variable en una cadena de texto. Obviamente la cadena de texto resultante tendrá un formato especial para luego poder ser recuperada con facilidad.
¿Y cómo se puede leer una de esas cadenas? Sencillo. Cada letra indica el tipo de variable que se está almacenando ("a" por "array" y "s" por "string"). Cada número indica la longitud del valor almacenado o también la cantidad de valores almacenados (sin embaro recordar que cuando se trate de una variable del tipo entero ["i"] no aparecerá número alguno). Y lo que está entre comillas es el valor almacenado.
De esa manera, si tenemos la variable $array = array("subscriber"=>"1") y la serializamos obtendremos como resultado la cadena a:1:{s:10:"subscriber";s:1:"1";}. La cadena se podría leer como: 'Lo siguiente es un solo ARRAY cuyo índice es del tipo STRING con una longitud de 10 y de valor "subscriber". Y el valor del array es del tipo STRING con una longitud de 1 y de valor "1"'.
Footer
Si alguien me puede recomendar alguna aplicación con la que pueda establecer un chat en vivo dentro del site oficial de orifichu y así responder preguntas en vivo y en directo; le estaré eternamente agradecido.
Atte. orifichu
