 Your new post is loading...
Your new post is loading...
Scoop.it!
“ORMs are not entirely useless…” I just tweeted in response to a not exactly constructive message that we should fire developers who want to use ORMs. But than I continued in a not exactly constructi 
No comment yet.
Sign up to comment
Scoop.it!
Clustered indexes are often considered the "silver bullet" for performance tuning. However, they introduce a hardly known penalty that sheds a different light on them.
Mickael Ruau's insight:
What makes the clustered index fast is that every (direct) access is an index-only scan. So the question essentially boils down to: “how many indexes can support an index-only scan?” And the simple answer is: as many as you like. All you need to do is to add all the required columns to a non-clustered index and *BAM* using it is as fast as though it was a clustered index. That’s what SQL Server’s INCLUDE keyword of the CREATE INDEX statement is for! Focusing on index-only scans instead of clustered indexes has several advantages
Scoop.it!
How to implement and use a row generator in MySQL, similar to PostgreSQL's GENERATE_SERIES function.
Mickael Ruau's insight:
A row generator is a method to generate numbered rows on demand. It is possible to build a row generator with pure standard SQL—using recursive common table expressions (CTE), the with clause. If you never heard of the with clause, it’s probably because MySQL doesn’t implement that specific part of the SQL-99 standard (feature request from 2006). This article introduces generator views for MySQL. Not as powerful as recursive CTEs, but good enough in most cases.
Scoop.it!
When we are hired for a MySQL performance audit, we are expected to review the MySQL configuration and to suggest improvements.
Scoop.it!
McAfee has released a free open-source audit plug-in that provides detailed database activity audits and helps satisfy audit requirements for MySQL databases. Via Gust MEES
Scoop.it!
From
gigaom
Twitter has shared numerous aspects of its infrastructure over the past few years, and its decision to open source its work on MySQL might be the social media platform’s most useful contribution yet. Via Amodiovalerio Verde
Scoop.it!
Principaux acteurs technologiques Big Data et cas d’utilisation que l’on peut leur associer. Via Duarte Terencio
Scoop.it!
NB: These techniques are universal, but for syntax we chose Postgres. Thanks to the inimitable pgAdminIII for the Explain graphics.
Mickael Ruau's insight:
via @gcouprie
Scoop.it!
There are many blog posts already written on topics related to “MySQL server memory usage,” but nevertheless there are some who still get confused when troubleshooting issues associated with memory usage for MySQL.
Scoop.it!
We are here with another set of 10 MySQL interview questions for intermediate users. Via alexander knorr
Scoop.it!
The other day I was working on an issue where one of the slaves was showing unexpected lag.
Scoop.it!
Les injections SQL font partie des vulnérabilités les plus courantes d'un site web. La 3e édition de l'ouvrage "Sécurité PHP 5 et MySQL" de Damien Seguy et Philippe Gamache revient en détails sur cet enjeu.
Scoop.it!
Même si vous n’êtes pas trop versé(e) dans l’informatique, le concept de « clé primaire » peut quand même vous avoir occasionné quelques maux au crâne - comme utilisateur ou comme
|
Scoop.it!
Should a SQL performance consultant be afraid of SSD? Some surprising facts why I'm not afraid of SSD.
Mickael Ruau's insight:
The story goes on: which database operation do you think causes most random IO operations? Of course it’s our old friend the join—it is the sole purpose of joins to gather many little data fragments from different places and combine them into the result we want. Joins can also greatly benefit from SSDs. SSDs actually voids one of arguments often brought up by NoSQL folks against relational databases: with SSD it doesn’t matter that much if you fetch data from one place or from many places. To conclude what I said to my client: No, as an indexing-focused SQL performance guy, I’m absolutely not afraid of SSD.
Scoop.it!
Is SQL-Performance black magic to you? Answering these five questions will teach you the most important facts about SQL-Tuning in just three minutes.
Mickael Ruau's insight:
The following questions provide examples that might make you believe that SQL tuning is black magic. The explanations at the end are just a few sentences long and reveal that the black magic is pure science. Choose your Database
Scoop.it!
During FOSDEM PGDay I watched the "Indexes: The neglected performance all-rounder" talk by Markus Winand. Both his talk and the "SQL Performance Explained" book (which is also available online) are great.
Scoop.it!
eSecurity Planet
Scoop.it!
A free tool for translating MySQL queries into MongoDB. Helpful for SQL users who want to learn about MongoDB by building on their existing knowledge.
Scoop.it!
Un règlement européen sur la protection des données personnelles est actuellement en discussion. Le texte, déposé en janvier 2012 et retravaillé par la suite, remet à plat toutes les règles en la matière et crée de nouvelles obligations pour les entreprises.
Mickael Ruau's insight:
A l'heure du big data, un enjeu colossal
Troisièmement, le règlement place de nouvelles obligations à la charge des entreprises. Elles reposent d'abord sur de nouveaux droits reconnus aux individus (droit à l'oubli, droit à la portabilité des données dans un format standard, droit à l'information renforcé...). En outre, la mise en place d'un correspondant informatique et libertés deviendrait obligatoire pour toute entreprise de plus de 250 salariés, tout comme la prise en compte des questions de protection des données personnelles dès la conception des produits ou services des entreprises (c'est le "privacy by design"). Et les sanctions seraient considérablement renforcées, pouvant atteindre jusqu'à 2% du chiffre d'affaires mondial de l'entreprise jugée fautive.
Scoop.it!
Elasticsearch is a great search engine, flexible, fast and fun. So how can I get started with it? This post will go through how to get contents from a SQL database into Elasticsearch.
Mickael Ruau's insight:
Elasticsearch has a set of pluggable services called rivers. A river runs inside an Elasticsearch node, and imports content into the index. There are rivers for twitter, redis, files, and of course, SQL databases. The river-jdbc plugin connects to SQL databases using JDBC adapters.
Scoop.it!
A question often comes when talking about indexing: should we use multiple column indexes or multiple indexes on single columns?
Scoop.it!
Compressed tables is an example of an InnoDB feature that became available with the “Barracuda” file format, released with InnoDB 1.1.
Scoop.it!
Converting Between Data Types in MySQL
Scoop.it!
Si vous changez l'encodage de données existantes, vous risquez de perturber les caractères existant. Procédez avec précaution et vérifiez régulièrement que vous n'avez pas altéré les caractères spéciaux en les rendant illisibles. Si c'était le cas, répétez les opérations en récupérant une copie des données de la table ou en partant d'une table vide puis en chargeant les données sauvegardées.
Mickael Ruau's insight:
Il existe différents encodages UTF8.
Préférez l'encodage utf8_general_ci qui n'a pas de spécificité régionale et est insensible à la casse de caractères.
Scoop.it!
Dans une base de données quelconque qui restera anonyme [1] un mien collègue a déniché qu’un mariage pouvait avoir une date de fin future planifiée (nous ne parlons pas des divorces passés ou proches). En l’occurrence, tous les mariages étaient censés se dissoudre le 31 décembre 9999. C’est évidemment stupide. Cette donnée aberrante est l’équivalent en date d’un nombre magique : une telle donnée possède un autre sens que sa simple valeur, en l’occurrence le fait q
ue la date de fin de mariage n’existe pas, le mariage n’a pas été dissous. Cela peut-il poser un problème réel dans le futur ? Je concède que la perspective est lointaine, mais il n’y a pas qu’un programme concerné par ce genre de phénomène, loin de là.
Mickael Ruau's insight:
cette application est mal programmée, elle ne distingue pas ce que toute base de données devrait connaître depuis plusieurs décennies, à savoir la distinction entre une donnée et une donne absente, ce qu’en langage de base de données on nomme NULL [4].
Au passage : Saint E. F. Codd aurait même voulu distinguer valeur existante inconnue et valeur sans signification, c’est-à-dire « Non renseigné » et « Non applicable ».
Les développeurs informatiques ne sont parfois même pas fichus de gérer correctement le cas du NULL.
Il a quelques propriétés surprenantes dont il faut tenir compte, comme 1 + NULL = NULL, ou comme la clause IF NULL = NULL qui renverra toujours « faux ».
Noter que selon les bases de données, une chaîne vide est équivalente à un NULL (Oracle) ou pas (SQL Server, PostgreSQL…).
Pour ne pas embrouiller plus les choses, le N/A a donc finalement été laissé de côté. Et, mine de rien, moi et mes collègues sommes obligés de le réintroduire de manière plus fastidieuse et visible dans les bases de données décisionnelles que nous sommes payés pour créer.
|
Well, I don’t think they “don’t know anything” but I wonder why they don’t provide decent solutions (including docs) for the two most striking performance problems caused by ORMs? Here they are: