Posts Tagged ‘bases de datos’

Report in .NET using Crystal Reports and MySQL database.

Martes, Diciembre 9th, 2008

This is just the first of some English posts that I'll publish by translating most popular posts in this blog. Original version (in Spanish) is here.

First of all, I must asume that creating reports is one of that things I like worst in programming. But it's quite obvious that few serious applications don't need them, and the one I'm developing now isn't an exception to this rule. So I've been creating some reports recently and I've discovered a new way to do it. And that's what I explain in this post.

As I've said sometimes before in previous posts, I develop with VisualBasic.NET and MySQL database. And I use Crystal Reports to create reports, as this tool is integrated in VisualStudio.NET. Since now, I used to use an ODBC connection configured in each PC to connect to MySQL server. But I didn't like this system much, because actually I'm not working just with one database but with some with different names. They have the same structure, tables and data, but just one is the good one, as the rest are just for developing purposes. It's really easy to use one or other connection string to make the application connect with one or other database, but with reports it isn't so easy as they take data using that ODBC connection (and it just can connect with one database).

But now I've discovered how to create reports with just a DataTable and an XML schema, needing nothing else. Actually it's possible to use a DataSet instead of a DataTable as well. So I'm going to explain it with an easy example and some images.

I'll work with two tables in my MySQL database where I'll keep information about bills. First table is the one with information about headers and has this data:

+---------+------------+-------------------------+
| blh_num | blh_dat    | blh_cus                 |
+---------+------------+-------------------------+
|       1 | 2008-07-30 | CERAMICAS PEPE, S.A.    |
|       2 | 2008-07-30 | TALLERES GOMEZ, S.L.    |
|       3 | 2008-07-31 | DEPORTES DAMIAN, S.L.   |
|       4 | 2008-07-31 | SOFTWARE ALBERTMATA.NET |
+---------+------------+-------------------------+

Second table is the one with information about positions and has this rows:

+---------+---------+------------------------+---------+---------+
| blp_num | blp_pos | blp_art                | blp_pri | blp_qty |
+---------+---------+------------------------+---------+---------+
|       1 |       1 | RATON LOGITECH         |   15.95 |       1 |
|       2 |       1 | MONITOR LG 19 PULGADAS |   210.5 |       1 |
|       3 |       1 | ROUTER DLINK           |      56 |       1 |
|       4 |       1 | RATON LOGITECH         |   15.95 |       2 |
|       4 |       2 | TECLADO LOGITECH       |   12.95 |       1 |
|       4 |       3 | RECEPTOR GPS ZAPPA     |   59.95 |       1 |
|       4 |       4 | PAQUETE 500 FOLIOS     |     3.7 |       4 |
+---------+---------+------------------------+---------+---------+

It's something really simple and not normalized, but will be enough for this example, as we're going to create a report that will be the inovice for purchase number 4 (the one with customer SOFTWARE ALBERTMATA.NET). Obviously, we'll need information about both tables but I just want to work with one DataTable, so first of all I'm going to create a MySQL view with this sentence:

CREATE VIEW zbl_bill2print AS 
(
SELECT
    blh_num AS BILL_NUMBER,
    blh_dat AS BILL_DATE,
    blh_cus AS BILL_CUSTOMER,
    blp_pos AS LINE_NUMBER,
    blp_art AS LINE_ARTICLE,
    blp_pri AS LINE_UNITPRICE,
    blp_qty AS LINE_UNITS,
    blp_pri * blp_qty AS LINE_TOTALPRICE
FROM
    blh_billheader LEFT JOIN blp_billposits ON blh_num = blp_num
WHERE
    blh_num = 4
);

So, from now on the report will be created using this zbl_bill2print view. Let's go with the .NET part.

Step 1. Creating XML file containing table/view structure.

Along this post we'll work with these three things:

1) a Windows form (frmMain) where we'll have the report viewer object.
2) a class (clsReportCreator) we're going to create right now.
3) a report (rptBill) that will be the invoice we want to print.

So let's start creating clsReportCreator class. It'll have only one attribute (the name of the table or view), one constructor method, one method to load DataTable object and one last method to generate the XML file. Here is the full code for this class:

'--------------------------------------------------------------------
' Author:      Albert Mata (www.albertmata.net)
' Date:        20080731
' Needs:       MySQL.Data reference.
' Description: Class to create a report using just an XML file. 
'--------------------------------------------------------------------
Imports MySql.Data.MySqlClient

Public Class clsReportCreator

    '----------------------------------------------------------------
    ' Attributes.
    '----------------------------------------------------------------
    Private TableOrView As String

    '----------------------------------------------------------------
    ' Constructor method.
    '----------------------------------------------------------------
    Public Sub New(ByVal TableOrView As String)
        Me.TableOrView = TableOrView
    End Sub

    '----------------------------------------------------------------
    ' Returns DataTable corresponding to TableOrView.
    '----------------------------------------------------------------
    Public Function GetDataTable() As DataTable
        Dim DA As MySqlDataAdapter
        Dim DS As New DataSet
        Dim DT As DataTable
        Dim ConnectionString As String
        Dim SQL As String

        'Setting connection string to connect to MySQL database.
        ConnectionString = "Database = blog; " _
                         & "Data Source = localhost; " _
                         & "User ID = root; " _
                         & "Password = mypassword"

        'Setting SQL string.
        SQL = "SELECT * FROM " & Me.TableOrView

        'Getting data and filling DataSet and DataTable.
        DA = New MySqlDataAdapter(SQL, ConnectionString)
        DA.Fill(DS, Me.TableOrView)
        DT = DS.Tables(Me.TableOrView)

        'Returning DataTable.
        Return DT
    End Function

    '----------------------------------------------------------------
    ' Creates XML file in desired path.
    '----------------------------------------------------------------
    Public Sub CreateXMLFile(ByVal FilePath As String)
        Dim DT As DataTable

        'Creating DataTable.
        DT = Me.GetDataTable()

        'Writting XML file in desired path.
        DT.WriteXmlSchema(FilePath & Me.TableOrView & ".xml")
    End Sub

End Class

And we also create frmMain form, which only code by the moment will be this:

'--------------------------------------------------------------------
' Author:      Albert Mata (www.albertmata.net)
' Date:        20080731
' Description: Form to show how to create a report using just an XML
'              file. 
'--------------------------------------------------------------------
Public Class frmMain

    '----------------------------------------------------------------
    ' As a first step, creates XML file.
    '----------------------------------------------------------------
    Private Sub frmMain_Load(ByVal sender As System.Object, _
    ByVal e As System.EventArgs) Handles MyBase.Load
       'Creating XML file.
        Dim RC As New clsReportCreator("zbl_bill2print")
        RC.CreateXMLFile("C:\")
    End Sub

End Class

Right now we have a first application. If we execute it we'll get C:\zbl_bill2print.xml file with the structure of zbl_bill2print view. So we run it and get that file.

Step 2. Creating report and loading data source.

First, we add a report to our project and give it a name like rptBill.rpt. We create it choosing empty report option, so desestimating any templates.

Now we go to Fields explorer menu and right-click the first option (Database fields). In new contextual menu we click on Database assistant option.

After this we get the Available data source menu, where we choose Create new connection and after that ADO.NET option.

Making this, we'll see a new form where we'll be asked about File's path. In this point we have to find XML file we've created before (in my example C:\zbl_bill2print.xml) and then press Finish. We have NewDataSet option including our just added zbl_bill2print in Available data source menu now.

So we select it and press button to move it to Selected tables menu. Done this, it's time to click on Accept.

With all this stuff we've gotten that zbl_bill2print structure available in Fields explorer menu with all its fields, as shown in image below:

Step 3. Designing report.

Nothing special to say here. Just adding fields from Fields explorer menu, inserting text objects where needed, sums, text formats, images and so on...

I've just created a very simple design like this:

Step 4. Last actions to get the invoice.

Finally we're going to create the bill. To do that, we add a CrystalReportViewer object in frmMain form. I call it crvBill. After that it's necessary to modify frmMain source code to make it look like this:

'--------------------------------------------------------------------
' Author:      Albert Mata (www.albertmata.net)
' Date:        20080731
' Description: Form to show how to create a report using just an XML
'              file. 
'--------------------------------------------------------------------
Imports CrystalDecisions.CrystalReports.Engine

Public Class frmMain

    '----------------------------------------------------------------
    ' Creates XML file (just once) and creates and loads a report.
    '----------------------------------------------------------------
    Private Sub frmMain_Load(ByVal sender As System.Object, _
    ByVal e As System.EventArgs) Handles MyBase.Load
        'Creating XML file.
        Dim RC As New clsReportCreator("zbl_bill2print")
        'RC.CreateXMLFile("C:\")

        'Creating report.
        Dim RD As ReportDocument = New rptBill()

        'Setting data source for report.
        Dim DT As DataTable = RC.GetDataTable()
        RD.SetDataSource(DT)

        'Setting data source for possible subreports.
        For Each SR As ReportDocument In RD.Subreports
            If SR.Database.Tables.Count > 0 Then
                SR.SetDataSource(DT)
            End If
        Next

        'Setting recently created report must be shown in viewer.
        Me.crvBill.ReportSource = RD
    End Sub

End Class

It's important to note that the line where the XML file is created is commented now, as we just need to create this file once to use it to create the source data, but from now on we don't need to generate it every time.

What we're mainly doing in this code is:

1) creating a report object same kind we've designed in step 3,
2) getting a DataTable with data we want to show (in this example and according to the way we've defined MySQL view, we want to show invoice number 4),
3) setting this DataTable as the report's source data,
4) asking CrystalReportViewer to show this report.

We execute the application again and get desired invoice:

Of course there should be quite more information, images and legal texts in a real invoice, but this is just an easy example of how to do the report itself.

So we've seen how to create a report in VisualBasic.NET just using an XML file. Of course there are plenty of things to improve, as optimizing how database connection is done, or avoiding WHERE condition directly in MySQL view and so on... but what I was looking for with this example was just a very minimum guide to show the process.

