Mais à quoi peuvent bien servir les normes SQL?

De temps en temps, on entend parler des normes SQL, mais dans la réalité, ces normes paraissent bien théorique voire inutiles.
Néanmoins, voici un exemple ou l’emploi des normes SQL peut permettre d’éviter des situations délicates.

Lors de l’utilisation des ETL, une pléthore de fonctions SQL peut être proposée. Ces fonctions lors de créations de mappings et de transfromations sont très utiles. Néanmoins, un grand nombre de celles-ci sont propriétaires.

En premier lieu, les fonctions propres à l’ETL, seront souvent implémentées par le serveur ETL et ne pourront en aucun cas être confiées au serveur de BDD. D’autres, seront traduites en fonctions BDD, les choix de traduction peuvent être corrects, mais aussi surprenants, voire pénalisants. Ils resteront propres à l’ETL et vous ne serez pas maitre de ceux-ci.

Ensuite, les fonctions propres à la BDD, peuvent être mises en oeuvre directement sur le serveur BDD; l’ETL soumettra une requête optimisée et efficace pour votre base. Ainsi, une commande peut récupérer des données agrégées depuis la base de données, alors que l’utilisation de fonctions d’agrégation preopres à l’ETL forcerait le rapatriment de toutes les données avant de faire l’agrégation.

Par contre, dans le cas de l’utilisation de fonctions SQL standards, un avantage supplémentaire peut être tiré. En cas de migration de base de données, l’ETL propose surement des drivers ODBC adaptés. Les fonctions utilisables sans opérations de maintenance sot les foctions propriétaire ETL et les fonctions standard SQL. Les fonctions propriétaires BDD sont à migrer.

Ainsi, le choix du type de fonction utilisées lors de l’implémentation sera déterminant pour les futures optimisations et migrations. Le plus maléable est de se conformer aux normes SQL.
Donc l’utilisation des normes peut être un atout lors de l’implémentation d’un process d’alimentation.

Related articles

• Du mauvais usage du TRUNCATE (aprevotleygonie.wordpress.com)

No SQL rime t-il avec No Future?

L’arrivée du terme No SQL dans le language informatique ‘hype’ a fait l’effet d’un électrochoc dans ma tête. Immaginez 15 Ans de réflexion, d’études, d’utilisation des languages SQL, SQL+, PL/SQL anéantis par le NoSQL. Ce nouveau concept mettra t-il à terre un language faisant référence depuis 1974?
Près de 40 ans d’informatique et de SGBDR réduits à néant, et rendu définitivement has been! La majorité des produits de reporting et des ETL seraient donc basés sur des principes néandertaliens, au bord de la disparition.

Fort de ces réflexions, je me suis renseigné; WIKIPEDIA est mon amie. Voici donc le lien vers la page faisant le point sur cette menace pour les métiers de la BI:
http://fr.wikipedia.org/wiki/NoSQL

Ainsi, le concept est réellement nouveau, rien encore de bien précis. Le dinosaure du reporting a encore quelques temps devant lui, mais ce concept est à surveiller de près. Une révolution est peut-être en marche.

Related articles

• Going NoSQL with SQL (architects.dzone.com)
• NoSQL – Not only SQL (Introduction to Apache Cassandra) (clean-clouds.com)

Du mauvais usage du TRUNCATE

En préambule, voici la définition du TRUNCATE SQL(WIKIPEDIA):

In SQL, the TRUNCATE TABLE statement is a Data Definition Language (DDL) operation that marks the extents of a table for deallocation (empty for reuse).
The result of this operation quickly removes all data from a table, typically bypassing a number of integrity enforcing mechanisms.
It was officially introduced in the SQL:2008 standard.

