Nomenclaturas o Naming Conventions
En vista del último análisis que se hizo acerca de si usar nombres en singular o en plural para las tablas de nuestras bases de datos es lógico que continuemos analizando las nomenclaturas o naming conventions o convención de nombres para los distintos elementos que componen las bases de datos de nuestras aplicaciones. Vamos a analizar las nomenclaturas más aceptadas por la comunidad de usuarios a la vez que verificamos si la base de datos de WordPress cumple con las mismas.
El análisis comenzará con las nomenclaturas para los nombres de las tablas.
¿MAYÚSCULAS o minúsculas?
Respuesta: minúsculas. La razón más sólida para usar minúsculas para los nombres de las tablas es la ayuda visual que obtenemos al hacerlo. Observe las siguientes consultas SQL:
* SELECT * FROM USUARIOS
* SELECT * FROM usuarios
Es una práctica muy común el usar MAYÚSCULAS para los comandos propios de SQL tales como "SELECT" o "FROM". Por lo que cuando un desarrollador ve dentro de una consulta algunas palabras en MAYÚSCULAS la primera palabra que se le vendrá a la mente será "SQL". Preguntémonos entonces: ¿qué pasaría si usamos MAYÚSCULAS para identificar a una tabla dentro de una consulta?. Pues fácilmente se confundiría con un comando SQL.
Y la situación se pondría peor si nuestras consultas resultan ser mucho más complejas que los ejemplos mostrados. En tal caso perderíamos tiempo valioso analizando una consulta para diferenciar los comandos SQL de los nombres de las tablas. Lo cual no pasa cuando contamos con la ayuda visual que brinda el usar nombres en minúsculas para las tablas.
¿Las tablas de WordPress usan nombres en minúsculas? Sí. Todas las tablas de WordPress usan nombres en minúsculas. Punto a favor.
¿camelCase o underscore_case?
Respuesta: undescore_case.
Hay ocasiones en las que una o más de nuestras tablas debe tener un nombre compuesto por 2 o más palabras. En estos casos debemos buscar alguna forma de unir las palabras que formarán el nombre de una tabla. Las 2 opciones de mayor aceptación por la comunidad de usuarios son camelCase y undescore_case.
La opción camelCase dictamina que las palabras que van a formar los nombres de una tabla deben estar unidas sin espacios. Y para diferenciar una palabra de otra cada palabra (a veces con excepción de la primera dependiendo de la preferencia del desarrollador) debe tener su primera letra en MAYÚSCULA. El nombre camelCase hace alusión a la forma de un camello (camel) en donde cada letra en MAYÚSCULA vendría a representar a una joroba del camello.
La opción undescore_case dictamina que las palabras que van a formar los nombres de una tabla deben estar unidas por un subguión (undescore). En este caso se puede diferenciar fácilmente una palabra de otra por lo que no es necesario el uso de mayúsculas.
Hay 3 razones fundamentales por las cuales los usuarios prefieren el uso de underscore_case:
1.- La opción undescore_case es más parecida al lenguaje natural pues mientras que en el lenguaje natural usamos palabras separadas por espacios con undescore_case usamos palabras separadas por subguiones. Una leve diferencia.
2.- La opción undescore_case no hace uso en ningún caso de letras en MAYÚSCULA. Si lo hiciese (tal como lo hace camelCase) estaría en contra de la nomenclatura anterior en la cual definimos que era mejor usar minúsculas para los nombres de las tablas.
3.- La opción undescore_case permite diferenciar fácilmente si el nombre de una tabla hace uso de un prefijo o no. Mientras que camelCase no nos permite diferenciar a simple vista si dentro del nombre de una tabla hay un prefijo.
¿Las tablas de WordPress usan nombres con undescore_case? Sí. Todas las tablas de WordPress usan nombres con undescore_case. Punto a favor.
¿Debo usar prefijos?
Si bien el uso de prefijos no está prohibido hay que recordar que solo deben usarse en casos justificados. Recordando obviamente que hay más de una justificación para usar prefijos.
¿Las tablas de WordPress usan nombres con prefijos? Sí. ¿Tiene justificado el uso de prefijos?. Sí. Veamos.
Durante el proceso de instalación de WordPress debemos indicar el nombre de cualquier base de datos que tengamos creada en el mismo servidor donde vamos a efectuar la instalación. Esta puede ser una base de datos nueva con ninguna tabla o una antigua que ya contenga algunas tablas. Ahora vamos a suponer la siguiente situación: vamos a instalar WordPress en una base de datos que ya contiene tablas y una de esas tablas tiene el nombre "users". Si WordPress hubiese llamado a su tabla de usuarios con el nombre "users" (actualmente se llama "wp_users") ocurriría un error al momento de tratar de instalar WordPress pues una base de datos no puede contener 2 o más tablas con el mismo nombre. Sabiendo que estas situaciones pueden ocurrir en la vida real WordPress decidió usar un prefijo para el nombre de todas sus tablas y así evitar estos posibles errores de instalación. Por lo cual podemos decir que WordPress tiene justificado el uso de prefijos para los nombres de sus tablas.
Una vez más, punto a favor
¿Y puedo usar números?
No y simplemente no. La verdad del caso es que no hay ninguna razón para usar números dentro de los nombers de las tablas. Hasta se podría decir que la persona que lo hace está mostrando un conocimiento muy pobre sobre diseño de bases de datos.
Si bien WordPress actualmente no hace uso de números dentro de los nombres de sus tablas hubo un tiempo en el cual WordPress tenía una tabla cuyo nombre contenía un número. La tabla se llamaba "wp_post2cat". Era una tabla intermedia que enlazaba la tabla "wp_posts" con la tabla "wp_categories" (también en desuso). Obviamente el número 2 reemplazaba a la palabra en inglés "to". Reemplazar a una palabra con un número obviamente no podría considerarse como una práctica seria dentro del diseño de bases de datos.
Felizmente WordPress corrigió su error. Sin embargo no habrá punto a favor o en contra en este caso.
¿Y que hay de los acrónimos y abreviaciones?
Al igual que en el caso de los prefijos el uso de acrónimos y abreviaciones no está prohibido pero en la medida de lo posible se debe evitar su uso. Las principales razones son las siguientes:
1.- Dificulta la lectura del nombre de una tabla.
2.- No todos sabrán qué significa. Hay casos en los que más de una persona están involucradas en el desarrollo de una aplicación. Si una de ellas decide usar una abreviación o un acrónimo dentro del nombre de una tabla, ¿entenderán los demás su significado? Muy probablemente no.
Sin embargo cabe resaltar que hay casos en los que un acrónimo o abreviación es de uso generalizado y por lo tanto fácil de reconocer por casi cualquier persona. Siendo uno de los casos más saltantes el acrónimo HTML. HTML es un acrónimo de "HyperText Markup Language" pero los desarrolladores usamos comunmente el acrónimo y no la frase completa. En este tipo de casos se puede justificar el uso de un acrónimo o de una abreviación.
¿Las tablas de WordPress usan nombres con acrónimos o con abreviaciones? Sí. WordPress hace uso de una abreviación. La abreviación es "wp" (obviamente por "WordPress") y es el prefijo que tienen todos los nombres de sus tablas. Por lo tanto podemos decir que WordPress tiene justificado el uso de esta abreviación.
Y otra vez, punto a favor.
Hablemos de los campos de las tablas
Algunas nomenclaturas relacionadas con los nombres de las tablas también se repiten con los nombres de los campos. Veamos algunas.
1.- Nombres en singular. Sí, SINGULAR. Las tablas usaban nombres en plurar por ser consideradas como un conjunto de registros. Pero como normalmente un campo hace alusión a un dato único como el email o la dirección se suelen usar nombres en SINGULAR. Resaltanto además que el uso de nombres en plural no está prohibido cuando se tiene una buena justificación como en el caso de algunos campos que pueden contener más de un dato. Casi siempre estos campos suelen ser de tipo texto.
2.- Nombres en minúsculas.
3.- Nombres con underscore_case.
4.- Nombres sin prefijos. Hay que resaltar que en el caso de los nombres de los campos no está justificado el uso de los prefijos. Simplemente porque las posibles razones que tenían las tablas para usar prefijos son razones imposibles en el caso de los campos. Por ejemplo, WordPress tenía justificado el uso de prefijos en los nombres de sus tablas pues eso evitaba que hubiesen dos tablas con el mismo nombre en la base de datos. Lo cual es imposible que ocurra con los campos pues una tabla puede contener un campo con el nombre "abc" y otra tabla también puede contener un campo con el nombre "abc" sin problema alguno. Y si alguien intenta poner 2 o más campos con el mismo nombre dentro de una misma tabla pues el gestor de base de datos que este usando no se lo permitirá. Por lo tanto, el uso de prefijos para los nombres de los campos no está justificado.
¿Las tablas de WordPress usan nombres siguiendo estas nomenclaturas? mmm. Veamos.
WordPress no hace uso de prefijos para los nombres de sus campos. Además, WordPress también hace uso de underscore_case para los nombres de sus campos. Per he de resaltar 2 cosas importantes con respecto a las otras 2 nomenclaturas:
1.- WordPress tiene un campo dentro de su base de datos cuyo nombre está, justificadamente, en plural. El campo se llama "link_notes" y se encuentra dentro de la tabla "wp_links". Este campo almacena varias notas relacionadas con un link (enlace). Debido a esto es que está justificado el que use un nombre en plural.
2.- WordPress no hace uso de minúsculas de forma absoluta para los nombres de sus campos. Hay campos cuyo nombre está en mayúsculas (como "ID") o simplemente es una mezcla de mayúsculas y minúsculas (como "comment_ID"). En este caso WordPress lo hizo muy mal.
Qué dicen, ¿punto en contra?
No usen el nombre de la tabla para un campo
La razón fundamental para esto es que facilita la lectura de una consulta SQL. Veamos.
Si yo quiero seleccionar un campo de una tabla dentro de una consulta SQL normalmente uso la expresión "TABLA.CAMPO". En tal caso si quiero consultar el "nombre" de un cliente dentro de la tabla "clientes" tendré 2 opciones dependiendo de como he llamado al campo que hace alusión al nombre del cliente:
1.- SELECT cliente.cliente_nombre FROM clientes... (caso en el que uso el nombre de la tabla para definir el nombre del campo)
2.- SELECT cliente.nombre FROM clientes... (caso en el que NO uso el nombre de la tabla para definir el nombre del campo)
La segunda consulta podría leerse como "quiero el nombre del cliente". Pero ¿como se leería la primera consulta? Sería algo como "quiero el cliente nombre del cliente"....¿suena eso "natural"?...obviamente NO.
Debido a esto es que se debe evitar el uso del nombre de la tabla dentro del nombre de los campos. Sin embargo, el nombre de la tabla dentro de los campos solo está justificado en el caso de los campos que servirán de llave primaria o secundaria (o foránea) dentro de una tabla. Veamos un ejemplo.
Vamos a suponer que tenemos 2 tablas relacionadas entre sí. La tabla "clientes" y la tabla "pedidos". La tabla "pedidos" almacenará los pedidos de los clientes. Si no usamos el nombre de la tabla para los nombres de las llaves primarias de ambas entonces las tablas lucirían de esta forma:
clientes
id
pedidos
id
Ahora vamos a agregarle a la tabla "pedidos" la llave secundaria o foránea relacionada con la llave primaria de la tabla "clientes".
clientes
id
pedidos
id
id (este es el id del cliente que hace el pedido)
Obviamente esto no será permitido por nuestro gestor de base de datos pues no pueden haber 2 campos con el mismo nombre. Debido a este problema es que se opta por cambiarle el nombre a la llave secundaria relacionada con la tabla "clientes" y que se encuentra dentro de la tabla "pedidos". Y qué mejor que ponerle el nombre de la tabla de donde proviene para poder identificarla fácilmente. Haciendo esto las tablas quedarían de la siguiente forma:
clientes
id
pedidos
id
cliente_id (este es el id del cliente que hace el pedido)
Ahora cada vez que en una consulta SQL se quiera relacionar ambas tablas se tendría que hacer lo siguiente:
clientes.id = pedidos.cliente_id
Si bien esa definición no está mal hecha se podría mejorar de la siguiente manera:
clientes.cliente_id = pedidos.cliente_id
De esta forma la consulta SQL sería más fácil de comprender y analizar. Lo cual nos lleva a la conclusión obvia de que la llave primaria de la tabla "clientes" necesita un cambio de nombre. Ahora quedarían así:
clientes
cliente_id
pedidos
id
cliente_id (este es el id del cliente que hace el pedido)
Y si ya se ha usando el nombre de la tabla para definir le nombre de su llave primaria entonces la misma práctica se tendría que hacer con el resto de tablas para llevar una concordancia. Con esto las tablas quedarían así:
clientes
cliente_id
pedidos
pedido_id
cliente_id (este es el id del cliente que hace el pedido)
Todos estos pasos nos han llevado a la conclusión evidente de que es una buena práctica el usar el nombre de la tabla solo para los campos del tipo llave primaria o secundaria.
¿Los campos de WordPress usan nombres que contienen el nombre de sus tablas? Sí. En este caso WordPress ha cometido un error enorme y considerable ya que el 98% de sus campos contienen el nombre de su tabla correspondiente. Haciendo uso de esta mala práctica de forma galaxicamente desastrosa. Y es curioso notar que hay tablas en donde la llave primaria no contiene el nombre de la tabla mientras que el resto de campos sí...un giro de 180 grados hacía el dark side of the force.
1000 puntos en contra (exageración).
No al tipo de datos
Esta la considero como una práctica de antaño y muy desfasada.
Hay quienes, por ejemplo, suelen usar la palabra "bool" para definir el nombre de campos del tipo boleano. Por ejemplo: "bool_eliminado" (para saber si una persona ha sido eliminada o no) o "bool_permiso" (para saber si una eprsona tiene permiso o no a realizar determinada acción). Pero esta práctica ha sido reemplazada por otra que permite definir de manera más natural los nombres de este tipo de campos. Por ejemplo el campo "bool_eliminado" se puede reemplazar por "esta_eliminado" y el campo "bool_permiso" se puede reemplazar por "tiene_permiso". Así la lectura de este tipo de campos se realizaría de forma más natural ya que, por ejemplo, el campo "esta_eliminado" lo puedo leer como "¿está eliminado?". ¿Ven la diferencia?.
Sin embargo, hay casos especiales en los que aparentemente se usa el tipo de datos dentro de los nombres de los campos. Pero no es así. Veamos un ejemplo.
El campo "fecha_registro" almacena la fecha en la cual se registró una persona. Este campo es del tipo "fecha" o "date". Y ya que la palabra "fecha" aparece dentro del nombre del campo quizá se diga que se está usando el tipo de datos para definir el nombre del campo. Pero en realidad es una confusión. La palabra "fecha" hace alusión a lo que se almacena pero no al tipo de datos. Una "fecha" tiene que almacenarse dentro de un campo del tipo "fecha". Y como ambas palabras son iguales pues he ahí la confusión. En el caso de nuestro idioma es más congruente decir que una "fecha" se puede alamcenar en un campo del tipo "date"...así podemos evitar posibles confusiones.
¿Los campos de WordPress usan nombres que contienen su tipo de datos? No. Punto a favor.
Y a continuación...
El vídeo
Footer
¿Qué dicen? ¿Qué nota le pondrían en general a WordPress? Ah, si están interesados en estudiar la base de datos de WordPress pueden descargarse un archivo que he titulado "La historia de la base de datos de WordPress". Este archivo lo pueden descargar haciendo click aquí.
Atte. orifichu