PS. Some menu and option names can be different as I develope in VisualStudio Spanish version and I've just translated them as I've thought they could appear in English version. Sorry about that!

Update.

There is a second part for this post explaining how to pass parameters from form to report, but it's still only in Spanish.

MySQL no admite TRANSFORM PIVOT (pero se pueden obtener resultados parecidos).

Jueves, Noviembre 27th, 2008

Estos últimas días he estado mirando un tema que me preocupaba porque iba a necesitarlo en la aplicación que ando desarrollando... y tras no haber encontrado nada, finalmente me he tenido que poner a fondo con ello hasta sacarlo de una u otra manera. El tema consiste en hacer una consulta de referencias cruzadas en MySQL y, como digo, tras bastante investigar he descubierto que en realidad MySQL no admite esta clase de consultas. Para explicar mejor lo que pretendía hacer voy a basarme en un ejemplo consistente en la siguiente tabla sfc_salefrcast:

+---------+---------+------------+---------+
| sfc_cus | sfc_mat | sfc_mth    | sfc_qty |
+---------+---------+------------+---------+
| 12345   |       1 | 2008-11-01 |    1200 |
| 12345   |       3 | 2008-11-01 |    1500 |
| 54321   |       2 | 2008-11-01 |    2500 |
| 54321   |       3 | 2008-12-01 |    3500 |
| 54321   |       3 | 2009-03-01 |    4500 |
| 54321   |       3 | 2009-07-01 |    4500 |
| 99999   |       4 | 2009-02-01 |    2000 |
| 99999   |       4 | 2009-04-01 |    4000 |
| 99999   |       4 | 2009-06-01 |    6000 |
+---------+---------+------------+---------+

Es una tabla de previsiones de ventas en donde sfc_cus es el código del cliente, sfc_mat el código del material, sfc_mth el mes representado por su primer día y sfc_qty la cantidad que prevemos que vamos a venderle de dicho material a dicho cliente dicho mes (y dichosos nosotros si acertamos).

Bien, pues a partir de esta tabla pretendía conseguir una tabla (o vista... un conjunto de registros, vamos) en la que en cada registro se me mostrara una combinación de cliente y material, y a partir de aquí una columna para cada mes con la cantidad correspondiente. Algo del estilo de lo siguiente...

+---------+---------+------+------+------+------+------+------+
| sfc_cus | sfc_mat | M0   | M1   | M2   | M3   | M4   | M5   |
+---------+---------+------+------+------+------+------+------+
| 12345   |       1 | 1200 |    0 |    0 |    0 |    0 |    0 |
| 12345   |       3 | 1500 |    0 |    0 |    0 |    0 |    0 |
| 54321   |       2 | 2500 |    0 |    0 |    0 |    0 |    0 |
| 54321   |       3 |    0 | 3500 |    0 |    0 | 4500 |    0 |
| 99999   |       4 |    0 |    0 |    0 | 2000 |    0 | 4000 |
+---------+---------+------+------+------+------+------+------+

...en donde M0 es el mes actual (2008-11-01), M1 es el mes próximo, M2 el siguiente, etc.

Pues bien, si estuviéramos trabajando en Microsoft Access podríamos hacer algo simple como...

TRANSFORM SUM(sfc_qty) 
    SELECT sfc_cus, sfc_mat
    FROM sfc_salefrcast
    GROUP BY sfc_cus, sfc_mat
PIVOT sfc_mth;

...y obtendríamos algo muy parecido al resultado deseado. Simplemente no nos mostraría las columnas donde no haya ningún valor que mostrar (como M2), pero sería un problema muy menor que solventaríamos sin dificultad. En Microsoft Excel también sería sencillísimo obtener esos resultados a través de una tabla dinámica.

No obstante, trabajo con MySQL. Y por desgracia MySQL no admite TRANSFORM-PIVOT. De hecho no he encontrado ninguna alternativa atractiva para resolver mi problema, de modo que he tenido que rascar un poquito y crear una a medida, que me ha quedado así:

SELECT
    sfc_cus,
    sfc_mat,
    SUM(IF(MID(sfc_mth, 1, 7) = MID(NOW(), 1, 7), sfc_qty, 0)) AS M0,
    SUM(IF(MID(sfc_mth, 1, 7) = 
           MID(DATE_ADD(NOW(),INTERVAL 1 MONTH), 1, 7), 
           sfc_qty, 0))                                        AS M1,
    SUM(IF(MID(sfc_mth, 1, 7) = 
           MID(DATE_ADD(NOW(),INTERVAL 2 MONTH), 1, 7), 
           sfc_qty, 0))                                        AS M2,
    SUM(IF(MID(sfc_mth, 1, 7) = 
           MID(DATE_ADD(NOW(),INTERVAL 3 MONTH), 1, 7), 
           sfc_qty, 0))                                        AS M3,
    SUM(IF(MID(sfc_mth, 1, 7) = 
           MID(DATE_ADD(NOW(),INTERVAL 4 MONTH), 1, 7), 
           sfc_qty, 0))                                        AS M4,
    SUM(IF(MID(sfc_mth, 1, 7) = 
           MID(DATE_ADD(NOW(),INTERVAL 5 MONTH), 1, 7), 
           sfc_qty, 0))                                        AS M5
FROM
    sfc_salefrcast
GROUP BY 
    sfc_cus, sfc_mat;

(Ver actualización 1.)

Al no utilizar directamente fechas sino estar jugando con NOW() y la función DATE_ADD, obtenemos siempre resultados para el mes corriente y los siguientes N meses, independientemente de cuando solicitemos esa información a la base de datos.

Ignoro si hay alguna manera más directa de hacerlo (y si la hay y la conoces, estaré encantadísimo de leerla), pero por lo pronto lo he solucionado así...

Actualización.

1. Siguiendo el consejo -uno de ellos- de Luís Medel en los comentarios, he cambiado la versión original que había publicado para dejar esta más simplificada al realizar en un solo paso el sumatorio y el filtrado. Además, Luís propone utilizar CASE WHEN THEN ELSE END en lugar de IF.

2. Pedro Cambra facilita en los comentarios un link a la página de Roland Bouman donde se expone un método para hacerlo de forma dinámica utilizando procedimientos almacenados.

3. Pedro Cambra comenta también que MySQL dispone de la función EXTRACT con el parámetro YEAR_MONTH que efectivamente se podría utilizar para mejorar el apartado del MID(fecha,1,7). Más información en el manual de referencia de MySQL.

Pinceladas de álgebra relacional.

Domingo, Octubre 12th, 2008

Hoy algo de teoría. Como sabemos, el lenguaje estándar para realizar consultas en bases de datos es el SQL (Structured Query Language). Este lenguaje permite definir y manipular bases de datos relacionales, que son las bases de datos con las que solemos trabajar (como MySQL, Oracle, SQL Server y demás). Hay otro tipo de bases de datos que no son relacionales, pero su uso a día de hoy es tremendamente minoritario.

En una base de datos relacional la información está estructurada en forma de relaciones (ojo, no confundirse, en este ámbito 'relación' equivale a lo que habitualmente llamamos 'tabla') dando lugar a lo que se conoce como modelo relacional. En este modelo relacional las consultas se pueden llevar a cabo con lenguajes relacionales de dos tipos:

1) Lenguajes basados en álgebra relacional, que se inspira en la teoría de conjuntos para ir construyendo paso a paso el procedimiento a seguir para obtener los datos deseados. Estos lenguajes son lenguajes, pues, procedimentales.

2) Lenguajes basados en el cálculo relacional, que se basa en el cálculo de predicados de la lógica matemática. Estos lenguajes no describen un procedimiento y por tanto se les llama lenguajes declarativos (no procedimentales).

SQL es un lenguaje mixto, ya que incluye temas de álgebra relacional y otros de cálculo relacional, aunque predominan estos últimos, por lo que se considera un lenguaje declarativo. No obstante, hoy vamos a ver algunas pinceladas básicas de álgebra relacional.

Para especificar una consulta en álgebra relacional hay que ir siguiendo una serie de pasos que sirven para ir construyendo nuevas relaciones (recordemos: análogas a las tablas) a partir de las relaciones existentes. En estos pasos se utilizan las operaciones del álgebra relacional, que resumidas de un modo muy escueto son las siguientes.

0. Renombramiento.

Se trata de una operación que nos facilita trabajar con relaciones cambiándoles el nombre a ellas o a sus atributos. Así...

R (h) := RelacionConNombreOriginal (AtributoConNombreOriginal)

...renombra la relación a 'R' y uno de sus atributos a 'h' (del mismo modo que relaciones vienen a ser lo que habitualmente llamamos tablas, atributos vienen a ser lo que llamamos campos o columnas en esas tablas).

1. Unión.

Se trata de generar una nueva relación juntando todas las tuplas (tuplas = registros) de las dos relaciones que intervienen en la unión. Está claro que las dos relaciones deberán tener estructuras semejantes. Además, como en una relación (como en una tabla) no puede haber tuplas (registros) duplicadas, si al unirlas se da alguna duplicidad, se elimina directamente. Se denota con...

R := T U S

...donde 'U' representa el símbolo de unión y 'T' y 'S' son las relaciones de partida.

2. Intersección.

Se trata de generar una nueva relación con las tuplas que aparecen a la vez en las dos relaciones que intervienen en la intersección. También aquí las dos relaciones deberán tener estructuras semejantes. Se denota con...

R := T (U) S

...donde '(U)' pretende ser el símbolo de intersección ('U' invertida) que no sé cómo representar aquí en el blog y 'T' y 'S' son las relaciones de partida.

3. Diferencia.

Se trata de generar una nueva relación con las tuplas que aparecen en una primera relación pero no en una segunda. Nuevamente ambas relaciones deben tener estructuras semejantes. Se denota con...

R := T - S

...donde 'T' y 'S' son las relaciones de partida.

4. Producto cartesiano.

