Imagine a relationship between students and classrooms. Every classroom can have N students, meaning this zero, one, or many pupils. From the other side, every student must have a classroom, otherwise she won’t be allowed to study. This is a classic 1:n relationship, used in most of the real cases that we may encounter.

But what if, let’s say, a student had finished her studies and, however, wasn’t deleted from the database? (just to keep the records and other sensible information). In that case, the statement ‘every student must have one and only one classroom’ would be wrong. Instead, we could say ‘every student can have one classroom or none’. Now we are talking about zero or one to many relationships.

A practical situation for this type of relationships are tree structures on auto-referenced tables. For instance, a category tree where every tuple can have a parent or none (thus being at root level). While a possible solution to this problem might be to create a ‘fake’ root element that all the others inherit from unless said otherwise, this approach forces the design to include a ‘meta element’, not meant to represent data at all. That’s to say, it has to be programmatically removed from all database queries so not to have it poking around.

The right solution to this problem is making the foreign key nullable so that we can effectively represent the case when there is no parent while respecting relational integrity. In addition, the cascading options on deletion should be set as ‘set null’ so that a possible deletion of a classroom does not delete all the students that might be related:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

-- ------------------------------------------
-- Table classrooms 
-- ------------------------------------------
CREATE TABLE classrooms(
  classroomID INT NOT NULL AUTO_INCREMENT ,
  classroomName VARCHAR(50) NOT NULL ,
  PRIMARY KEY (classroomID)
) ENGINE = InnoDB;
 
-- ------------------------------------------
-- Table students
-- ------------------------------------------
CREATE TABLE students (
  studentID INT NOT NULL AUTO_INCREMENT ,
  studentName VARCHAR(50) NOT NULL ,
  classroomID INT DEFAULT NULL ,
  PRIMARY KEY (studentID) ,
  CONSTRAINT fk_students_classrooms
    FOREIGN KEY (classroomID)
    REFERENCES classrooms.classroomID
    ON DELETE SET NULL
    ON UPDATE CASCADE
) ENGINE = InnoDB;

Further reading: here and here.

1
2
3
4

sudo apt-get install mysql-server</li>
sudo apt-get remove --purge mysql-server</li>
sudo apt-get autoremove mysql-server</li>
sudo apt-get install mysql-server</li>

Some times is useful!

Let’s imagine that, as I explained before, I have separated data input into tables coded by a station ID. All of them are stored in the same database for maintenance simplicity sake. So, we have the ‘database’ in which there are hundreds of tables called ‘Station_XYZ’. Every table has the same structure: to simplify, SensorID, Time (UNIX), Value. All right then, time to make cubes!

First of all, I define a MySQL stored procedure to extract maximum, minimum and average values from these tables and to save them in a second ‘database_cubes_1h’, named so because this process will run every hour. Also, there is a table Stations in ‘database_main’ (a third database to keep other application’s configurations), where all the stations ever installed are registered. We will use this table to know if a station exists and therefore its related table in database. A first draft would look like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

-- -----------------------------------------------------
-- Procedure `fill_cubes_1h`
-- -----------------------------------------------------
 
DROP PROCEDURE IF EXISTS fill_cubes_1h;
 
DELIMITER //
 