The TRUNCATE TABLE mytable statement is logically (though not physically) equivalent to the DELETE FROM mytable statement (without a WHERE clause).
The following characteristics distinguish TRUNCATE TABLE from DELETE:
*In the Oracle Database, TRUNCATE is implicitly preceded and followed by a commit operation. (This may also be the case in MySQL, when using a transactional storage engine.)
*Typically, TRUNCATE TABLE quickly deletes all records in a table by deallocating the data pages used by the table. This reduces the resource overhead of logging the deletions, as well as the number of locks acquired. Records removed this way cannot be restored in a rollback operation. Two notable exceptions to this rule are the implementations found in PostgreSQL and Microsoft SQL Server, both of which allow TRUNCATE TABLE statements to be committed or rolled back transactionally.
*You cannot specify a WHERE clause in a TRUNCATE TABLE statement—it is all or nothing.
*TRUNCATE TABLE cannot be used when a foreign key references the table to be truncated, since TRUNCATE TABLE statements do not fire triggers. This could result in inconsistent data because ON DELETE/ON UPDATE triggers would not fire.
*In some database systems, TRUNCATE TABLE resets the count of an Identity column back to the identity’s seed.
*In Microsoft SQL Server 2000 and beyond in full recovery mode, every change to the database is logged, so TRUNCATE TABLE statements can be used for tables involved in log shipping. [1]

Lors de l’utilisation des ETL, la création d’un mapping peut, si on veut opérer en annule et remplace, faire appel à un mécanisme de suppression des données.
Ce mécanisme proposé est souvent nommé TRUNCATE TABLE.
Les ETL Buisness Objects Data Integrator et Informatica power Center sont tous deux concernés par ma remarque.
Ces ETL font appel à la commande SQL DELETE, et non au TRUNCATE SQL.

Voici donc la définition du DELETE SQL (WIKIPEDIA):

In the database structured query language (SQL), the DELETE statement removes one or more records from a table.
A subset may be defined for deletion using a condition, otherwise all records are removed.
Some DBMSs, like MySQL, allow to delete rows from multiple tables with one DELETE statement (this is sometimes called multi-table DELETE).

Ainsi, lors de suppression de gros volumes de données, l’ETL peut prendre un temps non négligeable, long, beaucoup trop long, voire s’approchant de l’infini.
En effet, le DELETE SQL réalise le nettoyage de la table LIGNE PAR LIGNE, alors que le TERUNCATE SQL fait la même opération, mais globalement.
Dans ce cas, il est souvent plus malin de ne pas suivre la voie tracée par l’ETL, de stopper l’alimentation, et de changer son fusil d’épaule.
Ainsi, Buisness Objects Data Integrator propose en alternative un DROP and RECREATE vraiement efficace.
Il aussi est possible de créer et appeler un code SQL faisant l’opération, que ce soit du TRUNCATE SQL ou DROP and RECREATE.

Related articles

• Heavy updates and deletions within an onFlush event handler (stackoverflow.com)

Tout sur mes TABLESPACES…

En chatouillant le crapeau TOAD, on peut obtenir quelques requêtes ORACLE fort intéressantes. Ainsi, lorsqu’on n’a pas le mot de passe SYSTEM et pas les droits sur les tablespaces, on peut avoir besoin de les surveiller pendant une alimentation ETL.

A l’aide du user oracle sous UNIX, il est possible de se connecter en tant que SYSDBA:

su – oracle
SET ORACLE_SID=base1
sqlplus /nolog connect / AS sysdba

Ensuite, il ne reste qu’à executer la requete sortie du fond de la mare:

SELECT t.tablespace_name « Tablespace »,  t.status « Tablespace Status »,  d.status « File Status »,  ROUND((d.max_bytes – NVL(f.sum_bytes, 0))/1024/1024) « Used MB »,  ROUND(NVL(f.sum_bytes, 0)/1024/1024) « Free MB »,  t.initial_extent « Initial Extent »,  t.next_extent « Next Extent »,  t.min_extents « Min Extents »,  t.max_extents « Max Extents »,  d.file_name « Datafile name »,  d.autoextensible
FROM
(SELECT tablespace_name, file_id, SUM(bytes) sum_bytes
FROM DBA_FREE_SPACE
GROUP BY tablespace_name, file_id) f,
(SELECT tablespace_name, file_name, MAX(bytes) max_bytes, status, autoextensible, file_id
FROM DBA_DATA_FILES
GROUP BY tablespace_name, file_name, status,autoextensible, file_id) d,
DBA_TABLESPACES t
WHERE t.tablespace_name = d.tablespace_name
AND f.tablespace_name(+) = d.tablespace_name
AND f.file_id(+) = d.file_id
GROUP BY t.tablespace_name, d.file_name, t.initial_extent,  t.next_extent, t.min_extents, t.max_extents,  t.pct_increase, t.status, d.max_bytes, f.sum_bytes, d.status,  d.autoextensible;