Se trata de generar una nueva relación combinando cada una de las tuplas de una primera relación con cada una de las tuplas de una segunda relación. Así pues la relación resultante tendrá tantos atributos como la suma de los atributos de cada una de las relaciones de partida. Y tendrá tantas tuplas como el producto de tuplas de ambas relaciones. Se denota con...

R := T x S

...donde 'T' y 'S' son las relaciones de partida.

5. Selección.

Se trata de generar una nueva relación con un subconjunto de las tuplas de la relación de partida. Para ello es preciso expresar alguna condición que las tuplas deberán cumplir para formar parte de la nueva relación. Se denota con...

R := T(C)

...donde 'T' es la relación de partida y 'C' la condición (puede ser compuesta) que deben cumplir las tuplas de 'T' para formar parte de 'R'.

6. Proyección.

Se trata de generar una nueva relación con sólo algunos de los atributos de los que consta la relación de partida. Se denota con...

R := T [A1, A2, A3...]

...donde 'T' es la relación de partida y las 'A' representan los atributos que se quieren trasladar a la relación resultante 'R'.

7. Combinación.

Se trata de generar una nueva relación a partir de un producto cartesiano entre dos relaciones de partida, con la salvedad que sólo formarán parte de la nueva relación las tuplas resultantes del producto que cumplan unas determinadas condiciones de igualdad entre atributos. Dios, suena fatal... pero es simplemente un JOIN. Se denota con...

R := T [B] S

...donde 'T' y 'S' son las relaciones de partida y 'B' es el conjunto de condiciones.

8. Combinación natural.

Igual que la combinación, sólo que no es necesario especificar las condiciones 'B' puesto que se asume que los atributos que se quieren igualar son los que se llaman igual en las dos relaciones de partida. Se denota con...

R := T * S

...donde 'T' y 'S' son las relaciones de partida.

Expresado así todo ello suena bastante complejo, la verdad. Pero si conocemos algo de SQL y hemos ido identificando las instrucciones veremos que es mucho más sencillo de lo que parece. Los renombramientos vienen a ser alias, las uniones vienen a ser UNIONs, las selecciones son SELECT * con
cláusulas WHERE, las proyecciones son SELECT con una selección de campos, etc.

Vamos a ver ahora un ejemplo interesante de cómo se construye una consulta con álgebra relacional. Imaginemos que tenemos una relación con las siguientes tuplas (voy a representarlo como tabla con registros para que resulte más familiar):

+-----------------+
|   biblioteca    |
+-------+---------+
| libro | paginas |
+-------+---------+
|   AAA |     125 |
|   BBB |     250 |
|   CCC |     300 |
|   DDD |     105 |
+-------+---------+

Si en SQL quisiéramos saber cuál es el menor número de páginas nos bastaría con hacer...

SELECT MIN(paginas) 
FROM biblioteca;

Y si quisiéramos saber cuál es el libro con ese menor número de páginas tendríamos que hacer...

SELECT libro 
FROM biblioteca 
WHERE paginas = (SELECT MIN(paginas) FROM biblioteca);

¿Pero cómo conseguimos encontrar esto con álgebra relacional donde NO tenemos una maravillosa función MIN()? Tenemos que hacerlo por pasos, más o menos así:

Paso 1.

Obtener una relación sólo con los números de páginas.

R1 := biblioteca [paginas]

+---------+
| paginas |
+---------+
|     125 |
|     250 |
|     300 |
|     105 |
+---------+
Paso 2.

Renombrar esta relación para poder llevar a cabo el siguiente paso. Podríamos haberlo hecho directamente en el paso 1, pero así queda más claro.

R2 (pags) := R1 (paginas)

+------+
| pags |
+------+
|  125 |
|  250 |
|  300 |
|  105 |
+------+
Paso 3.

Llevar a cabo una combinación entre 'biblioteca' y la recién obtenida 'R2' estableciendo como condición que 'paginas' sea mayor que 'pags'.

R3 := biblioteca [paginas > pags] R2

+-------+---------+------+
| libro | paginas | pags |
+-------+---------+------+
|   AAA |     125 |  105 |
|   BBB |     250 |  125 |
|   BBB |     250 |  105 |
|   CCC |     300 |  125 |
|   CCC |     300 |  250 |
|   CCC |     300 |  105 |
+-------+---------+------+

Como vemos, hemos obtenido una relación donde aparecen todas las combinaciones en que 'paginas' tiene un valor superior a algún valor de 'pags'. En esa relación tenemos pues todos los valores de 'paginas' que son mayores que algún otro valor de 'pags', y por tanto sólo faltan los valores de 'paginas' que no son mayores a ningún otro valor de 'pags' (o sea, los valores mínimos).

Paso 4.

Hacer una proyección para quedarnos sólo con los valores de 'paginas'.

R4 := R3 [paginas]

+---------+
| paginas |
+---------+
|     125 |
|     250 |
|     300 |
+---------+
Paso 5.

Efectuar una diferencia entre los números de páginas de la relación original (lo tenemos en 'R1') y los que acabamos de obtener.

R5 := R4 - R1

+---------+
| paginas |
+---------+
|     105 |
+---------+

¡Bingo! Ya tenemos el valor mínimo de páginas... vamos ahora a terminar encontrando el título del libro con el menor número de páginas...

Paso 6.

Realizar una combinación natural entre la relación original y esta última.

R6 := biblioteca * R5

+-------+---------+
| libro | paginas |
+-------+---------+
|   DDD |     105 |
+-------+---------+
Paso 7.

Y para obtener el título del libro... una última proyección.

R7 := R6 [libro]

+-------+
| libro |
+-------+
|   DDD |
+-------+

Así pues, vemos que para llevar a cabo consultas con álgebra relacional debemos seguir una técnica procedimental en que vamos marcando los pasos que hay que ir siguiendo (haz esto y hazlo así). En cambio con SQL no necesitamos hacerlo de ese modo, ya que como hemos comentado al principio del post SQL es un lenguaje declarativo (haz esto, no me importa cómo lo hagas).

Nunca está de más tener algunas nociones de teoría de bases de datos, ¿no? ;-)

Claves foráneas vs UNIQUE en MySQL.

Domingo, Octubre 5th, 2008

Cuando diseñamos una tabla en MySQL (y en general en cualquier otro SGBD) solemos prestar mucha más importancia a las claves primarias que a las foráneas. Sin embargo las claves foráneas son también muy importantes principalmente por un doble motivo. Por un lado permiten mantener la integridad de la base de datos ante posibles modificaciones o eliminación de datos. Por otro lado aceleran enormemente determinadas combinaciones (joins) de tablas. No obstante, si estamos utilizando MySQL este segundo tema no depende estrictamente de las claves foráneas sino de la unicidad de las claves. Son temas parecidos pero no iguales, ya que para que una campo pueda ser referenciado por la clave foránea de otra tabla debe cumplir el criterio de unicidad, pero que lo cumpla no obliga a que alguna clave foránea tenga que referenciarlo. De esto es de lo que va a tratar este post.

Como el tema va a ser algo complicado de explicar sin unas tablas de datos a las que sujetarnos, voy a partir de tres tablas con las que desarrollaré toda la explicación. Estas tres tablas son las que paso a explicar a continuación.

Tabla de materiales vendidos.
mysql> DESCRIBE mat_materialsx;
+---------+----------------------+------+-----+---------+-------+
| Field   | Type                 | Null | Key | Default | Extra |
+---------+----------------------+------+-----+---------+-------+
| mat_ped | varchar(6)           | NO   | PRI |         |       |
| mat_pos | smallint(5) unsigned | NO   | PRI | 0       |       |
| mat_typ | varchar(6)           | YES  |     | NULL    |       |
| mat_fin | varchar(2)           | YES  |     | NULL    |       |
| mat_qty | double unsigned      | YES  |     | NULL    |       |
+---------+----------------------+------+-----+---------+-------+
5 rows in set (0.01 sec)

Es una tabla que recoge todos los materiales que se han vendido en algún momento a lo largo de la trayectoria de una empresa. Los campos mat_ped y mat_pos son la clave primaria e identifican el número de pedido de venta y la posición dentro de dicho pedido. No afectarán en nada a nuestro desarrollo, así que podemos olvidarnos de ellos. En cambio los restantes campos serán importantes: mat_typ indica el tipo de material, mat_fin indica el acabado de ese material y mat_qty indica el número de kilos vendidos en ese pedido y posición.

Quedará más claro viendo algunos datos que puede contener esta tabla:

mysql> SELECT * FROM mat_materialsx LIMIT 5;
+---------+---------+---------+---------+---------+
| mat_ped | mat_pos | mat_typ | mat_fin | mat_qty |
+---------+---------+---------+---------+---------+
| 100023  |       1 | 430     | XP      |     800 |
| A09085  |       1 | 430     | BA      |    3000 |
| A09086  |       1 | 430     | BA      |    7380 |
| A09138  |       1 | 409     | 2B      |     538 |
| A09139  |       1 | 409     | 2B      |     539 |
+---------+---------+---------+---------+---------+
5 rows in set (0.00 sec)

Lo he limitado a 5 resultados pero en realidad en esta tabla es donde estará el enorme volumen de datos, ya que la tabla entera contendrá...

mysql> SELECT COUNT(*) FROM mat_materialsx;
+----------+
| COUNT(*) |
+----------+
|   177047 |
+----------+
1 row in set (0.06 sec)

El objetivo final que querremos conseguir (para lo cual necesitaremos llevar a cabo una consulta) es una agrupación de esos 177.047 materiales vendidos. Para ello agruparemos tanto los tipos de material como los acabados a través de unas tablas de parametrización en las que le diremos qué tipo de material o qué acabado agrupado corresponden a cada tipo de material o acabado original. Estas dos tablas son las que ahora vemos. Primero la de tipos de material.

Tabla de agregación de tipos de material.
mysql> DESCRIBE typ_alltypesx;
+---------+------------+------+-----+---------+-------+
| Field   | Type       | Null | Key | Default | Extra |
+---------+------------+------+-----+---------+-------+
| typ_bas | varchar(6) | NO   | PRI |         |       |
| typ_agg | varchar(6) | NO   |     |         |       |
+---------+------------+------+-----+---------+-------+
2 rows in set (0.01 sec)

