Lors de tries par page ou par ligne en base de données, il est parfois utile d'attribuer un rang pour chaque enregistrement. Voici une requête SQL qui vous permettra d'effectuer une telle opération :
SELECT (
SELECT COUNT(id) FROM table t2
WHERE t2.titre <= t1.titre
) AS rang , t1.*
FROM table t1
ORDER BY t1.titre
Problème du jour :
Vous avez une table en latin1_general_ci (ou un interclassement assez proche), et vous souhaitez effectuer une recherche sur le terme "cinéma" avec un LIKE.
Un problème va se poser si l'utilisateur saisit "cinema" et non "cinéma"... votre requête ne retournera aucun résultat...
SELECT * FROM `table` WHERE `texte` LIKE '%cinema%' ;
Une partie de la solution se trouve dans l'interclassement, si vous effectuez cette même requête LIKE dans une table en utf8_general_ci, le résultat retournera tous les "cinéma" !
Certains diront sûrement qu'il suffit de changer l'interclassement et le problème sera réglé mais parfois vous n'avez pas cette possibilité pour diverses raisons...
Voici une solution qui je l'espère vous plaira, il "suffit" de traiter le texte reçu en latin1 ISO-8859-1 dans la requête avec un CONVERT(_utf8 '%...%' USING utf8) COLLATE utf8_general_ci :
SELECT * FROM `table`
WHERE `texte` LIKE CONVERT(_utf8 '%cinema%' USING utf8) COLLATE utf8_general_ci ;
En promo : Comment réinitialiser le numéro identifiant AUTO_INCREMENT dans une table ?
ALTER TABLE `table` AUTO_INCREMENT = 1 ;
L'astuce suivante consiste à copier une table avec ses données, mais surtout en faire une copie conforme. Le but étant de conserver les types et les index :
CREATE TABLE table_destination LIKE table_source ;
INSERT INTO table_destination SELECT * FROM table_source ;
Le contre-exemple le plus connu est la ligne de commande suivante :
CREATE TABLE table_destination SELECT * FROM table_source ;
La ligne ci-dessus fera une copie des données, mais la structure de la table de destination suivera simplement les besoins de la requête SELECT.
PostgreSQL n'est pas à vendre
À la lumière du récent rachat de MySQL, j'aimerais une fois de plus répondre à une question qui nous est posée de temps en temps: «Qui rachètera PostgreSQL?». Bien sûr, cela fait sourire ceux qui sont immergés dans le monde de l'Open Source, mais nous y répondons invariablement «PostgreSQL ne peut pas être acheté». Bien que de loin MySQL et PostgreSQL se ressemblent (ce sont des "bases de données Open Source"), il s'agit de deux choses très différentes, aussi bien sur le plan technique que sur le reste. On pourrait résumer leurs différences comme cela:
MySQL est un PRODUIT Open-Source
PostgreSQL est un PROJET Open-Source
Bien que 'produit' et 'projet' soient des mots proches, la distinction est énorme. MySQL est dirigé par une organisation à but lucratif (MySQL AB), à qui appartient le code, qui a embauché pratiquement tous les développeurs, qui dirige de manière autoritaire dans quelle direction doit aller le produit, et qui a le droit de changer (et ne s'en est pas privé) la licence d'utilisation du logiciel (ainsi que de sa documentation).
À l'opposé, PostgreSQL n'est pas dirigé par une société, le projet est contrôlé par la communauté, il n'y a aucun problème sur la licence, les développeurs principaux sont répartis sur un large spectre d'organisations publiques ou privées. Comment un logiciel peut profiter d'un tel système ? Bien, la signification originale de LAMP a évolué (selon: Linux, Apache, MySQL, Middleware, PHP, Perl...) en des modèles similaires, et tous fonctionnent. Tout comme PostgreSQL, il n'y a aucun moyen "d'acheter" ces projets.
Je ne sais pas trop quoi penser du rachat à ce jour. Il m'est difficile de savoir si cela sera bon ou mauvais pour PostgreSQL (le produit du projet), ou bon ou mauvais pour MySQL (le produit). C'est probablement mauvais pour le projet MySQL, je pense en effet que les employés de MySQL AB et la communauté auraient préférés l'option IPO jadis promise. Cela leur aurait probablement rapporté plus de publicité et de visibilité sur le long terme. Pour faire court, le produit (MySQL) sera inévitablement ralenti, le temps que la société (MySQL AB) soit absorbée par Sun (ce n'est pas la peine de mentionner que Falcon ne sera peut-être jamais terminé). Sur le long terme, cela sera peut-être un "plus" pour le produit. Pour l'instant, les plus gros gagnants sont les investisseurs et les directeurs, qui n'ont probablement pas réfléchi trop longtemps pour accepter une offre de 800 millions de dollars.
Est-ce que Sun continuera de supporter PostgreSQL? Ils disent que oui, bien que de toute façon ils ne contribuent pas énormément à PostgreSQL, en termes d'effort de développement ou de contributions en argent. Les sociétés qui voudraient contribuer à PostgreSQL peuvent non seulement embaucher les développeurs du projet, mais peuvent aussi donner au SPI (Software in the Public Interest, une organisation à but non lucratif, loi américaine 501(c)(3). Ainsi, si Sun ne veut pas démontrer son support continu à PostgreSQL en payant 1 million de dollar pour écrire du code résolument génial, ils peuvent toujours participer en donnant de l'argent via le SPI...
Article : Greg Sabino Mulane « Postgres is not for sale » -
Traduction: Jean-Paul Argudo
Source: PostgreSQLFr.org
Le principal avantage est de pouvoir construire des requêtes beaucoup plus complexes qu'un simple LIKE en exploitant toute la puissance des expressions régulières.
Quelques exemples basiques
SELECT * FROM clients WHERE nom LIKE 't%' ;
SELECT * FROM clients WHERE nom REGEXP '^t' ;
SELECT * FROM clients WHERE nom LIKE '%d' ;
SELECT * FROM clients WHERE nom REGEXP "d$";
Exemple plus difficile à réaliser avec un simple LIKE
SELECT * FROM clients WHERE nom REGEXP '^.{4}$' ;
Autre exemple : isoler un mot précis
SELECT * FROM textes WHERE contenu REGEXP '[^a-z]bonjour[^a-z]' ;
Si vous désirez que votre requête soit sensible à la casse, vous devez utiliser la commande REGEXP BINARY.
SELECT * FROM textes WHERE contenu REGEXP BINARY '[^a-zA-Z]Bonjour[^a-zA-Z]' ;
Attention: Au niveau sécurité, au delà de la protection contre les injections SQL, n'oubliez pas aussi de protéger vos requêtes contre les injections d'expressions régulières par rapport aux caractères spéciaux comme les ".", "*", "+", "?", etc...
Sun Microsystems annonce qu'il achètera pour un milliard de dollars (675 millions d'euros) environ le développeur de bases de données open source MySQL AB.
Sun a précisé qu'il payerait autour de 0 millions en cash en échange de tous les titres MySQL et reprendrait environ 0 millions d'options.
Sun s'attend à ce que l'opération, qui devrait être bouclée vers la fin du troisième trimestre ou le début du quatrième de l'exercice fiscal 2008, accroisse son bénéfice opérationnel 2010.
Sun a par ailleurs déclaré mercredi s'attendre à une hausse de son chiffre d'affaires et de son bénéfice au deuxième trimestre de son exercice, clos le 30 décembre.
Le groupe américain table sur une hausse d'environ 1% de son chiffre d'affaires trimestriel à 3,6 milliards de dollars et sur un bénéfice net de 230-265 millions de dollars, soit 28-32 cents par action, contre 133 millions de dollars, ou 15 cents par action, un an plus tôt.
Les analystes tablent eux en moyenne sur un C.A. de 3,52-3,67 milliards et sur un BPA de 20-38 cents avant éléments exceptionnels, selon Reuters Estimates.
Les commandes nettes trimestrielles ont elles progressé d'environ 7% à 3,85 milliards de dollars, précise mercredi le groupe.
L'action est en hausse de 4% à 15,57 dollars en avant-Bourse.
Source: Liberation.fr
Il faut spécifier dans les scripts PHP que les données transmises sont en UTF-8.
...
// avec MySQLi
mysqli_query($link, "SET NAMES 'utf8' ");
// ancienne méthode
mysql_query("SET NAMES 'utf8' ");
...
