Administración web de una base de datos de NWN – Parte 1

CAPÍTULO 1 - MOTIVOS

Los principales motivos que podemos tener para administrar la base de datos del server desde la web serán:

• Sencillez. Con esto nos ahorraremos de estar toqueteando las base de datos directamente y/o las modificaciones correspondientes en el módulo.
• Interactuación entre la web y el módulo.

CAPÍTULO 2 - HARDWARE Y SOFTWARE NECESARIO

HARDWARE

Casi cualquier pc nos servirá si deseamos montarlo por nuestra cuenta, por ejemplo en casa. Aunque si no queréis molestaros en estar administrando un server y tenerlo 24 horas encendido y consumiendo un poco de ancho de banda, siempre podéis optar por un servicio de hosting o housing.
Por si sentís curiosidad, yo dispongo de la típica adsl de 3 mb de Telefónica, y las características de mi servidor podeís verlas aqui. Aunque el anterior a ese lo he tenido corriendo en un Intel Pentium III a 450 mhz con 256 mb de Ram.

SOFTWARE

A continuación un listado de lo que yo utilizo:

• Suse Linux 10.2, como sistema operativo en el servidor web.
• Apache, como servidor de páginas web.
• Mysql, como servidor de bases de datos.
• Mysql Administrator y Mysql Query, como cliente de base de datos
• Php, como lenguaje de programación.
• Quanta o Bluefish como aplicaciones para desarrollar en Linux o Dreamwearver para Windows.
• Un cliente ftp o ssh, para subir ficheros. Lo dejo a vuestro gusto.
• Firefox como navegador. Esto también a gusto del consumidor.

TECNOLOGÍAS EMPLEADAS

• SQL
• PHP
• HTML
• CSS

CAPÍTULO 3 - CREACIÓN DE LA ZONA DE ADMINISTRACIÓN

CREANDO LA ESTRUCTURA

A mi me gusta tener todo muy limpio y ordenado, lo que me ahorra tiempo en futuras modificaciones o ampliaciones.
Listado de directorios que utilizaremos para nuestro ejemplo. Los expongo a continuación:

• / - Esto es la raíz. Logicamente representará al directorio donde queráis almacenar la página web.
• /mantenimiento - El directorio donde irémos almacenando la zona de administración, de esta forma queda separado de la web. Importante: aunque no lo toquemos en este manual, este directorio debería de estrar protegido con usuario y contraseña.
• /mantenimiento/css - Almacenará las hojas de estilos.
• /mantenimiento/img - Almacenará las imágenes de la web.
• /mantenimiento/includes - Almacenará los includes.

Una vez tengamos los directorios creados, abrimos nuestro editor web y creamos las siguientes páginas (ojo a las rutas):

• /mantenimiento/index.php - Página principal de administración.
• /mantenimiento/css/generico.css - Hoja de estilos. Puede darse el caso de que queráis usar varias.
• /mantenimiento/includes/cabecera.php - Parte de la cabecera.
• /mantenimiento/includes/cuerposup.php - Parte superior del cuerpo de la página.
• /mantenimiento/includes/cuerpoinf.php - Parte inferior del cuerpo de la página.
• /mantenimiento/includes/pie.php - Pie de la página.
• /mantenimiento/includes/conexion.php - Incluirá el código para conectar a la base de datos.

El hecho de usar varios includes, me ahorra depender de las típicas plantillas de Dreamweaver. Y a la hora de modificar cualquier parte genérica de la web solo tengo que subir dichos includes y no todos los archivos.
Otra de las muchas utilidades de este método es que el código quedá mucho más legible. Podréis ver su funcionamiento en cualquier portal tipo phpnuke o similares.

Estructura de una base de datos optimizada aplicada al NWN

CAPÍTULO 1 - MOTIVOS

Existen varios motivos, pero los más importantes son 2:

• Reducción de sentecias sql, lo cual repercute a medio-largo plazo en la velocidad del server.
• Limpieza y orden.

CAPÍTULO 2 - ESTRUCTURA

Lo primero que tenemos que hacer antes de crearla, es tener bien claro las variables y tener en mente que en un futuro puede ser que deseemos añadir más. Para ello podemos valernos de cualquier procesador de textos o papel y lapiz (como a la antigua usanza).
Una vez que sabemos todos los datos que queremos guardar, deberíamos dividirlos en 2 bloques, datos básicos (requeridos para poder jugar) y datos opcionales o indispensables.
Consejo: A la hora de crear tablas es recomendable que sean de tipo innodb. Esta opción nos dejará trabajar con posibles relaciones. También cabe estudiar el tema de los Procesos Almacenados.