Es una tabla extremadamente simple donde sólo consta el tipo de material básico (el original, el que aparece en los pedidos) y el tipo de material agrupado que le corresponde a cada tipo de material básico.

Algunos datos de los que consta son los siguientes:

mysql> SELECT * FROM typ_alltypesx LIMIT 5;
+---------+---------+
| typ_bas | typ_agg |
+---------+---------+
| 14462   | 524     |
| 202     | 202     |
| 301PK   | 524     |
| 304     | 304     |
| 304/L   | 304     |
+---------+---------+
5 rows in set (0.00 sec)

Así, los materiales 14462 y 301PK quedarán agrupados como material 524. Los 304 y 304/L quedarán como 304. Y así para un total de unos 70 materiales.

Tabla de agregación de acabados.
mysql> DESCRIBE fin_allfinish;
+---------+------------+------+-----+---------+-------+
| Field   | Type       | Null | Key | Default | Extra |
+---------+------------+------+-----+---------+-------+
| fin_bas | varchar(2) | NO   | PRI |         |       |
| fin_agg | varchar(2) | NO   |     |         |       |
+---------+------------+------+-----+---------+-------+
2 rows in set (0.01 sec)

También es una tabla extremadamente simple donde sólo consta el acabado básico (el original, el que aparece en los pedidos) y el acabado agrupado que le corresponde a cada acabado básico.

Algunos datos de los que consta son los siguientes:

mysql> SELECT * FROM fin_allfinish LIMIT 5;
+---------+---------+
| fin_bas | fin_agg |
+---------+---------+
| 1       | 1       |
| 1D      | 1       |
| 1P      | K3      |
| 2B      | 2B      |
| 2C      | 2B      |
+---------+---------+
5 rows in set (0.00 sec)

Así, los acabados 1 y 1D quedarán agrupados como acabado 1. El 2B y el 2C quedarán agrupados como acabado 2B. Y así para un total de 94 acabados.

Primera consulta de agrupación.

Tenemos pues las tres tablas presentadas. Vamos a llevar a cabo una primera ejecución de la consulta de combinación y agrupación que necesitaremos para obtener el resultado deseado y evaluaremos cuánto tiempo ha tardado MySQL en devolvernos el resultado:

mysql> SELECT typ_agg AS type, 
    -> fin_agg AS finish, 
    -> SUM(mat_qty) AS quantity
    -> FROM 
    -> ((mat_materialsx LEFT JOIN typ_alltypesx ON mat_typ = typ_bas) 
    -> LEFT JOIN fin_allfinish ON mat_fin = fin_bas)
    -> GROUP BY typ_agg, fin_agg;
+-------+--------+-----------+
| type  | finish | quantity  |
+-------+--------+-----------+
| 202   | 2B     |      7217 |
| 202   | BA     |     31140 |
| 430   | 1      |    994298 |
| 430   | 2B     |  11621394 |
| 430   | BA     |  22678569 |
| 430   | K3     |    546858 |
| 441   | 2B     |   2862123 |
| 441   | K3     |     55160 |
| 524   | 1      |   4930442 |
| 524   | 2B     |  23379844 |
| 524   | BA     |   4499020 |
| 524   | K3     |    652620 |
+-------+--------+-----------+
12 rows in set (0.95 sec)

No está nada mal. En apenas un segundo ha hecho los correspondientes joins y las agregaciones de los 177.047 registros para devolvernos lo que deseábamos obtener. Entonces... ¿si estoy defendiendo la importancia de las claves foráneas y sobretodo de la unicidad, no es un contrasentido haber obtenido unos resultados tan buenos? No, no lo es. Tiene una explicación. Fijémonos que estamos haciendo las combinaciones con los cambos typ_bas y fin_bas que son claves principales en sus respectivas tablas y que por tanto son campos únicos en ellas. Dicho de otro modo, MySQL no necesita estrictamente que existan claves foráneas (en este caso serían mat_typ y mat_fin) referenciando a estas claves primarias para ejecutar la consulta rápidamente. Lo que sí necesita es que exista ese unicidad.

Bien, vamos a complicarlo y se entenderá mejor -espero-. Imaginemos que no estamos trabajando con datos de una sola empresa sino que formamos parte de un pequeño grupo de empresas que comparten base de datos. Así, en las tablas de parametrización de tipos de material y acabados, la clave principal no es únicamente el tipo de material y el acabado, sino que incorporamos también el código de la empresa en cuestión, ya que el material 304/L en una empresa se agrupará como 304 mientras que en otra se agrupará como 524 (es un decir).

De este modo las dos tablas quedarán ahora así.

Tabla de agregación de tipos de material.
mysql> describe typ_alltypesx;
+---------+------------+------+-----+---------+-------+
| Field   | Type       | Null | Key | Default | Extra |
+---------+------------+------+-----+---------+-------+
| typ_cpy | varchar(3) | NO   | PRI |         |       |
| typ_bas | varchar(6) | NO   | PRI |         |       |
| typ_agg | varchar(6) | NO   |     |         |       |
+---------+------------+------+-----+---------+-------+
3 rows in set (0.01 sec)

Con unos datos como estos (AMG es el código de una de las empresas, concretamente de la que nos interesará, ya que pondremos absolutamente todos los datos con este código de empresa):

mysql> SELECT * FROM typ_alltypesx LIMIT 5;
+---------+---------+---------+
| typ_cpy | typ_bas | typ_agg |
+---------+---------+---------+
| AMG     | 14462   | 524     |
| AMG     | 202     | 202     |
| AMG     | 301PK   | 524     |
| AMG     | 304     | 304     |
| AMG     | 304/L   | 304     |
+---------+---------+---------+
5 rows in set (0.00 sec)
Tabla de agregación de acabados.
mysql> describe fin_allfinish;
+---------+------------+------+-----+---------+-------+
| Field   | Type       | Null | Key | Default | Extra |
+---------+------------+------+-----+---------+-------+
| fin_cpy | varchar(3) | NO   | PRI |         |       |
| fin_bas | varchar(2) | NO   | PRI |         |       |
| fin_agg | varchar(2) | NO   |     |         |       |
+---------+------------+------+-----+---------+-------+
3 rows in set (0.01 sec)

Con unos datos como estos:

mysql> SELECT * FROM fin_allfinish LIMIT 5;
+---------+---------+---------+
| fin_cpy | fin_bas | fin_agg |
+---------+---------+---------+
| AMG     | 1       | 1       |
| AMG     | 1D      | 1       |
| AMG     | 1P      | K3      |
| AMG     | 2B      | 2B      |
| AMG     | 2C      | 2B      |
+---------+---------+---------+
5 rows in set (0.00 sec)
Segunda consulta de agrupación.

Tenemos pues de nuevo las tres tablas presentadas, sólo que ahora las dos últimas han sufrido un pequeño cambio, aunque aparentemente no demasiado importante puesto que sólo hemos añadido un campo adicional, pero no hemos tocado los que ya había y siguen siendo claves primarias los que lo eran anteriormente. Vamos a llevar a cabo la segunda ejecución de la consulta de combinación y agrupación y evaluaremos cuánto tiempo ha tardado esta vez MySQL en devolvernos el resultado:

mysql> SELECT typ_agg AS type, 
    -> fin_agg AS finish, 
    -> SUM(mat_qty) AS quantity
    -> FROM 
    -> ((mat_materialsx LEFT JOIN typ_alltypesx ON mat_typ = typ_bas) 
    -> LEFT JOIN fin_allfinish ON mat_fin = fin_bas)
    -> GROUP BY typ_agg, fin_agg;
+-------+--------+-----------+
| type  | finish | quantity  |
+-------+--------+-----------+
| 202   | 2B     |      7217 |
| 202   | BA     |     31140 |
| 430   | 1      |    994298 |
| 430   | 2B     |  11621394 |
| 430   | BA     |  22678569 |
| 430   | K3     |    546858 |
| 441   | 2B     |   2862123 |
| 441   | K3     |     55160 |
| 524   | 1      |   4930442 |
| 524   | 2B     |  23379844 |
| 524   | BA     |   4499020 |
| 524   | K3     |    652620 |
+-------+--------+-----------+
12 rows in set (21.02 sec)

Nada menos que 21 segundos. Una barbaridad. De acuerdo que tiene que combinar y agrupar 177.047 registros, pero tampoco son tantos... ¿qué pasará cuando sean millones? El problema que nos ha aparecido es ni más ni menos que la unicidad. Antes los campos typ_bas y fin_bas que se utilizan para los joins eran únicos. Ahora ya no lo son. Vamos a intentar solucionarlo.

Establecimiento de unicidad.

Para ello ejecutaremos las siguientes sentencias:

mysql> ALTER TABLE typ_alltypesx 
    -> CHANGE typ_bas typ_bas VARCHAR(6) UNIQUE;
Query OK, 70 rows affected (0.03 sec)
Records: 70  Duplicates: 0  Warnings: 0

mysql> DESCRIBE typ_alltypesx;
+---------+------------+------+-----+---------+-------+
| Field   | Type       | Null | Key | Default | Extra |
+---------+------------+------+-----+---------+-------+
| typ_cpy | varchar(3) | NO   | PRI |         |       |
| typ_bas | varchar(6) | NO   | PRI |         |       |
| typ_agg | varchar(6) | NO   |     |         |       |
+---------+------------+------+-----+---------+-------+
3 rows in set (0.01 sec)

mysql> ALTER TABLE fin_allfinish 
    -> CHANGE fin_bas fin_bas VARCHAR(2) UNIQUE;
Query OK, 94 rows affected (0.03 sec)
Records: 94  Duplicates: 0  Warnings: 0

mysql> DESCRIBE fin_allfinish;
+---------+------------+------+-----+---------+-------+
| Field   | Type       | Null | Key | Default | Extra |
+---------+------------+------+-----+---------+-------+
| fin_cpy | varchar(3) | NO   | PRI |         |       |
| fin_bas | varchar(2) | NO   | PRI |         |       |
| fin_agg | varchar(2) | NO   |     |         |       |
+---------+------------+------+-----+---------+-------+
3 rows in set (0.01 sec)

