Artículos y recursos relacionados
- KB-LJW-DB-101 : Impacto de los tipos de cursores ADO en un controlador ODBC en ASP
- KB-LJW-DB-104 : Gestión de datos de tipo "DATE" con MySQL y MariaDB
Drivers MariaDB instalados en nuestros servidores ASP Classic
Por razones de fiabilidad y sostenibilidad de la licencia, el motor de bases de datos MariaDB está instalado en nuestros alojamientos compartidos ASP Classic. Por su parte, el motor de bases de datos MySQL sigue estando disponible y se instala bajo demanda en nuestros servidores dedicados, en versión 8.x o 5.x.
El motor MariaDB sabe importar y ejecutar sus bases MySQL. Los Drivers ODBC disponibles en nuestros servidores compartidos para acceder a sus bases MariaDB son los siguientes:
- {MariaDB ODBC 3.2 Driver}
- {MySQL ODBC 5.3 Unicode Driver}
- {MySQL ODBC 3.51 Driver}
¿Qué es MariaDB
MariaDB es un sistema de gestión de bases de datos relacional open source, compatible con MySQL del que es un derivado. Este motor está diseñado para almacenar, consultar y manipular datos estructurados mediante el lenguaje SQL. Al haber nacido de un fork (bifurcación del código fuente) de MySQL en abril de 2009, MariaDB tiene como objetivo ofrecer una continuidad técnica: utiliza los mismos conceptos fundamentales (tablas, índices, motores de almacenamiento, transacciones), los mismos protocolos de red y una compatibilidad muy alta a nivel de consultas y esquemas.
MySQL era propiedad y estaba patrocinado por la empresa sueca MySQL AB, que fue adquirida en febrero de 2008 por Sun Microsystems, hoy convertida en Oracle Corporation. En 2009-2010, cuando Oracle adquirió Sun, se creó un fork (una rama separada) surgido del proyecto open source MySQL: MariaDB. Esta rama separada se creó debido a preocupaciones relacionadas con la gestión de productos de Oracle y su política comercial y tarifaria, susceptible de evolucionar de manera arbitraria y de amenazar la gratuidad e incluso la propia disponibilidad de MySQL a medio plazo.
Ambos comparten el mismo motor y una compatibilidad técnica muy alta, ya que las bases MySQL y MariaDB pueden convertirse de un motor a otro y funcionar de la misma manera, a veces con ajustes menores. Por ello, MariaDB se considera un reemplazo directo de MySQL.
MariaDB se ha consolidado como el proyecto más dinámico y el que recibe actualizaciones con mayor regularidad. MariaDB ha sido adoptado por un número creciente de empresas y productos, como Google, Mozilla o incluso Plesk, que desde 2022 lo ha integrado por defecto en sustitución de MySQL, ya que este último ya no es instalado por Plesk de forma predeterminada. Las principales ventajas de MariaDB son su carácter libre y gratuito, así como el dinamismo y la regularidad en la producción de actualizaciones, innovaciones y optimizaciones.
MariaDB constituye una alternativa sólida y madura ampliamente adoptada en producción por numerosas empresas y actores. Su desarrollo comunitario, su gobernanza abierta y su ritmo de innovación lo convierten en una elección pertinente para utilizar un equivalente de MySQL, pero sin dependencia de un único editor (Oracle).
Importación de bases de datos MySQL a MariaDB
Debido a la raíz común de los motores MySQL y MariaDB, la importación de datos suele ser muy sencilla. Asegúrese de disponer de una copia de seguridad nativa de su base MySQL, es decir, una copia realizada por el propio motor MySQL o por una herramienta fiable como los DUMP de Plesk, NaviCat o phpMyAdmin. Las copias de seguridad de su base MySQL realizadas con software menos fiable (por ejemplo, EMS SQL Manager for MySQL) o con versiones antiguas pueden resultar menos compatibles y ser más complejas de importar en MariaDB.
Nuestros clientes realizan por ejemplo con frecuencia importaciones de este tipo:
- Desde: MySQL 5.x (motor de almacenamiento MyISAM) con codificación "utf8_general_ci"
- Hacia: MariaDB 11.4 (motor de almacenamiento InnoDB) con codificación "utf8mb4_unicode_ci"
Una vez que su base de datos haya sido convertida al motor MariaDB, le desaconsejamos restaurar o importar antiguas copias de seguridad MySQL de su base, ya que podría provocar una corrupción de datos. Tal importación es posible con precauciones y verificaciones previas de los datos. Podemos asistirle si desea importar datos desde MySQL hacia MariaDB.
Cómo gestionar y administrar las bases de datos MariaDB
Las bases de datos MariaDB disponibles en sus alojamientos proporcionados en nuestros servidores son accesibles de la misma manera que sus bases MySQL, es decir, desde la interfaz PHPMyAdmin proporcionada desde Plesk, y desde cualquier otro software de gestión remota de bases de datos compatible.
En cuanto a esta compatibilidad, los programas cliente de gestión de bases de datos que utiliza para administrar sus bases deben ser capaces de soportar de forma fiable conexiones a un servidor MariaDB 11.4+, al motor de almacenamiento InnoDB y a la codificación/cotejamiento utf8mb4_unicode_ci. Recomendamos, a modo de ejemplo, HeidiSQL (gratuito), Navicat (de pago), o DbVisualizer (de pago), siendo esta lista no exhaustiva. Existen otros programas según sus necesidades y preferencias, pero asegúrese de su fiabilidad y dé prioridad a las versiones recientes y actualizadas.
Cómo acceder a las bases de datos MariaDB desde ASP Classic
La conexión a sus bases de datos MariaDB desde su sitio ASP Classic se realiza de la misma manera que lo hace con MySQL. Solo cambia el nombre del Driver ODBC y, eventualmente, las OPTION (Flags) que indique en su cadena de conexión.
El acceso a sus bases de datos MariaDB desde sus páginas ASP a través de ADO debe hacerse mediante el Driver {MariaDB ODBC 3.2 Driver} o {MariaDB ODBC 3.1 Driver} en función del que esté instalado en el servidor Windows.
Dado que los motores de MariaDB y MySQL son próximos, incluso puede acceder a sus bases MariaDB mediante el Driver {MySQL ODBC 3.51 Driver} o bien {MySQL ODBC 5.3 Unicode Driver}. No obstante, este procedimiento solo debe utilizarse en casos muy específicos y si domina perfectamente lo que está haciendo. En general, se recomienda utilizar el Driver ODBC proporcionado y previsto para este fin, {MariaDB ODBC 3.2 Driver}.
El establecimiento de conexiones a otras fuentes de datos, como por ejemplo Microsoft Access o Excel, puede incluir el parámetro Provider= en la cadena de conexión. En ausencia de este parámetro, ADO utiliza el provider predeterminado para los Drivers ODBC, a saber MSDASQL (Microsoft OLE DB provider for ODBC).
Cuando establece una conexión a su base MariaDB a través de un Driver ODBC desde su código ASP, establece una conexión denominada "DSN-Less". En este caso no necesita especificar Provider=MSDASQL en su cadena de conexión: ADO lo utiliza implícitamente. Consulte a este respecto nuestro artículo relativo al impacto de los tipos de cursores ADO sobre el acceso a sus bases MariaDB.
Una excepción a señalar: probablemente deberá añadir Provider=MSDASQL; DSN=MonDSN; a su cadena de conexión si establece la conexión mediante un DSN.
El uso de un Driver diseñado para MySQL puede permitirle en algunos casos evitar ciertos errores que pueden surgir si accede a sus Recordset de forma demasiado permisiva. A la inversa, el uso de un Driver diseñado para MySQL no debería serle necesario si ha programado su ASP Classic siguiendo las buenas prácticas relacionadas con la declaración explícita del tipo de cursor mediante la propiedad rs.CursorType.
El siguiente código le muestra cómo establecer una conexión DSN-Less a su base de datos MariaDB y cómo especificar ciertos Flags en el parámetro OPTION.
<%
'Declarar las Opciones/Flags de conexión MariaDB posiblemente útiles con ADO + ASP Classic (lista no exhaustiva)
'Referencias & Listas (incompletas):
'https://mariadb.com/docs/connectors/mariadb-connector-odbc/mariadb-connector-odbc-guide#general-connection-parameters
'https://docs.skysql.com/Connecting%20to%20SkySQL%20DBs/Connect%20using%20ODBC/#options-bitmask
'Algunas Opciones/Flags de conexión existen y están heredadas del motor MySQL:
'https://dev.mysql.com/doc/connector-odbc/en/connector-odbc-configuration-connection-parameters.html#codbc-dsn-option-flags
Dim CONST_DB_MARIADB__FOUND_ROWS : CONST_DB_MARIADB__FOUND_ROWS = 2
Dim CONST_DB_MARIADB__NO_PROMPT : CONST_DB_MARIADB__NO_PROMPT = 16
Dim CONST_DB_MARIADB__DYNAMIC_CURSOR : CONST_DB_MARIADB__DYNAMIC_CURSOR = 32
Dim CONST_DB_MARIADB__NO_SCHEMA : CONST_DB_MARIADB__NO_SCHEMA = 64
Dim CONST_DB_MARIADB__COMPRESSED_PROTO : CONST_DB_MARIADB__COMPRESSED_PROTO = 2048
Dim CONST_DB_MARIADB__NO_CACHE : CONST_DB_MARIADB__NO_CACHE = 1048576
Dim CONST_DB_MARIADB__FORWARD_CURSOR : CONST_DB_MARIADB__FORWARD_CURSOR = 2097152
Dim CONST_DB_MARIADB__MULTI_STATEMENTS : CONST_DB_MARIADB__MULTI_STATEMENTS = 67108864
'Declarar el valor (suma) de las opciones que se deben proporcionar al Driver ODBC MariaDB
'(lista recomendada, a personalizar según sus necesidades)
Dim dbConnOptions
dbConnOptions = CONST_DB_MARIADB__FOUND_ROWS + CONST_DB_MARIADB__NO_PROMPT
'Declarar la cadena de conexión a la base de datos mediante el Driver MariaDB
Dim dbConnString : dbConnString = "Driver={MariaDB ODBC 3.2 Driver}; Server=127.0.0.1; Charset=utf8; Port=3306; Database=dbName_abcdef; User=dbUser_test_abc123; Password=dbPw_abcdef12345; Option=" & dbConnOptions & ";"
'Si utiliza tablas codificadas en utf8mb4, añada lo siguiente a su cadena de conexión:
dbConnString = dbConnString & "InitStmt={SET NAMES 'utf8mb4';}"
''ALTERNATIVA: El tipo de collation normalmente ya está incluido en la definición de la tabla.
''No obstante, puede forzarlo para esta conexión si lo desea:
'dbConnString = dbConnString & "InitStmt={SET NAMES 'utf8mb4' COLLATE utf8mb4_unicode_ci;}"
'Abrir la conexión a la base de datos
Set dbConn = Server.CreateObject("ADODB.Connection")
dbConn.Open dbConnString
%>También dispone del parámetro INITSTMT, que permite ejecutar instrucciones SQL al iniciar la conexión. Si desea ejecutar varias instrucciones SQL al inicio de su conexión, debe obligatoriamente proteger estas diferentes instrucciones SQL con llaves {} para agruparlas. De lo contrario, los puntos y coma que separan cada instrucción SQL serán interpretados erróneamente por el analizador ODBC. Es un matiz importante, ya que el punto y coma se utiliza como separador tanto por el analizador SQL como por el analizador ODBC. La forma correcta es, por tanto: InitStmt={SET SESSION sql_mode='STRICT_TRANS_TABLES,NO_ZERO_DATE,NO_ZERO_IN_DATE'; SET time_zone='+00:00'; SET NAMES utf8;}. Deberá haber añadido el valor del Flag MULTI_STATEMENTS (67108864) para poder ejecutar varias instrucciones. Por último, tenga en cuenta que algunos Drivers ODBC solo ejecutan la primera instrucción SQL e ignoran las siguientes.
Motores de almacenamiento MyISAM e InnoDB
Los servidores de bases de datos MySQL y MariaDB admiten los dos tipos de motores principales, que son MyISAM e InnoDB. No obstante, por las razones expuestas más abajo en los párrafos siguientes, le recomendamos priorizar el motor de almacenamiento InnoDB y migrar las tablas de su base de datos desde el motor MyISAM hacia el motor InnoDB. Puede realizar esta conversión progresivamente, tabla por tabla. Estamos a su disposición para asistirle en esta operación si así lo desea.
El motor de almacenamiento MyISAM es antiguo y fue utilizado históricamente por defecto por MySQL. Sigue siendo compatible con MySQL y MariaDB. Desde hace ya varios años, el motor de almacenamiento InnoDB se ha convertido en el estándar, debido a su mayor fiabilidad y a sus mejores prestaciones generales tanto en lectura como en escritura. El motor InnoDB soporta mucho mejor el aumento de carga en términos de volumen de datos y de tráfico que el motor MyISAM, que puede provocar ralentizaciones cuando se alcanzan volúmenes a gran escala. Una de las principales razones para utilizar InnoDB en lugar de MyISAM es la ausencia de bloqueo completo a nivel de tabla, lo que permite acelerar el tratamiento de las consultas.
Les principales différences entre InnoDB et MyISAM sont les suivantes :
- InnoDB dispone de un bloqueo granular. MyISAM solo dispone de un bloqueo completo a nivel de toda la tabla.
- InnoDB posee lo que se llama integridad referencial, lo que implica la compatibilidad con claves foráneas (SGBDR) y restricciones relacionales, cosa que MyISAM no hace (DMBS).
- InnoDB admite transacciones, lo que significa que puede confirmarlas o anularlas. No es el caso de MyISAM, que aplica de facto cualquier consulta.
- InnoDB es más fiable porque utiliza logs de transacciones para la recuperación automática, lo que no está implementado en MyISAM.
Codificación y collation
Codificación de caracteres (charset)
En el motor MariaDB, la codificación (charset / juego de caracteres) define cómo se representan los caracteres en memoria y se almacenan en disco. La codificación responde a la pregunta: « ¿qué símbolos puedo almacenar y cómo se codifican en bytes? ». Por ejemplo, la codificación utf8mb4 permite representar todo el juego de caracteres Unicode (incluidos los emojis), mientras que la codificación latin1 sabe almacenar un número de caracteres mucho más limitado.
Collation de caracteres
La collation no se refiere al almacenamiento de los caracteres en sí, sino a la manera de comparar y ordenar las cadenas de caracteres. Define las reglas lingüísticas: sensibilidad a mayúsculas y minúsculas, a los acentos, orden alfabético y equivalencias entre caracteres. En resumen, la codificación describe qué se puede almacenar, y la collation indica cómo se comparan esos datos almacenados. La collation de referencia para la codificación utf8mb4 es la collation utf8mb4_unicode_ci.
Existen varias collations para una misma codificación (por ejemplo utf8mb4_general_ci, utf8mb4_unicode_ci, utf8mb4_bin), y su elección afectará a la manera de comparar, ordenar y clasificar sus datos. En caso de necesidad, el tipo de collation puede forzarse al ejecutar su consulta SQL mediante COLLATE, como muestra este ejemplo:
SELECT * FROM miTabla ORDER BY miTabla.champ COLLATE utf8mb4_unicode_ci;Relaciones entre codificación y collation
La codificación y la collation están íntimamente ligadas, porque cada collation está definida para una codificación determinada. Por lo tanto, no puede aplicar una collation utf8mb4_* a una columna cuyo juego de caracteres esté definido en latin1. MariaDB utiliza siempre, por tanto, el par codificación–collation para manipular texto. En la práctica, esto tiene consecuencias directas: una cláusula ORDER BY, un GROUP BY o una comparación (= , LIKE) dependerán de la collation, mientras que los problemas de caracteres corruptos (símbolos �) casi siempre se deben a una mala codificación.
A veces puede resultar tentador modificar la collation para « corregir » un problema de visualización, pero esto funciona muy raramente. La regla sana es sencilla: elija una codificación moderna y universal (recomendamos utf8mb4), y después seleccione una collation adaptada al comportamiento funcional esperado (comparación estricta, insensible a mayúsculas y minúsculas, respeto lingüístico, etc.) (recomendamos utf8mb4_unicode_ci).
Documentación oficial de MariaDB relativa a los charsets y collations disponibles:
- Presentación y generalidades sobre los charsets y las collations en MariaDB
- Lista de los charsets y collations disponibles en MariaDB
Conversión de la codificación a "utf8mb4_unicode_ci"
Esta sección le presenta las ventajas de realizar una migración de las tablas con una codificación utf8_general_ci o latin1_swedish_ci hacia utf8mb4_unicode_ci.
Sepa ante todo que MariaDB admite todos los charsets y collations utilizados históricamente por MySQL. Por tanto, no tiene ninguna obligación de realizar esta migración. Sin embargo, si sus tablas están destinadas a contener datos con caracteres acentuados, información introducida por los usuarios o caracteres avanzados (como los Emojis), entonces leer esta sección será probablemente la mejor decisión que haya tomado hoy.
UTF-8 es un método de codificación que traduce cualquier carácter basado en Unicode en una cadena. UTF-8 es uno de los sistemas de codificación más utilizados para Unicode. UTF significa « Unicode Translation Format »: su función es traducir los caracteres Unicode en cadenas binarias correspondientes y viceversa.
La codificación utf8mb4 ofrece compatibilidad Unicode completa y admite una gama más amplia de caracteres, lo que permite utilizar símbolos que requieren hasta 4 bytes por carácter. Esta gama de caracteres incluye los nuevos Emojis, emoticonos como ☺, 😍, 😐, etc.
Ahora bien, contrariamente a su denominación, la codificación utf8 en MySQL no cumple la norma UTF-8, debido a que no admite el número correcto de bytes por carácter. MySQL corrigió este error únicamente a partir de MySQL 8, utilizando desde entonces por defecto el juego de caracteres utf8mb4 en lugar del utf8 incompleto, utilizado hasta entonces en las versiones anteriores, y en particular en MySQL 5.x. Por ello, para garantizar una compatibilidad completa y correcta con el estándar UTF-8, conviene utilizar la codificación de caracteres utf8mb4.
La codificación latin1_swedish_ci era, por su parte, el cotejamiento predeterminado de MySQL 5.x (antes de MySQL 8) para la codificación latin1 (ISO-8859-1), elegido históricamente por razones de simplicidad y rendimiento, sin relación real con la lengua sueca. Durante mucho tiempo fue aceptado y utilizado por inercia, pero gestiona mal los idiomas no occidentales, los caracteres acentuados complejos y toda compatibilidad Unicode moderna, lo que ha provocado innumerables errores de codificación silenciosos. Los datos corruptos y almacenados con la codificación incorrecta en sus tablas son muy difíciles de recuperar. En su época, era rápido, ligero y suficiente para aplicaciones occidentales simples. Hoy en día está obsoleto y desaconsejado, en favor de una migración hacia utf8mb4.
MariaDB, por su parte, respeta más las normas por ser más reciente. Gestiona de forma nativa la codificación utf8mb4 de manera fiable. La gestión incompleta de UTF-8 en MySQL 5.x hace imposible almacenar caracteres que requieren 3 o 4 bytes comprendidos en la norma UTF-8, como los Emojis, hoy en día de uso común. Intentar insertar tales caracteres en una tabla en utf8 (que no esté en utf8mb4) provoca errores de ejecución del tipo: Valor de cadena incorrecto: « \x77\xD0 » para la columna "column_name" en la fila 1. Esta es la razón principal por la que ciertos datos se muestran de forma incorrecta para algunos usuarios de MySQL que utilizan esta codificación histórica utf8.
Conviene señalar que existen dos tipos de codificación disponibles para utf8mb4:
- utf8mb4_unicode_ci, que está perfectamente alineado con la norma real UTF-8 y por tanto es recomendado y utilizado por defecto por MariaDB y las versiones recientes de MySQL (8.x)
- utf8mb4_general_ci, que está destinado a casos de uso generales. Aunque este juego de caracteres se llama utf8mb4, también está implementado de forma incompleta en MySQL. Se trata de una versión parcial de utf8mb4 diseñada para tomar atajos con el fin de mejorar el rendimiento de la base de datos.
Casos particulares con MariaDB
Dado que MariaDB es más reciente que MySQL, respeta en mayor medida la norma ODBC 3.8 y resulta menos permisivo en algunos casos muy específicos.
En la inmensa mayoría de los casos, la importación de sus bases de datos MySQL existentes funcionará inmediatamente en el motor MariaDB, a menudo con ganancias de rendimiento.
Pueden surgir algunos casos muy particulares: consulte nuestra base de conocimientos o póngase en contacto con nuestro equipo para asistirle si encuentra cualquier dificultad.
Gestión de datos de tipo DATE
Puede que encuentre algunos casos particulares relacionados con la gestión de campos de tipo Date, especialmente con valores vacíos, o si desea almacenarlos en un formato diferente del estándar ISO YYYY-MM-DD HH:MM:SS.
Consulte los consejos y buenas prácticas en nuestro artículo KB-LJW-DB-104 sobre este tema.
Cursor predeterminado
El Driver {MariaDB ODBC 3.2 Driver} utiliza por defecto un cursor Forward-Only (SQL_CURSOR_FORWARD_ONLY) si el tipo de cursor no se proporciona en las OPTION de su cadena de conexión. Esto difiere del comportamiento observado anteriormente con el Driver {MariaDB ODBC 3.1 Driver}, que utilizaba un cursor estático (SQL_CURSOR_STATIC) como cursor predeterminado.
ADO nunca cede el control al cursor predeterminado del Driver ODBC, y especifica como mínimo 0=adOpenForwardOnly. En consecuencia, este cambio a nivel del Driver ODBC no debería en la práctica tener ningún impacto en su código ASP.
Consulte nuestro artículo KB-LJW-DB-101 sobre este tema.
Le asistimos con IIS y su código ASP Classic.
Póngase en contacto con nuestro equipo.