ESTRUCTURA BÁSICA

A continuación muestro como debería de quedar las tablas y/o campos.
Tabla: cuentas

Campo	Tipo	Atributos	Extra	Otros
id_cuenta	int	unsigned	auto_increment	primary key
cuenta	varchar(100)
password	varchar(100)
cdkey	longtext
baneado	int

Guardará todos los datos básicos referente a las cuentas.
Tabla: personajes

Campo	Tipo	Atributos	Extra	Otros
id_pj	int	unsigned	auto_increment	primary key
id_cuenta	int	unsigned		relación
nombre	varchar(100)
online	int

Guardará todos los datos básicos referente a los pjs. Relacionada con la tabla cuentas.
Tabla: server

Campo	Tipo	Atributos	Extra	Otros
id_server	int	unsigned	auto_increment	primary key
ano	int
mes	int
dia	int

Esta tabla contendría los datos fundamentales para el funcionamiento del servidor. Yo he puesto estos, pero lógicamente se podrían añadir más.

ESTRUCTURA AVANZADA

Tabla: caracteristicas

Campo	Tipo	Atributos	Extra	Otros
id_car	int	unsigned	auto_increment	primary key
id_pj	int	unsigned		relación
fue	int
des	int
con	int
inte	int
sab	int
car	int
pgact	int
pgtotal	int
fechainicial	int
xp	int
oro	int
id_deidad	int			relación
raza	varchar(100)
fortaleza	int
reflejos	int
voluntad	int
ataquebase	int

Esta tabla albergaría las características de la ficha de los pjs. Si en un futuro se quieren introducir más variables en ellas no abría problema. Mantendrá relación con la tabla de personajes y la tabla de dioses.
Tabla: areas

Campo	Tipo	Atributos	Extra	Otros
id_area	int	unsigned	auto_increment	primary key
ref	varchar(100)
descripcion	longtext

Esta tabla almacenará todas las referencias de las áreas actuales y futuras junto con el nombre de cada una de ellas.
Tabla: quest

Campo	Tipo	Atributos	Extra	Otros
id_quest	int	unsigned	auto_increment	primary key
ref	varchar(100)
descripcion	longtext
activa	int

Almacenará todas las referencias y nombres descriptivos de las quest. Opcinalmente, yo he decidido poner una campo más para poder activarlas y desactivarlas en caso de que no funcionen bien o cualquier otro problema que surja con ellas.
Tabla: diario

Campo	Tipo	Atributos	Extra	Otros
id_diario	int	unsigned	auto_increment	primary key
id_pj	int	unsigned		relación
id_quest	int	unsigned		relación

En esta tabla se guardarán las quest hechas por los pjs. Mantendrá relación con la tabla de personajes y la tabla de quest.
Tabla: areasv

Campo	Tipo	Atributos	Extra	Otros
id_areasv	int	unsigned	auto_increment	primary key
id_pj	int	unsigned		relación
id_area	int	unsigned		relación

Guardará las áreas visitadas por los pjs. Mantendrá relación con la tabla personajes y areas.
Tabla: estadisticas

Campo	Tipo	Atributos	Extra	Otros
id_estad	int	unsigned	auto_increment	primary key
id_pj	int	unsigned		relación
xpmonstruos	int
xpviajes	int
xpfabricar	int
xpquest	int

Aqui almacenaremos cualquier variable que nos sirva para las estadísticas. Se le podrán ir añadiendo más.
Tabla: dioses

Campo	Tipo	Atributos	Extra	Otros
id_deidad	int	unsigned	auto_increment	primary key
ref	varchar(100)
descripcion	longtext

Aquí incluiremos el listado de dioses.

CAPÍTULO 3 - OTRAS ALTERNATIVAS

Si sois de los que no os gustan tener muy estructurada la base de datos pero no queréis renuncionar a tenerla optimizada, siempre podéis juntar con la tabla de personajes aquellas tablas que solo van a tener un registro por pj.
Por ejemplo: Los campos de las tablas estadisticas y características podrían agregarse a la de personajes.
Y con éste último capítulo doy por concluido este tutorial. Espero que veáis en él un ejemplo a seguir.