Aparentemente las tablas no han cambiado. Al menos no nos muestra cambios en el DESCRIBE. Sin embargo sí que lo han hecho, ya que le hemos establecido que los campos typ_bas y fin_bas además de formar parte de claves primarias, son en sí mismos únicos. Si quisiéramos que claves foráneas de otras tablas hicieran referencia a estos campos ahora podríamos hacerlo (antes no habríamos podido ya que MySQL nos habría devuelto un error), pero en realidad para evaluar la velocidad de la consulta no nos es estrictamente necesario. Ya he comentado antes que para la velocidad a la hora de combinar y agrupar MySQL requiere unicidad, no necesariamente claves foráneas. Vamos a verlo.

Tercera consulta de agrupación.

Respecto a la ejecución anterior sólo hemos cambiado que ahora las dos tablas de parametrización han visto como sus campos clave utilizados en los joins se han hecho únicos. Veamos cómo va la tercera ejecución de la consulta de combinación y agrupación y evaluaremos cuánto tiempo ha tardado ahora MySQL en devolvernos el resultado:

mysql> SELECT typ_agg AS type, 
    -> fin_agg AS finish, 
    -> SUM(mat_qty) AS quantity
    -> FROM 
    -> ((mat_materialsx LEFT JOIN typ_alltypesx ON mat_typ = typ_bas) 
    -> LEFT JOIN fin_allfinish ON mat_fin = fin_bas)
    -> GROUP BY typ_agg, fin_agg;
+-------+--------+-----------+
| type  | finish | quantity  |
+-------+--------+-----------+
| 202   | 2B     |      7217 |
| 202   | BA     |     31140 |
| 430   | 1      |    994298 |
| 430   | 2B     |  11621394 |
| 430   | BA     |  22678569 |
| 430   | K3     |    546858 |
| 441   | 2B     |   2862123 |
| 441   | K3     |     55160 |
| 524   | 1      |   4930442 |
| 524   | 2B     |  23379844 |
| 524   | BA     |   4499020 |
| 524   | K3     |    652620 |
+-------+--------+-----------+
12 rows in set (1.43 sec)

Genial. Hemos pasado de 21 segundos a apenas uno y medio. La mejora es espectacular... ¿Qué ocurriría ahora si aprovechamos que esos campos ya son únicos para hacer que también sean el destino de claves foráneas en la tabla principal? Veámoslo.

Establecimiento de claves foráneas.
mysql> ALTER TABLE mat_materialsx 
    -> ADD FOREIGN KEY(mat_typ) REFERENCES typ_alltypesx(typ_bas);
Query OK, 177047 rows affected (3.71 sec)
Records: 177047  Duplicates: 0  Warnings: 0

mysql> ALTER TABLE mat_materialsx 
    -> ADD FOREIGN KEY(mat_fin) REFERENCES fin_allfinish(fin_bas);
Query OK, 177047 rows affected (4.10 sec)
Records: 177047  Duplicates: 0  Warnings: 0

Cuarta consulta de agrupación.

¿Habremos mejorado algo al incorporar estas claves foráneas? Veamos, veamos...

mysql> SELECT typ_agg AS type, 
    -> fin_agg AS finish, 
    -> SUM(mat_qty) AS quantity
    -> FROM 
    -> ((mat_materialsx LEFT JOIN typ_alltypesx ON mat_typ = typ_bas) 
    -> LEFT JOIN fin_allfinish ON mat_fin = fin_bas)
    -> GROUP BY typ_agg, fin_agg;
+-------+--------+-----------+
| type  | finish | quantity  |
+-------+--------+-----------+
| 202   | 2B     |      7217 |
| 202   | BA     |     31140 |
| 430   | 1      |    994298 |
| 430   | 2B     |  11621394 |
| 430   | BA     |  22678569 |
| 430   | K3     |    546858 |
| 441   | 2B     |   2862123 |
| 441   | K3     |     55160 |
| 524   | 1      |   4930442 |
| 524   | 2B     |  23379844 |
| 524   | BA     |   4499020 |
| 524   | K3     |    652620 |
+-------+--------+-----------+
12 rows in set (1.45 sec)

En este caso la respuesta es que no. Nos hemos quedado exactamente igual. No obstante con todo esto no quiero decir que las claves foráneas no sean necesarias, ya que como he dicho al comenzamiento del post, nos sirven para mantener la integridad de la base de datos (¡aspecto fundamental!). Lo único que pretendo con este post es dejar claro que MySQL no las necesita estrictamente para combinar eficientemente distintas tablas, ya que es capaz de hacerlo igual de bien simplemente con que los campos que utilizamos para los joins sean únicos.

Nota importante.

A lo largo de todo el ejemplo es básico ir borrando la caché de consultas de MySQL para no obtener resultados distorsionados. Para ello he utilizado la sentencia:

mysql> RESET QUERY CACHE;
Query OK, 0 rows affected (0.00 sec)

De lo contrario nos encontraremos con tiempos de respuesta maravillosos de 0.00 sec... ;-)

Jugando con formatos de fechas en MySQL.

Jueves, Septiembre 4th, 2008

Este post es muy simple, pero su contenido me facilita mucho la vida desde que lo programé. Se trata de un par de simples funciones para convertir los dos formatos de fecha que más utilizo en el proyecto que estoy desarrollando. Estos dos formatos son por una parte el habitual DATE de MySQL (YYYY-MM-DD) y por otra parte un formato texto VARCHAR(8) que simplemente elimina los guiones (YYYYMMDD) de la fecha. Lo de utilizar este formato en modo texto viene porque recopilo mucha información de tablas en una base de datos externa en la que las fechas están almacenadas de esta manera.

De paso tiene la ventaja de que es insensible a configuraciones regionales que tienden a cambiar mes y día a la mínima que se les da una oportunidad...

Así pues, para moverme indistintamente con los dos formatos de fecha y no tener que andar preocupándome en cada ocasión si está en uno u otro formato, tengo estas dos minifunciones almacenadas en MySQL que me sirven de ayuda.

La primera es para pasar de formato DATE a formato VARCHAR(8):

#---------------------------------------------------------------------
# STORED FUNCTION: sf_date2strng 
#---------------------------------------------------------------------
# Author:      Albert Mata (www.albertmata.net)
# Date:        20080904
# Description: Takes a date in YYYY-MM-DD format and returns it in
#              YYYYMMDD format.
#---------------------------------------------------------------------
DROP FUNCTION IF EXISTS sf_date2strng;

DELIMITER //

CREATE FUNCTION sf_date2strng(mydate DATE) RETURNS VARCHAR(8)

BEGIN
    RETURN CONCAT(MID(mydate,1,4),MID(mydate,6,2),MID(mydate,9,2));
END
//

DELIMITER ;

Y esta segunda es para pasar de formato VARCHAR(8) a formato DATE:

#---------------------------------------------------------------------
# STORED FUNCTION: sf_strng2date 
#---------------------------------------------------------------------
# Author:      Albert Mata (www.albertmata.net)
# Date:        20080904
# Description: Takes a date in YYYYMMDD format and returns it in
#              YYYY-MM-DD format.
#---------------------------------------------------------------------
DROP FUNCTION IF EXISTS sf_strng2date;

DELIMITER //

CREATE FUNCTION sf_strng2date(mydate VARCHAR(8)) RETURNS DATE

BEGIN
    RETURN STR_TO_DATE(mydate,'%Y%c%e');
END
//

DELIMITER ;

Para almacenarlas en la base de datos MySQL basta con copiar todo este código tal cual en un archivo de texto, añadirle una primera línea...

USE nameofddbb;

...y guardar el archivo con un nombre corto y en una ruta facilita (esto es opcional, pero para qué complicarse la vida), como por ejemplo C:\in.txt. Hecho esto, basta con escribir en un símbolo de sistema de Windows (antes de entrar en MySQL):

mysql -u root -p < C:\in.txt

También podemos hacerlo con un usuario no root, pero tiene que tener suficientes permisos para poder crear un procedimiento almacenado en la base de datos concreta que hayamos especificado en esa primera línea del archivo de texto.

Una vez tenemos las funciones almacenadas en MySQL comprobamos que funcionan. Primero le introducimos una fecha para que nos la convierta a texto y vemos que funciona sin problemas:

mysql> SELECT sf_date2strng('2008-09-04');
+-----------------------------+
| sf_date2strng('2008-09-04') |
+-----------------------------+
| 20080904                    |
+-----------------------------+
1 row in set (0.00 sec)

También podemos introducirle una fecha completa (con hora) y funcionará también bien. Sin embargo nos avisará de que se ha generado un warning. Si lo miramos vemos que no es nada grave, simplemente nos informa de que ha desestimado totalmente la hora, lo cual no nos importa.

mysql> SELECT sf_date2strng('2008-09-04 18:23:45');
+--------------------------------------+
| sf_date2strng('2008-09-04 18:23:45') |
+--------------------------------------+
| 20080904                             |
+--------------------------------------+
1 row in set, 1 warning (0.00 sec)

mysql> SHOW WARNINGS;
+-------+------+---------------------------------------------+
| Level | Code | Message                                     |
+-------+------+---------------------------------------------+
| Note  | 1265 | Data truncated for column 'mydate' at row 1 |
+-------+------+---------------------------------------------+
1 row in set (0.00 sec)

A continuación probamos la segunda función, introduciéndole un texto que representa una fecha para que nos la convierta a tipo DATE:

mysql> SELECT sf_strng2date('20081026');
+---------------------------+
| sf_strng2date('20081026') |
+---------------------------+
| 2008-10-26                |
+---------------------------+
1 row in set (0.00 sec)

A partir de aquí podremos utilizar estas dos funciones en cualquier consulta, vista u otro procedimiento o función almacenada que deseemos.

Instrucciones menos habituales en MySQL (1a parte).