CREATE PROCEDURE fill_cubes_1h($StationID INT)
BEGIN
  IF Station_ID IN (SELECT StationID FROM `database`.`Stations`)
  THEN
    SET @strSQL = CONCAT('
      INSERT INTO `database_cubes_1h`.`Station_',$StationID,'`
      SELECT
        SensorID,
        UNIX_TIMESTAMP(DATE_FORMAT(FROM_UNIXTIME(Time),"%Y-%m-%d %H:00:00")) AS Hour,
        AVG(Value) AS Value,
        MAX(Value) AS ValueMax,
        MIN(Value) AS ValueMin
      FROM `database`.`Station_',$StationID,'`
      WHERE
        Time >= UNIX_TIMESTAMP(DATE_FORMAT(NOW() - INTERVAL 1 HOUR,"%Y-%m-%d %H:00:00"))
      GROUP BY
        HOUR, SensorID
      ORDER BY
        HOUR ASC
    ');
 
    PREPARE statement FROM @strSQL;
    EXECUTE statement ;
    DEALLOCATE PREPARE statement ;
 
  ELSE
    SET @foo = "";
 
  END IF;
 
END;//
 
DELIMITER ;

Basically, it composes a query to extract averages from one table and insert into another at once. This query is run as a prepared statement so that we can reuse the function for all the stations in our database, as long as tables are always named as Station_XYZ. But, what does exactly it do?

1. Use a statement like ‘INSERT INTO table SELECT * FROM another_table. It will copy data automatically if the number and format of columns of the SELECT output and the INSERT INTO input are the same.
2. As Time is stored in UNIX EPOCH time, it is converted to ISO time, then only the hour is extracted, then it is converted back to UNIX. The result of this process is be able to group the result set by hour, getting rid off minutes and seconds. “UNIX_TIMESTAMP(DATE_FORMAT(FROM_UNIXTIME(Time),”%Y-%m-%d %H:00:00″)) AS Hour”
3. A WHERE condition filters the results for the last hour: ‘Time >= UNIX_TIMESTAMP(DATE_FORMAT(NOW() – INTERVAL 1 HOUR,”%Y-%m-%d %H:00:00″))’.
4. Finally, the whole result set is grouped by Time, to be able to calculate averages, maximums and minimums. This statement does the grouping by respecting the different sensors that might have sent data on the same hourly interval “GROUP BY HOUR, SensorID” and the following ones perform calculations “AVG(Value) AS Value, MAX(Value) AS ValueMax, MIN(Value) AS ValueMin”.

Up to now we seem to have resolved the performance problem. Hourly cubes can be constructed and we only would need to add a sort of cron job. But, it is not so easy… I haven’t mentioned yet that data is not received synchronously. That means, within a time frame of three or four hours we could receive the data from a lazy or out of range station. That may be problematic, so…

I’ve changed my stored procedure to do as follows:

1. Calculate the whole last day in hourly tranches, while keep running every hour. “WHERE Time >= UNIX_TIMESTAMP(DATE_FORMAT(NOW() – INTERVAL 1 DAY,”%Y-%m-%d %H:00:00″)) AND Time <= UNIX_TIMESTAMP(DATE_FORMAT(NOW() – INTERVAL 1 HOUR,”%Y-%m-%d %H:59:59″))”
2. Modify the query to allow update in case that a hourly cube was already calculated. “ON DUPLICATE KEY UPDATE `Value` = VALUES(`Value`)”

Please note that in order to get it correctly running, there should be an effective way to detect a duplicate key. In my case, I’ve used all fields but the value as primary keys, instead of defining a new artificial key field. Thus, SensorID and Time are primary keys, so there should never be more than one value for each combination of both. Doing so, MySQL detects duplicate and updates the third column, value, by throwing no errors. The whole stored procedure would look like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

-- -----------------------------------------------------
-- Procedure `fill_cubes_1h`
-- -----------------------------------------------------
 
DROP PROCEDURE IF EXISTS fill_cubes_1h;
 
DELIMITER //
 
CREATE PROCEDURE fill_cubes_1h($StationID INT)
BEGIN
 
  IF Station_ID IN (SELECT StationID FROM `database`.`Stations`)
  THEN
    SET @strSQL = CONCAT('
      INSERT INTO `database_cubes_1h`.`Station_',$StationID,'`
      SELECT
        SensorID,
        UNIX_TIMESTAMP(DATE_FORMAT(FROM_UNIXTIME(Time),"%Y-%m-%d %H:00:00")) AS Hour,
        AVG(Value) AS Value,
        MAX(Value) AS ValueMax,
        MIN(Value) AS ValueMin
        FROM `database`.`Station_',$StationID,'`
      WHERE
        Time >= UNIX_TIMESTAMP(DATE_FORMAT(NOW() - INTERVAL 1 DAY,"%Y-%m-%d %H:00:00")) AND
        Time <= UNIX_TIMESTAMP(DATE_FORMAT(NOW() - INTERVAL 1 HOUR,"%Y-%m-%d %H:59:59"))
      GROUP BY
        HOUR, SensorID
      ORDER BY
        HOUR ASC
      ON DUPLICATE KEY UPDATE `Value` = VALUES(`Value`)
    ');
 
    PREPARE statement FROM @strSQL;
    EXECUTE statement ;
    DEALLOCATE PREPARE statement ;
 
  ELSE
    SET @foo = "";
 
  END IF;
 
END ;//
 
DELIMITER ;

The next step is to get this procedure running every hour for all the stations in the database. Now we are going to use our Stations table. The steps to follow are:

1. Request the highest station ID in Stations table
2. Since station ID’s are not sequential, get a way to determine if related table should exist
3. Tell the procedure to keep going if any exception raises
4. Run the loop until reach final station ID, and call the previous procedure passing current index as a parameter

The final result looks like:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

-- -----------------------------------------------------
-- Procedure `climaps_main`.`fill_all_cubes_1h`
-- -----------------------------------------------------
 
DROP PROCEDURE IF EXISTS fill_all_cubes_1h;
 
DELIMITER //
 
CREATE PROCEDURE fill_all_cubes_1h()
BEGIN
  DECLARE v INTEGER;
  DECLARE m INTEGER;
 
  DECLARE CONTINUE HANDLER FOR SQLEXCEPTION BEGIN END;
 
  SET v = 0;
  SET m = (SELECT StaID FROM climaps_main.Stations ORDER BY StaID DESC LIMIT 1);
 
  WHILE v <= m DO
 
    CALL fill_cubes_1h(v);
    SET v = v + 1;
 
  END WHILE;
 
END;//
 
DELIMITER ;

We’ve nearly finished! We have a way to build hourly cubes for a variable number of stations, and solving the problem of asynchronous data. We just need to create an event to run this last procedure, as we have stated above, every hour. This should work on MySQL 5.1

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

-- -----------------------------------------------------
-- Event `database_main`.`fill_cubes_1h`
-- -----------------------------------------------------
 
DROP EVENT IF EXISTS fill_cubes_1h;
 
DELIMITER //
 
CREATE EVENT fill_cubes_1h
  ON SCHEDULE EVERY 1 HOUR
  DO BEGIN
      CALL fill_all_cubes_1h();
  END //
 
DELIMITER ;

If for any reason we are not allowed to create events (all this stuff should be run as a user with whole access to the tables involved), or we are running a MySQL version lower than 5.1, a cron job should be run instead. Just get EXECUTE access on the database where the procedures have been created (on my case, database_main), and add this line to crontab:

1

0 * * * * mysql -e 'CALL database_main.fill_all_cubes_1h()'

Please note that to get this statement running without asking for a password, you need to create a .my.cnf file in your home directory (UNIX systems)

And that’s all!

So, what do you think? What’s your method? Comments and feedback are much appreciated

In this post I’d like to talk about the main three techniques we’ve used to engage our high performance database, and the reasons to choose these solutions.

First of all, MySQL innodb tables start degrading at some million registers  (7-10M on my current server, but not tested further), so the first though I had was: we need to divide if we want to conquer. Then, after some thinking about, I decided to split the big table into small chunks, and use a table for each station. That made the whole problem more affordable, and tables smaller enough not to become scary: the new problem was how to store about 5 M registers per year per table in our database.

Of course, some logic in both the application controller and the data input server was needed to correctly place data registers. Additionally, tables get often fragmented so some cron jobs were needed to keep the database running smoothly. But there was still the problem of data growing. As long as registers were separated depending on the station, the scalability problem was solved: more tables can be added, even more servers with ranges of stations and a hash function to calculate what server is a given station hosted in. Once again were we talking about several million registers per year per table, and with a standart MySQL 5.1 server (the main problem with an start-up company tends to be funding, so we didn’t have anything better).

Then a second solution came out: since 80% of queries are performed over the last few years of data, let’s move oldest registers to depot tables! This way, data used most often will be kept on relatively small (affordable, at least) tables, and the rest will be just stored.  So a big problem had turned into a matter of designing some queries over a bunch of tables, in a way that can be easily automated. Great! And it’s been so for a while, until we’ve realized that even with small tables, we are handing huge sets of data to represent evolution of physical variables along time. I’m talking about high resolution data, let’s say a measure every minute for some types of sensor, which makes sense to study minor variations along the day.

It’s now when we start thinking about cubes – resumes. The real headache with big data sets starts when comparing a whole month range of values, which will produce several thousand registers to represent on a 800px wide plot graph… that’s basically a waste of server processor and memory resources, since we are providing a resolution which is not adapted to the circumstances.

So now we have a third solution which is based on averages. MySQL – as other database engines – allows creating averages on the fly which is further better than relying these operations on the application layer. The problem beneath is that a big data set must be evaluated on demand, and this for every user on the website (we barely can cache MySQL responses because values change every 10 minutes). To fix it, we’ve decided to run these operations just once every hour, and store the results on cubes – tables with resumes – which would be consulted instead of the high density original ones. The algorithm to determine the table to look is simple: if the range of data is larger than several days, just use the hourly resolution instead. To automate this, we’ve added some naming convention, let’s say, all data tables are named the same way (based on the station ID), and only the database name (based on the data resolution) changes.

To finish with, I’d like to advance the construction of this cubes generation process:

1. A stored procedure calculates averages for a given period for a given table
2. Another stored procedure launches the first one for all the tables; it is defined to be called from whatever time event handler we use
3. The event handler is defined, well in MySQL engine, well as a cron job

I’ll talk about the implementation details in further posts…

So I wrote a php script that would run with a cron job and every three months, create a new table, add it some triggers, and remap a MyISAM merged table on another database. Clear and easy, at the beginning. Everything went right until I went for the triggers creation…

First of all, there is no way to use the values returned from a SELECT or SHOW statement on MySQL stored procedures: that means that tasks like remapping the merged table cannot be done with stored procedures on 5.1. Well, I would need a PHP script anyway so this wasn’t really disappointing. After all, I would create a couple of stored procedures (one to create table, another to create triggers) on the database definition, so that I would never need to know both table and triggers structure from any external script.

That run with the table creation statement, but not with the triggers. As I used a prepared statement on MySQL to allow dynamic definition of tables and triggers (every quarter, a new table name), these technique has some limitations. One of them is as follows: prepared statements do not support yet create trigger sentences. So finally I had to move this part to the external script.

And then started fun: mysql_query or mysqli_query php functions do not support multiple – statements (and triggers often use several because delimiters and some code is executed). What would I do?

Well, perhaps there are smarter solutions, but I chose to write first a temporary file, and use it then as source for MySQL. Using ‘SOURCE file.sql’ was tricky, because SOURCE is an instruction available on the MySQL client, not the server, so PHP cannot execute it. ‘LOAD DATA INFILE’ was suggested in some forum’s solutions but this is limited to only data – and I wanted advanced SQL statements.

Finally, the function ‘system’ on PHP core gave me the solution: if I can call server’s system, I can just run mysql client telling it where the source SQL file is. This way ‘mysql -u user –password=pass < file.sql’ is actually mysql client who is doing the job for me.

It is running, and working

In such a situation, we can rely on our software, but… what happens if any error is introduced on the application layer? Some valuable registers could be lost and hard to identify and recover later. To avoid this effect, we’d rather prefer to implement some constraints in our database. I wouldn’t think that all the applications that connect to our database are going to be free of bugs, and our data is so valuable!

A good way to implement this protection is using triggers. Triggers are SQL sentences that execute when (or after, or before) some action happens over the registers of a table. Usually, they can be defined to be executed BEFORE or AFTER an UPDATE, INSERT or DELETE action happens.

So, the approach is: each time a register is told to be deleted from a certain table, the trigger we are going to set up will raise and tell the user (application, interface, whatsoever): ‘hey, listen, you cannot do that’. This trigger will be executed after the DELETE action, and will break the operation avoiding the deletion.

Unfortunately, this is quite easy in other database servers like Oracle and MSSQL, where exceptions and errors can be handled and created by the user. With these servers, the content of the trigger would like more or less like this:

throw_exception('cannot delete registers from this table');

And that’s all: the exception makes the entire request fail.

But we don’t have this feature in MySQL (at least not in 5.1 version), and the way to get the same behavior is a bit tricky. If we cannot send an exception to alert the user that something has failed… well, at least we would be able to make some thing crash, and the server itself will tell the user about this failure!

I guess that there are several ways of doing the same. This is my particular one: I try to insert empty values on the same table a register is about to be deleted. This throws an error because a trigger cannot modify the same table it has been raised from, and operation fails. An external user will not know, however that this error is due to the trigger I’ve added but OK, I’ll tell them. At least, I’ve prevented my table to lose data if it is not correctly managed by some applications. This is the code:

1
2
3
4
5
6
7
8
9
10
11

DELIMITER //
 
DROP TRIGGER IF EXISTS no_deletion_data;
 
CREATE TRIGGER no_deletion_data
  BEFORE DELETE ON `Data`
  FOR EACH ROW BEGIN
    INSERT INTO `Data` VALUES();
  END;//
 
DELIMITER ;

I know is not the smartest way to solve the problem, but at least is the cleanest I’ve got. Any suggestions? Well, at least, it works!

Notice: Article only available in Spanish!

Hemos visto en publicaciones anteriores cómo conectar a una base de datos mysql desde php, y cómo usar la función mysql_query para consultar datos. También hemos visto algunas nociones de seguridad en scripts y aplicaciones php. Ahora vamos a ver cómo encapsular estas funciones en una práctica clase que nos permitirá instanciar objetos dbhandler y trabajar cómodamente con ellos.

Parto de que el lector conoce el paradigma de la Programación Orientada a Objetos. Básicamente, una clase es un molde que tiene ciertas peculiaridades como métodos y atributos, que pueden ser públicos (de libre acceso) o privados (sólo accesibles dentro de la propia clase). Con esta clase, se pueden instanciar objetos pertenecientes a dicha clase. si estuviéramos en la arena de la playa con un cubo, el cubo sería la clase, y las torres de arena serían los objetos o instancias del cubo de playa.

Las clases tienen una sintaxis especial, se trabaja con ellas de un modo distinto a como hacemos con la programación estructurada. Veamos un ejemplo:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

public class dbhandler
{
  //
  var $user;
  var $pass;
  var $host;
  var $database;
  var $identifier;
  var $results;
  var $resultset;
  var $query;
  //
 
  /** 
   * constructor. initializes the object
   */
  public function dbhandler($user = "", $pass = "", $database = "" , $host="localhost")
  {
    if ($user == "" || $pass == "" || $database == "")
    {
      return(null);
    }
    $this->user     = $user;
    $this->pass     = $pass;
    $this->host     = $host;
    $this->database = $database;
  }
 
}

Es decir, todo objeto de la clase dbhandler almacenará unos valores como clave, usuario, base de datos y host, lo que nos permitirá tener varios manejadores apuntando a distintas bases de datos, a distintos servidores en distintas máquinas, o autenticados con distintos usuarios con distintos permisos; esto nos deja la puerta abierta para usar esta clase en entornos bastante versátiles.

Ya tenemos lo que la clase debe ‘saber’. Ahora queremos que haga cosas. Queremos que se conecte, queremos que seleccione la base de datos, queremos que permita desconectar y queremos que lea una tabla concreta. Vamos con los métodos:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61

/**
 * connect to server
 */
function connect()
{
  $this->identifier= @mysql_connect ($this->host,$this->user,$this->pass)
    or die("Error connecting to database with user ".$this->user . mysql_error());
}
 
/**
 * select database
 */
function selectDB()
{
  @mysql_select_db($this->database,$this->identifier)
    or die("Error selecting database: ".$this->database);
}
 
/**
 * retrieves data from the selected fields of a certain table
 * @param table to read from
 * @param fields to be retrieved
 */
function readTable($table,$fields)
{
  //variables
  $resultsArray = array();
 
  //fields
  $fieldsList = "";
  foreach($fields as $key=>$value)
  {
    $fieldsList .= $value . ",";
  }
 
  //remove last comma
  $fieldsList = substr($fieldsList,0,strlen($fieldsList)-1);
 
  //query
  $this->query = "SELECT " . $fieldsList . " FROM " . $table;
  $this->resultset = @mysql_query($this->query,$this->identifier);
  $this->results = @mysql_num_rows($this->resultset);
 
  if ( $this->results > 0)
  {
    while ($result = mysql_fetch_array($this->resultset))
    {
      $resultsArray[] = $result ;
    }
  }
 
  return($resultsArray);
}
 
/**
 * close connection and free resources
 */
function disconnect()
{
  mysql_close($this->identifier);
}

Como acabamos de ver, a las variables de la clase o atributos se les llama mediante $this->nombredeatributo, siendo $this el objeto actual, instanciado de la clase dbhandler. Para llamar a los métodos de la clase, igualmente usaremos $this->nombredemetodo(); por ejemplo ahora que hemos definido métodos para conectar y seleccionar la base de datos, podemos hacer esto automáticamente cada vez que se crea un objeto de la clase dbhandler. ¿Cómo? poniendo las correspondientes lí­neas en el constructor, por supuesto.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

/**
 * constructor. initializes object
 */
public function dbhandler($user = "", $pass = "", $database = "" , $host="localhost")
{
  if ($user == "" || $pass == "" || $database == "")
  {
    return(null);
  }
 
  $this->user     = $user;
  $this->pass     = $pass;
  $this->host     = $host;
  $this->database = $database;
 
  $this->connect();
  $this->selectDB();
}

Esto nos da una idea de lo cómodo que va a ser trabajar con clases a partir de ahora. Puesto que los atributos $database, $host, $user, $pass, etc., son comunes para todos los métodos de la clase, no necesitan ser pasados como parámetros en las funciones, lo que agiliza mucho la programación y permite código más legible. Ya tenemos nuestra clase con atributos y métodos definida, ahora tenemos que usarla. Si guardamos todo el código de la clase en un archivo llamado class.dbhandler.php, podemos crear un script que lo use del siguiente modo:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

/** 
 * script to connect to a database and read data from tables, with classes
 * @author Jorge Albaladejo Pomares [correo@jorgealbaladejo.com]
 * @license Creative Commons License http://creativecommons.org/licenses/by-sa/3.0/
 */
 
//main classes
include('class.dbhandler.php');
 
//main script
$db      = new dbhandler('john_smith','h01y_GRail','pastafarian_food','localhost');
$fields  = array('id', 'name', 'special_powers');
$results = $db->readTable('superheroes',$fields,$token);
 
foreach($results as $result)
{
  echo 'id => ' . $result['id'] . '<br />';
  echo 'title => ' . $result['title'] . '<br />';
}
echo '<br />';
$db->disconnect();

Y la clase dbhandler finalmente quedará así­:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105

/** 
 * class to handle database connections and reading from tables
 * @author Jorge Albaladejo Pomares [correo@jorgealbaladejo.com]
 * @license Creative Commons License http://creativecommons.org/licenses/by-sa/3.0/
 */
 
public class dbhandler
{
  //
  var $user;
  var $pass;
  var $host;
  var $database;
  var $identifier;
  var $results;
  var $resultset;
  var $query;
  //
 
  /**
   * constructor. initializes object
   * @param user
   * @param pass
   * @param database
   * @param host
   */
  public function dbhandler($user = "", $pass = "", $database = "" , $host="localhost")
  {
    if ($user == "" || $pass == "" || $database == "")
    {
      return(null);
    }
 
    $this->user     = $user;
    $this->pass     = $pass;
    $this->host     = $host;
    $this->database = $database;
 
    $this->connect();
    $this->selectDB();
  }
 
  /**
   * connect to server
   */
  function connect()
  {
    $this->identifier= @mysql_connect ($this->host,$this->user,$this->pass)
      or die("Error connecting to database with user '".$this->user . "': " . mysql_error());
  }
 
  /**
   * select database
   */
  function selectDB()
  {
    @mysql_select_db($this->database,$this->identifier)
      or die("Error selecting database: ".$this->database);
  }
 
  /**
   * queries the selected fields from a certain table in the database
   * @param table
   * @param fields
   */
  function readTable($table,$fields)
  {
    //variables
    $resultsArray = array();
 
    //fields
    $fieldsList = "";
    foreach($fields as $key=>$value)
    {
      $fieldsList .= $value . ",";
    }
 
    //remove last comma
    $fieldsList = substr($fieldsList,0,strlen($fieldsList)-1);
 
    //query
    $this->query = "SELECT " . $fieldsList . " FROM " . $table;
    $this->resultset = @mysql_query($this->query,$this->identifier);
    $this->results = @mysql_num_rows($this->resultset);
 
    if ( $this->results > 0)
    {
      while ($result = mysql_fetch_array($this->resultset))
      {
        $resultsArray[] = $result ;
      }
    }
 
    return($resultsArray);
  }
 
  /**
   * close connection and free resources
   */
  function disconnect()
  {
    mysql_close($this->identifier);
  }
 
}

Esta clase se puede completar añadiendo métodos para todo tipo de propósitos: búsquedas sobre la base de datos, consulta de datos según orden y paginación, se le puede implementar un método que devuelva los resultados en html o xml en lugar de devolverlos en un array, se le puede añdir un destructor que se encargue de liberar los recursos cuando se deja de utilizar el objeto…

1
2
3
4
5
6
7
8

/** 
 * destruct
 */
function destroy() 
{
  $this->disconnect();
  //settype(&$this, 'null'); //may not work with php4
}

Y lo mejor de todo, podemos reutilizar fácilmente el código para cualquiera de nuestras aplicaciones. Y podemos escribir aplicaciones de una forma muchísimo más sencilla y cómoda que con programación estructurada. En general, todo son ventajas

Notice: article only available in Spanish!

Ya he explicado en otro post cómo conectar a una base de datos mysql desde php. Ahora voy a explicar cómo trabajar con esta base de datos, en concreto mostrar los datos de una tabla.

Parto de la premisa de que se ha aprendido a utilizar el script anteriormente citado para la conexión y selección de base de datos, y que se ha configurado correctamente para acceder a una BD donde existe la tabla ‘superheroes’, con los campos ‘id’, ‘name’, ‘special_powers’.

Vamos allá : leemos los datos de la tabla. Para ello, usamos la función php mysql_query(); para ejecutar código sql en el servidor de bases de datos. Vamos a leer los campos importantes (en este caso, los tres) de la tabla superheroes.

1
2
3
4
5
6
7
8
9

$query = "SELECT id, name, special_powers FROM superheroes";
$resultset = @mysql_query($query,$identifier);
if (@mysql_num_rows($resultset) > 0)
{
  while ($result = mysql_fetch_array($resultset))
  {
    echo $result['id'] . ' | ' . $result['name'] . ' | ' . $result['special_powers'] . '<br />'  ;
  }
}

Una vez hemos leído los datos podemos inmediatamente mostrarlos por pantalla, o almacenarlos en una matriz asociativa para emplearlos más adelante. Por ejemplo, cambiando el código

1
2
3
4

while ($result = mysql_fetch_array($resultset))
{
  echo $result['id'] . ' | ' . $result['name'] . ' | ' . $result['special_powers'] . '<br />'  ;
}

por

1
2
3
4
5
6

$i = 0;
while ($result = mysql_fetch_array($resultset))
{
  $resultsArray[$i] = $result  ;
  $i++;
}

de modo que más adelante podremos mostrar estos datos como mejor nos convenga.

Hay que tener en cuenta que el script de conexión a base de datos que ya vimos, abre y cierra la conexión en un mismo paso. Por tanto, ahora tendremos que integrarlo con la parte de lectura de datos que acabamos de ver. El código resultante quedará así­:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

/** 
 * script to connect to a database and read tables
 * @author Jorge Albaladejo Pomares [correo@jorgealbaladejo.com]
 * @license Creative Commons License http://creativecommons.org/licenses/by-sa/3.0/
 */
 
//variables
$host = "localhost";
$user = "john_smith";
$pass = "h01y_GRail";
$db   = "pastafarian_food";
 
//connection
$identifier = @mysql_connect ($host,$user,$pass);
if (!$identifier)
{
  die("Error connecting to database: ".mysql_error());
}
 
//selecting the database
$db_selected = mysql_select_db ( $db, $identifier );
if (!$db_selected)
{
  die ("Cannot select database: " . mysql_error());
}
 
$query     = "SELECT id, name, special_powers FROM superheroes";
$resultset = @mysql_query($query,$identifier);
 
if (@mysql_num_rows($resultset) > 0)
{
  while ($result = mysql_fetch_array($resultset))
  {
    echo $result['id'] . ' | ' . $result['name'] . ' | ' . $result['special_powers'] . '<br />' ;
  }
}
 
//close connection
mysql_close($identifier);

Como vemos, el código queda un poco sucio, así que lo vamos a organizar un poquito creando tres funciones: la primera, conectará con la base de datos, la segunda, leerá la tabla, y la tercera realizará la conexión. Vamos allá.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98

/** 
 * script to connect to a database and read from tables, organized with functions
 * @author Jorge Albaladejo Pomares [correo@jorgealbaladejo.com]
 * @license Creative Commons License http://creativecommons.org/licenses/by-sa/3.0/
 */
 
/**
 * Connect to a database with default parameters
 * @return the connection identifier
 */
function connect()
{
  //variables
  $host = "localhost";
  $user = "john_smith";
  $pass = "h01y_GRail";
  $db   = "pastafarian_food";
  //
 
  //connection
  $identifier = @mysql_connect ($host,$user,$pass);
  if (!$identifier)
  {
    die("Error connecting to database: ".mysql_error());
  }
 
  //selecting database
  $db_selected = mysql_select_db ( $db, $identifier );
  if (!$db_selected)
  {
    die ("Cannot select database: " . mysql_error());
  }
 
  return($identifier);
}
 
/** 
 * retrieves the selected fields from a certain table in a database
 * @param table to retrieve from
 * @param fields to retrieve
 */
function readTable($table,$fields,$identifier)
{
  //variables
  $resultsArray = array();
 
  //fields
  $fieldsList = "";
  foreach($fields as $key=>$value)
  {
    $fieldsList .= $value . ",";
  }
 
  //remove last comma
  $fieldsList = substr($fieldsList,0,strlen($fieldsList)-1);
 
  //query
  $query = "SELECT " . $fieldsList . " FROM " . $table;
  $resultset = @mysql_query($query,$identifier);
  if (@mysql_num_rows($resultset) > 0)
  {
    $i = 0;
    while ($result = mysql_fetch_array($resultset))
    {
      $resultsArray[$i] = $result  ;
      $i++;
    }
  }
 
  return($resultsArray);
}
 
/** 
 * closes connection and frees resources
 * @param identifier of the connection to close
 */
function disconnect($identifier)
{
  //TODO: some routines to clean resources, data, variables, etc.
  mysql_close($identifier);
}
 
/**
 * main script 
 */
$token   = connect();
$fields  = array('id', 'name', 'special_powers');
$results = readTable('superheroes',$fields,$token);
 
foreach($results as $result)
{
  foreach($fields as $key)
  {
    echo $key . " => " . $result[$key] . "<br />";
  }
  echo "<br />";
}
disconnect($token);

Hecho esto, lo más práctico es almacenar las funciones que acabamos de crear en un archivo externo de librerías y funciones útiles, y así reducir al mínimo el tamaño de nuestro script. En este ejemplo, las funciones connect(), readTable() y disconnect() han sido movidas a un archivo llamado functions.php en el mismo directorio que el script principal. El código finalmente queda como sigue­:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

/** 
 * script to connect to a database and read from tables, organized with functions
 * @author Jorge Albaladejo Pomares [correo@jorgealbaladejo.com]
 * @license Creative Commons License http://creativecommons.org/licenses/by-sa/3.0/
 */
 
//main functions
include('functions.php');
 
// main script
$token   = connect();
$fields  = array('id', 'name', 'special_powers');
$results = readTable('superheroes',$fields,$token);
 
foreach($results as $result)
{
  foreach($fields as $key)
  {
    echo $key . " => " . $result[$key] . "<br />";
  }
  echo "<br />";
}
disconnect($token);

Hay que tener en cuenta que este script puede ser inseguro si se le ataca con sql injection, de esto hablaré más adelante en otras publicaciones.

Notice: Article only available in Spanish!

El primer paso para trabajar con scripts y aplicaciones en php que conectan con bases de datos mysql, es crear una conexión. Una conexión en php devuelve un identificador que será utilizado para cada transacción, consulta, etc, que se realice sobre la base de datos.

Para comenzar, hacen falta tres datos del proveedor de servicios de alojamiento: nombre de la base de datos, nombre de usuario y contraseña de acceso. En php desde la versión 3 existe la función mysql_connect();

mysql_connect($host,$usuario,$clave);

Donde host suele ser ‘localhost’ (a menos que se quiera conectar a bases de datos en distintas máquinas, en cuyo caso el proveedor de servicio debe proporcionar este dato), y usuario y clave son los datos de acceso a dicho servidor de base de datos.

Una vez establecida la conexión, se obtiene un identificador que se usará en cada operación que se realice sobre la base de datos. El siguiente paso es seleccionar una base de datos. Ésta debe haber sido creada de antemano, y el usuario con el que se realiza la conexión debe tener permisos de acceso a ella.

1
2

$identifier = mysql_connect($host,$usuario,$clave);
mysql_select_db ( $database , $identifier );

Por último, una vez terminada la ejecución, hay que liberar los recursos utilizados cerrando la conexión

1

mysql_close ($identifier);

A partir de ahora, todas las consultas realizadas se efectuarán sobre la base de datos seleccionada. Un script completo para conexión a base de datos quedaría como sigue:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

/**
 * script to connect to a database
 * @author Jorge Albaladejo Pomares [correo@jorgealbaladejo.com]
 * @license Creative Commons License http://creativecommons.org/licenses/by-sa/3.0/
 */
 
//variables
$host = "localhost";
$user = "john_smith";
$pass = "h01y_GRail";
$db   = "pastafarian_food";
 
//connection
$identifier = @mysql_connect ($host,$user,$pass);
if (!$identifier)
{
  die("Error connecting to database: ".mysql_error());
}
 
//selecting database
$db_selected = mysql_select_db ( $db, $identifier );
if (!$db_selected)
{
  die ("Cannot use database: " . mysql_error());
}
 
//Close connection
mysql_close($identifier);