Martes, Agosto 26th, 2008

Utilizando la base de datos MySQL como acostumbro, constantemente estoy lidiando con las sintaxis más habituales para crear y modificar tablas, funciones, vistas y demás. No obstante, hay también por ahí un conjunto de instrucciones que alguna vez he utilizado y que solía tener que googlear porque nunca las recordaba desde la vez anterior. Hasta que me decidí a ir anotándolas, por tontas y breves que fueran. Y ahora, ya que estamos, me ha parecido buena idea compartirlas por si a alguien le sirven de algo.

Ver el código que en su día utilizamos para crear una vista.

Si por ejemplo hacemos un...

DESCRIBE tbl_tablenamex;

...sobre una tabla o una vista, nos devuelve la estructura de esa tabla o vista, con sus campos y tipos de datos y demás información básica. No obstante, en ocasiones con las vistas me interesa ver de una manera rápida con qué sintaxis exacta la creé (de dónde saqué los campos, cómo enlacé las tablas, etc.). Normalmente tengo esa información guardada en archivos de texto, ya que raramente creo una vista directamente en consola, sino que más bien suelo hacerlo a través de archivos planos. No obstante me resulta más rápido verlo directamente en la consola que tener que ir a buscar el archivo. Para ello me valgo de...

SHOW CREATE VIEW viw_viewnamexx;

...y obtengo, aunque de un modo no muy agradable de ver, la sintaxis que utilicé para crear la vista en su momento.

Reiniciar el contador autonumérico de una tabla.

A menudo utilizo campos autonuméricos en mis tablas. Aunque tienen algún inconveniente, si se utilizan únicamente a modo de campo identificador para uso fundamentalmente interno, suelen aportar mayores ventajas que inconvenientes presentan. ¿Pero cómo reiniciamos el contador autonumérico después de haber estado trasteando con la tabla? Muy fácil, en dos pasos. El primero es asegurarnos que la tabla está totalmente vacía de registros. El segundo consiste en aplicar...

ALTER TABLE tbl_tablenamex AUTO_INCREMENT = 1;

...y el contador habrá quedado convenientemente reseteado. Si queremos que se resetee pero que no comience de nuevo por el 1 sino por ejemplo por el 1001, también se lo podemos indicar con esta misma instrucción.

Listar todas las tablas en una base de datos.

En principio para hacer esto nos podemos valer de un simple...

SHOW TABLES;

...pero esto solo nos listará las tablas sin añadir mayor información, cosa que la mayor parte de las veces nos puede ser más que suficiente. Sin embargo si queremos obtener más información podemos utilizar...

SELECT *
FROM information_schema.tables
WHERE table_schema = 'nameofddbb';

...y obtendremos no solo el nombre sino también si se trata de una tabla o vista, qué motor utiliza (InnoDB, MyISAM...), el número de registros, la fecha de creación, aspectos sobre el tamaño, etc.

Listar todos los campos en una tabla.

Del mismo modo, para los campos podemos hacer como hemos dicho antes un...

DESCRIBE tbl_tablenamex;

...pero si queremos un poco más de información también podemos recurrir a...

SELECT *
FROM information_schema.columns
WHERE table_name = 'tbl_tablenamex';

...y como ocurría con las tablas obtendremos algo más de información.

Obtener información sobre rutinas.

Si lo que queremos es obtener información sobre funciones o procedimientos almacenados en una base de datos (incluyendo el código fuente con el que se crearon), podemos utilizar...

SELECT *
FROM information_schema.routines
WHERE routine_schema = 'nameofddbb';

Obtener información sobre vistas (otro método).

Si de lo que queremos obtener información más detallada (incluyendo nuevamente el código utilizado en la generación) es una vista, podemos utilizar...

SELECT *
FROM information_schema.views
WHERE table_schema = 'nameofddbb';

Obtener información sobre triggers (disparadores).

Y si lo que queremos es obtener información más detallada sobre disparadores o triggers (también incluyendo el código con el que se han generado), podemos utilizar...

SELECT *
FROM information_schema.triggers
WHERE trigger_schema = 'nameofddbb';

Copiar una tabla y opcionalmente rellenarla.

Si deseamos crear una copia de una tabla en la misma o en otra base de datos, podemos utilizar primero esta instrucción para copiar la estructura...

CREATE TABLE tbl_targettabl LIKE nameofddbb.tbl_sourcetabl;

...y nos creará una tabla destino igual que la tabla origen, solo que sin datos dentro. Para copiar a continuación todos los datos nos bastará con...

INSERT INTO tbl_targettabl
SELECT * FROM nameofddbb.tbl_sourcetabl;

De hecho, en caso de querer copiar tanto estructura como datos, también podríamos haberlo hecho en un solo paso con...

CREATE TABLE tbl_targettabl
SELECT * FROM nameofddbb.tbl_sourcetabl;

...pero para mí gusto, este método presenta el inconveniente de que si la tabla contiene claves principales no se trasladan a la copia, por lo cual yo prefiero siempre el método en dos pasos.

Y lo de añadir nameofddbb. antes del nombre de la tabla está claro que sólo será preciso cuando estemos operando con dos bases de datos distintas (si solo trabajamos con una no es preciso añadirlo).

Esto es todo por ahora. Seguro que me dejo más instrucciones de esas poco frecuentes que a veces necesitamos, así que titulo intencionadamente el post con lo de 1a parte en previsión de que más adelante pueda haber otras.

Informe en .NET con Crystal Reports y base de datos MySQL.

Jueves, Julio 31st, 2008

Vaya por delante que el tema de la creación de informes (o reports) siempre ha sido una de las partes de la programación que me ha dado más pereza. Pero está claro que pocas aplicaciones se salvan de requerirlos en mayor o menor grado, y la que actualmente tengo entre manos no es, en absoluto, una excepción. Así pues, estos últimos días he tenido que preparar un nuevo report y de paso he aprovechado para investigar un poco y descubrir una nueva manera de realizarlos. Paso a explicarme.

Como ya he comentado en ocasiones, mi entorno de desarrollo es VisualBasic.NET y una base de datos MySQL. Y los informes los hago con el propio Crystal Reports que incorpora el VisualStudio.NET. El tema está en que hasta ahora los hacía a través de una conexión ODBC que tenía que instalar en cada máquina apuntando hacia el servidor MySQL, pero este sistema no me gustaba demasiado. Y no me gustaba porque en realidad de bases de datos tengo distintas con distintos nombres pero con las mismas estructuras de tablas y datos parecidos, ya que una es la productiva (la real, la buena) y las otras son para desarrollo, para que los usuarios hagan pruebas sin que afecte a los datos reales, etc. Controlar la cadena de conexión en la aplicación para que ataque a una u otra base de datos no me supone el más mínimo problema, pero los informes cogen sus datos a través de una conexión ODBC concreta y ésta en cada máquina ataca a una única base de datos. Así que no me convence este sistema.

Y ahora he descubierto cómo puede crear informes a través de un DataTable y de una estructura en un archivo XML, sin necesidad de nada más. De hecho en lugar de un DataTable se puede utilizar perfectamente un DataSet y funciona sin ningún tipo de problemas ni apenas modificaciones (dejo en manos del lector probarlo si le interesa). Voy a pasar a explicar mediante un ejemplo y algunas imágenes cómo realizarlo desde cero.

Partiré de dos tables en mi base de datos MySQL en las que guardaré información de facturas. La primera tabla es de cabeceras de esas facturas y tiene estos datos:

+---------+------------+-------------------------+
| blh_num | blh_dat    | blh_cus                 |
+---------+------------+-------------------------+
|       1 | 2008-07-30 | CERAMICAS PEPE, S.A.    |
|       2 | 2008-07-30 | TALLERES GOMEZ, S.L.    |
|       3 | 2008-07-31 | DEPORTES DAMIAN, S.L.   |
|       4 | 2008-07-31 | SOFTWARE ALBERTMATA.NET |
+---------+------------+-------------------------+

La segunda tabla son las posiciones de cada factura y tiene estos otros datos:

+---------+---------+------------------------+---------+---------+
| blp_num | blp_pos | blp_art                | blp_pri | blp_qty |
+---------+---------+------------------------+---------+---------+
|       1 |       1 | RATON LOGITECH         |   15.95 |       1 |
|       2 |       1 | MONITOR LG 19 PULGADAS |   210.5 |       1 |
|       3 |       1 | ROUTER DLINK           |      56 |       1 |
|       4 |       1 | RATON LOGITECH         |   15.95 |       2 |
|       4 |       2 | TECLADO LOGITECH       |   12.95 |       1 |
|       4 |       3 | RECEPTOR GPS ZAPPA     |   59.95 |       1 |
|       4 |       4 | PAQUETE 500 FOLIOS     |     3.7 |       4 |
+---------+---------+------------------------+---------+---------+

Es algo muy sencillo y poco normalizado, pero nos servirá para el ejemplo. Concretamente vamos a crear un informe que será nada más que una impresión de una factura. Como voy a trabajar con un simple DataTable pero mi informe requerirá datos de dos tablas, me crearé primero una vista en MySQL con la siguiente instrucción:

CREATE VIEW zbl_bill2print AS 
(
SELECT
    blh_num AS BILL_NUMBER,
    blh_dat AS BILL_DATE,
    blh_cus AS BILL_CUSTOMER,
    blp_pos AS LINE_NUMBER,
    blp_art AS LINE_ARTICLE,
    blp_pri AS LINE_UNITPRICE,
    blp_qty AS LINE_UNITS,
    blp_pri * blp_qty AS LINE_TOTALPRICE
FROM
    blh_billheader LEFT JOIN blp_billposits ON blh_num = blp_num
WHERE
    blh_num = 4
);

Así, mi informe a partir de ahora se realizará sobre esta vista zbl_bill2print. Vamos pues a empezar con la parte que incumbe a .NET.

Paso 1. Creación del archivo XML con la estructura de la tabla/vista.

Para todo el ejemplo jugaremos con:

1) un formulario frmMain donde tendremos el objeto visualizador de informes.
2) una clase clsReportCreator que crearemos a continuación.
3) un informe rptBill que representará la factura que queremos imprimir.

Comenzamos pues creando la clase clsReportCreator, que constará de un único atributo (el nombre de la tabla o vista), un método constructor, un método para cargar el DataTable correspondiente y un último método para generar el archivo XML. El código completo de esta clase es el siguiente:

'--------------------------------------------------------------------
' Author:      Albert Mata (www.albertmata.net)
' Date:        20080731
' Needs:       MySQL.Data reference.
' Description: Class to create a report using just an XML file. 
'--------------------------------------------------------------------
Imports MySql.Data.MySqlClient

Public Class clsReportCreator

    '----------------------------------------------------------------
    ' Attributes.
    '----------------------------------------------------------------
    Private TableOrView As String

    '----------------------------------------------------------------
    ' Constructor method.
    '----------------------------------------------------------------
    Public Sub New(ByVal TableOrView As String)
        Me.TableOrView = TableOrView
    End Sub

    '----------------------------------------------------------------
    ' Returns DataTable corresponding to TableOrView.
    '----------------------------------------------------------------
    Public Function GetDataTable() As DataTable
        Dim DA As MySqlDataAdapter
        Dim DS As New DataSet
        Dim DT As DataTable
        Dim ConnectionString As String
        Dim SQL As String

        'Setting connection string to connect to MySQL database.
        ConnectionString = "Database = blog; " _
                         & "Data Source = localhost; " _
                         & "User ID = root; " _
                         & "Password = mypassword"

        'Setting SQL string.
        SQL = "SELECT * FROM " & Me.TableOrView

        'Getting data and filling DataSet and DataTable.
        DA = New MySqlDataAdapter(SQL, ConnectionString)
        DA.Fill(DS, Me.TableOrView)
        DT = DS.Tables(Me.TableOrView)

        'Returning DataTable.
        Return DT
    End Function

    '----------------------------------------------------------------
    ' Creates XML file in desired path.
    '----------------------------------------------------------------
    Public Sub CreateXMLFile(ByVal FilePath As String)
        Dim DT As DataTable

        'Creating DataTable.
        DT = Me.GetDataTable()

        'Writting XML file in desired path.
        DT.WriteXmlSchema(FilePath & Me.TableOrView & ".xml")
    End Sub

End Class

Y creamos también el formulario frmMain cuyo único código por el momento (después cambiará un poco) será el que sigue:

'--------------------------------------------------------------------
' Author:      Albert Mata (www.albertmata.net)
' Date:        20080731
' Description: Form to show how to create a report using just an XML
'              file. 
'--------------------------------------------------------------------
Public Class frmMain

    '----------------------------------------------------------------
    ' As a first step, creates XML file.
    '----------------------------------------------------------------
    Private Sub frmMain_Load(ByVal sender As System.Object, _
    ByVal e As System.EventArgs) Handles MyBase.Load
       'Creating XML file.
        Dim RC As New clsReportCreator("zbl_bill2print")
        RC.CreateXMLFile("C:\")
    End Sub

End Class

Con esto tenemos una primera aplicación que al ejecutarla nos creará el archivo C:\zbl_bill2print.xml con la estructura de la vista zbl_bill2print. Lo probamos pues y obtenemos un archivo como éste.

Paso 2. Creación del informe e inserción del origen de datos.

Añadimos al proyecto un informe al que llamaremos rptBill.rpt y que crearemos seleccionando la alternativa Como informe en blanco y por tanto desestimando plantillas.

A continuación en el menú Explorador de campos seleccionamos la primera opción Campos de base de datos y en su menú contextual hacemos click en la opción Asistente de base de datos.

En el menú que se despliega (Orígenes de datos disponibles) seleccionamos Crear nueva conexión y a continuación la opción ADO.NET.

Con esto se nos abrira un nuevo formulario en el que nos solicitará la Ruta del archivo. Debemos aquí ir a buscar el archivo XML que hemos creado anteriormente (en mi caso el C:\zbl_bill2print.xml) y acto seguido pulsar en Finalizar. Con ello, en el menú anterior (Orígenes de datos disponibles) se nos mostrará ya la opción NewDataSet incluyendo el zbl_bill2print que acabamos de añadir.

Lo marcamos y le damos al botón para trasladarlo al menú de Tablas seleccionadas y pulsamos en Aceptar.

Con esto hemos conseguido que en el menú Explorador de campos nos aparezca ya la estructura de zbl_bill2print con sus campos, tal como se muestra a continuación:

Paso 3. Diseño del informe.

No tiene ningún misterio. Se trata de añadir los campos desde el menú Explorador de campos donde corresponda, insertarle los objetos de texto que nos parezcan adecuados, los totales cuando sea preciso, dar formato a los textos, incorporar imágenes y demás florituras a nuestro antojo...

Yo me inclino por un diseño sobrio como éste:

Paso 4. Últimos pasos para obtener la factura.

Por último vamos ya a crear la factura. Para ello en el formulario frmMain añadiremos un objeto de tipo CrystalReportViewer al que llamaremos por ejemplo crvBill. Y modificamos el código de frmMain para dejarlo como sigue:

'--------------------------------------------------------------------
' Author:      Albert Mata (www.albertmata.net)
' Date:        20080731
' Description: Form to show how to create a report using just an XML
'              file. 
'--------------------------------------------------------------------
Imports CrystalDecisions.CrystalReports.Engine

Public Class frmMain

    '----------------------------------------------------------------
    ' Creates XML file (just once) and creates and loads a report.
    '----------------------------------------------------------------
    Private Sub frmMain_Load(ByVal sender As System.Object, _
    ByVal e As System.EventArgs) Handles MyBase.Load
        'Creating XML file.
        Dim RC As New clsReportCreator("zbl_bill2print")
        'RC.CreateXMLFile("C:\")

        'Creating report.
        Dim RD As ReportDocument = New rptBill()

        'Setting data source for report.
        Dim DT As DataTable = RC.GetDataTable()
        RD.SetDataSource(DT)

        'Setting data source for possible subreports.
        For Each SR As ReportDocument In RD.Subreports
            If SR.Database.Tables.Count > 0 Then
                SR.SetDataSource(DT)
            End If
        Next

        'Setting recently created report must be shown in viewer.
        Me.crvBill.ReportSource = RD
    End Sub

End Class

Nótese que ahora ya he comentado la línea en que creamos el archivo XML, puesto que sólo necesitamos crearlo una única vez para luego poder generar el origen de datos, pero a partir de aquí no necesitaremos andar creándolo cada vez.

En este código lo que estamos haciendo fundamentalmente es crear un objeto del tipo informe que hemos diseñado en el paso 3, obtener un DataTable con los datos que queremos mostrar (en este caso y tal como tenemos definida la vista de MySQL, queremos mostrar la factura número 4), establecer que el origen de datos del informe será este DataTable y finalmente solicitarle al CrystalReportViewer que nos muestre este informe.

Ejecutamos nuevamente la aplicación y obtenemos la factura que queríamos:

Por supuesto en una factura auténtica faltarían datos fiscales, logotipos, impuestos, condiciones de pago y demás, pero lo que aquí pretendía era únicamente mostrar cómo llevar a cabo el informe en sí mismo.

Con esto queda visto cómo simplemente utilizando un archivo XML podemos crear un informe en VisualBasic.NET. Por supuesto habría que mejorar muchas cosas, por ejemplo optimizar cómo se realiza la conexión con la base de datos (particularmente tengo un clase para llevar a cabo esa serie de cuestiones), también evitar poner la condición WHERE directamente en la vista de MySQL y sí por ejemplo cuando recuperamos el DataTable... en fin, unas cuantas cosas. Pero lo que buscaba con este ejemplo era hacer algo muy minimalista para que quedara claro el funcionamiento.

Actualización.

A raíz de uno de los comentarios he añadido una pequeña segunda parte a este post, en la que se explica cómo pasar parámetros desde el formulario hasta el informe.

Copias de seguridad en MySQL con mysqldump.

Jueves, Junio 5th, 2008

En los pocos días de vida que tiene este blog es posible que haya mencionado ya que en el proyecto en el que estoy trabajando actualmente estamos utilizando una base de datos MySQL. Sí, lo sé, unas cuantas veces llevo ya... pero es que realmente va muy bien, estamos muy contentos con sus prestaciones hasta la fecha. Se está mostrando rápida y muy fiable... y todo ello con una licencia GPL, no lo olvidemos.

Bueno, el caso es que como es evidente, cuando trabajamos con cualquier sistema tenemos que tener muy bien previsto un método decente de copias de seguridad. En el caso de MySQL tenemos varias alternativas, pero la que a mí más me ha convencido ha sido la herramienta mysqldump. Es realmente sencilla de utilizar y tremendamente funcional. Su funcionamiento exacto con las decenas de opciones que admite se puede encontrar en el propio manual de referencia de MySQL. No requiere instalación alguna, simple y llanamente que dispongamos del archivo mysqldump.exe que conseguiremos sin problemas en la página oficial de MySQL y que si hemos instalado el servidor MySQL probablemente tendremos ya en nuestro equipo.

La herramienta mysqldump nos genera archivos con extensión .sql que incluyen -según hayamos configurado- las instrucciones necesarias para restaurar una base de datos entera -o todas las que tengamos en el servidor MySQL-, desde su creación hasta la adición de los datos pasando por la creación de las tablas. Realmente completito. Para una restauración sólo habría que hacer algo así en una línea de comandos (localhost o servidor según corresponda):

mysql -u root -p -h localhost < C:\archivo_backup.sql

No obstante lo que quiero explicar hoy es cómo he automatizado estas copias de seguridad que hago con mysqldump a través de un archivo batch. Expongo código y después lo comento.

@echo off

set path_mysqldump="C:\Program Files\MySQL\MySQL Server 5.0\bin"
set path_backups="\\99.24.13.29\BBDD\Backups"
set user=root
set password=mi_password
set host=99.24.13.26

if %time:~0,2% GEQ 10 goto :DespuesDeLas10

:AntesDeLas10
%path_mysqldump%\mysqldump --user=%user% --password=%password% 
      -h %host% --databases db_offers --single-transaction 
      > %path_backups%\backup_%date:~6,4%%date:~3,2%%date:~0,2%
        _0%time:~1,1%%time:~3,2%.sql
goto :Salir

:DespuesDeLas10
%path_mysqldump%\mysqldump --user=%user% --password=%password%
      -h %host% --databases db_offers --single-transaction 
      > %path_backups%\backup_%date:~6,4%%date:~3,2%%date:~0,2%
        _%time:~0,2%%time:~3,2%.sql
:Salir

Antes que nada, comentar que las líneas que comienzan por %path... aparecen aquí cortadas por temas de espacio (en píxeles, no en bytes ;-) ) en el blog, pero en realidad deben formar una sola línea que termina con .sql. Debe haber un espacio entre %password% y -h y después otro entre transaction y > %path_, pero en cambio la última linea va sin espacio (%date:~0,2%_0%time va todo seguido, ¿ok?).

Paso a explicarlo. Las primeras cinco líneas después del archiconocido @echo off son asignaciones de valores a las variables que después utilizaremos. Es la parte de configuración del archivo batch.

1) path_mysqldump contiene la ruta del directorio donde se encuentra el archivo mysqldump.exe.

2) path_backups contiene la ruta del directorio donde se almacenará la copia de seguridad, en este ejemplo he puesto una carpeta en un servidor.

3) user es el usuario con el que se ejecutará mysqldump. Parece una perogrullada, pero hay que tener en cuenta que debe disponer de permisos suficientes, aunque no es necesario que sea el usuario root (de hecho mucho mejor si no lo es, ya que así no quedará en un archivo batch visualizable el password del usuario root).

4) password es... sí, eso.

5) host es la máquina donde se encuentra el servidor MySQL que queremos backupear. Si es nuestro propio ordenador escribiremos localhost. A destacar que el servidor MySQL debe estar corriendo en el momento de lanzar el mysqldump.

Lo que sigue es ya la ejecución. En mi caso las copias de seguridad las quiero en formato backup_YYYYMMDD_HHMM con la fecha y la hora de esta manera, ya que así una simple ordenación alfabética de los archivos lleva a cabo también una ordenación por fechas. Para lograr eso hay que jugar con los date:~6,4 y similares y además hay que programar dos ramas en función de que sean antes o después de las 10 de la mañana, ya que hasta entonces necesito concatenar un 0 y un time:~1,1 para la hora con dos dígitos y a partir de las 10 me vale con time:~0,2. Podemos prescindir de hacer estas dos alternativas si vamos a lanzar siempre el batch a la misma hora y será más tardía que esas 10am de la madrugada. En cualquier caso para discernir entre si seguir un camino u otro utilizamos el...

if %time:~0,2% GEQ 10 goto :D espuesDeLas10

...donde GEQ equivale a lo que en lenguaje de programación normal y corriente diríamos >=.

Por último comentar que con esto obtenemos un archivo .bat que podemos ejecutar manualmente o programar para que se ejecute periódicamente a nuestro antojo. Por ejemplo con una simple tarea programada de Windows si no nos queremos complicar demasiado la vida.

Simulando DLookup fuera de Access (III).

Viernes, Mayo 30th, 2008

En los dos posts anteriores he mostrado maneras de simular un DLookup en una base de datos MySQL mediante stored procedures y stored functions (primera aproximación y versión mejorada). No obstante, ha quedado claro que hacerlo así aunque puede resultar útil tiene sus limitaciones. Es por ello que normalmente prefiero utilizar un DLookup llevado a cabo desde la parte de la aplicación. En mi caso esto equivale a realizarlo en VisualBasic.NET. Y sin más preámbulos veamos el código de la función:

'--------------------------------------------------------------------
' Author:      Albert Mata (www.albertmata.net)
' Date:        20080530
' Description: Function to simulate Microsoft Access DLookup. 
'--------------------------------------------------------------------
Public Function DLookup(ByVal Field As String, _
                        ByVal Table As String, _
               Optional ByVal Condition As String = "TRUE") _
                        As Object
    Try
        'Creating SQL string.
        Dim SQL As String
        SQL = "SELECT " & Field _
            & " FROM " & Table _
            & " WHERE " & Condition
        'Filling dataset with desired value. 
        Dim DS As New DataSet
        Dim DA As New MySqlDataAdapter(SQL, CONNECTION_STRING)
        DA.Fill(DS, "anyname")
        'Returning value or Null.
        If Not IsDBNull(DS.Tables("anyname").Rows(0).Item(0)) Then
            Return DS.Tables("anyname").Rows(0).Item(0)
        Else
            Dim X As Object = Convert.DBNull
            Return X
        End If
    Catch
        'If error happens, returning Null.
        Dim X As Object = Convert.DBNull
        Return X
    End Try
End Function

Cabe aclarar que CONNECTION_STRING será una constante definida en algún punto de la aplicación que recogerá la cadena de conexión para nuestra base de datos. En mi caso es algo como:

Database = nombre_bbdd; _
Data Source = localhost; _
User ID = root; _
Password = mi_password

Relacionado con cadenas de conexión, recomendado darse un paseo por ConnectionStrings.com.

Yo estoy trabajando con una base de datos MySQL, por eso el DataAdapter es en realidad un MySqlDataAdapter, pero el funcionamiento sería análogo con cualquier otra base de datos y utilizando un objeto DataAdapter convencional. Lo único es que si se trabaja con MySQL es necesario previamente haber agregado la referencia correspondiente al proyecto, y para mayor comodidad en temas de nomenclatura importar el espacio de nombres correspondiente en la parte superior de la clase:

Imports MySql.Data.MySqlClient

Respecto a la función, poco que explicar. Pasarle el campo y la tabla deseados y de manera opcional una condición en formato SQL sin el WHERE. Si no se desea condición se pueden informar sólo dos argumentos, en esta ocasión no es necesario enviar una cadena vacía ni nada por el estilo. Además, el valor que nos devuelve la función es de tipo Object, así que no tendremos ningún problema con el tipo de dato devuelto, nos admitirá cualquier tipo de campo que quiera que sea el campo en cuestión de la tabla en cuestión. En caso de producirse algún error (nombre de campo o tabla mal escritos, conexión a base de datos fallida...) o si no se halla ningún registro, la función nos devolverá un valor nulo, con lo cual desde código podremos recogerlo sin problemas y actuar en consecuencia. :-)

Simulando DLookup fuera de Access (II).

Miércoles, Mayo 28th, 2008

En el anterior post expuse una manera de realizar un DLookup en MySQL mediante stored procedures y stored functions y comenté que para el siguiente post me reservaba un modo de hacer lo mismo desde .NET. No obstante me permito intercalar otra manera de realizar otra vez el DLookup desde MySQL algo más sencilla que la primera aunque para recuperar el valor necesitaremos igualmente una doble consulta. Veamos cómo queda el código en esta ocasión:

#--------------------------------------------------------------------
# Author:      Albert Mata (www.albertmata.net)
# Date:        20080527
# Description: MySQL procedure to simulate Microsoft Access 
#              function DLookup. 
#--------------------------------------------------------------------

#--------------------------------------------------------------------
# Returns DLookup value using fourth parameter.
#--------------------------------------------------------------------
DROP PROCEDURE IF EXISTS DLookup;
DELIMITER //
CREATE PROCEDURE DLookup(IN campo VARCHAR(7),
                         IN tabla VARCHAR(14),
                         IN condicion VARCHAR(250),
                         OUT valor VARCHAR(250))
BEGIN

DROP TABLE IF EXISTS tbl_dlookupaux;
CREATE TABLE tbl_dlookupaux (tbl_res VARCHAR(250));
SET @query = CONCAT('INSERT INTO tbl_dlookupaux SELECT ',
                    campo, ' FROM ', tabla, ' WHERE ',
                    IF(ISNULL(condicion),'TRUE',condicion),
                    ' LIMIT 1');

PREPARE running FROM @query;
EXECUTE running;
DEALLOCATE PREPARE running;
SELECT tbl_res INTO valor FROM tbl_dlookupaux;
DROP TABLE IF EXISTS tbl_dlookupaux;

END
//
DELIMITER ;

Esta vez utilizo únicamente una stored procedure, pero lo hago tomando parámetros tanto de entrada (campo, tabla y condicion) como de salida (valor). Con esto lo que hago es almacenar el resultado en el parámetro valor en lugar de almacenarlo provisionalmente en una tabla para luego recuperarlo de allí (bueno, internamente la stored procedure sí almacena en una tabla temporal, pero en tanto que la misma stored procedure la borra este proceso es transparente al usuario).

Recuerdo que partíamos de una tabla cty_nicecities con esta estructura:

+--------+-----------+---------+
| cty_id | cty_nam   | cty_cou |
+--------+-----------+---------+
|      1 | Paris     | France  | 
|      2 | Rome      | Italy   | 
|      3 | Frankfurt | Germany | 
|      4 | Dortmund  | Germany | 
|      5 | Milan     | Italy   | 
+--------+-----------+---------+

La llamada debe ahora realizarse así:

CALL DLookup ('cty_nam', 'cty_nicecities', 'cty_id = 4', @my_city);
SELECT @my_city;

Almacenamos pues el valor en una variable (@my_city) y después lo rescatamos:

+----------+
| @my_city |
+----------+
| Dortmund |
+----------+

Tal vez este método es más limpio que el anterior. De todos modos para la próxima entrega, esta vez sí, postearé el DLookup mediante código en .NET, que será bastante más potente al incorporar gestión de errores y no tener limitaciones fruto de tener que especificar el tipo de datos concreto que esperamos obtener. No obstante un DLookup en MySQL se ejecutará íntegramente en el servidor, mientras que uno en .NET tendrá una parte ejecutándose en la máquina cliente, así que dependerá del gusto de cada cual escoger uno u otro. Yo me inclino por la versión en .NET...