Do we still need DBMS in web systems ? || A-t'on encore besoin des SGBD dans les systèmes orientés web ?

English:
I am actually working (quite a lot actually) on a system makeover for one of my clients. In a nutshell, it's an on-line (some would call it "cloud") system for their clients to administrate their business. The main issue with this system is the complexity of the process (a lot of the data are generated not just "proccessed") and the traffic. In this configurtion, what is the bottle neck ? The DBMS, and nobody will object.


Since the main reason behind this makeover is because of the intensive usage of the DBMS, the system was slow as hell. I know sql optimization etc... i am not a n00b, but think about this: Event if your sql statement is over-boosted etc... a sql that return 5000 records is still and sql that return 5000 records. That mean, there still 5000 records that the system have to processed, display etc. and i am not talking about the memory space used to store those 5000 records.


So,  i had to think a solution that use as less as possible the db. And i was able to redesign a system by reducing the number of db connection by 90% (maybe more i need to find a way to properly calculate it) and without any lost in term of functionlity and a definitly huge gain in speed and server load.


I then look at my documentation and ask myself: Why using a db for an applicative usage ? i don't put in line the need of a db, i clearly understand the benefit of it for reporting, analysis and other "off-line" operations.


It was possible by using what i call SOCS (Smart Object Caching System) and don't use db at all. Basically SOCS is like ORM, the difference is that instead of using the object as a bridge between the db and the application, the object IS the data and decide whether informations should be read from the db or written in the db. I will write an article later about it when the concept will be "clear enough" in my mind.


When i said "don't use db at all", i really meant it. For example content/file association. the best practice actually is the following flow:

 user access the content page -> retrieve the associed files' informations from the db -> integrate those information in the page

Don't you think there is a problem in this approch ? I always heard that the shortest and fastest path between two point is a straight line (event if i recently discussed the concept of "straight" line recently).
Let's illustrated this statement why the example of articles.
Most of the time, articles (blog tocket, articles etc...) are associated with pictures, pdf files etc... I won't discuss the silly practice you can find in every cms that store the text contents in db instead of a static html version. Anyway, in a decently structured system, every article have a unique id. So now ask yourself, why should you trigger the db to get the path to the images etc... when you can use the god speedly computer file system ? Why storing the file description in a db when you can use it as a file name ? Problem with space or special caracters ? You should maybe have a look at url encoding, base64 encoding etc... (i personanaly like url encoding).
isn't :

<?php

$article = 123456;

$file_list = sandir("/imgs/article/$article_id");

 ?>

<?php foreach($file_list as $image): ?>

<img src="/imgs/article/<?=$article_id?>/<?=$image?>" alt="<?=urldecode(substr($image,0,strrpos($image,'.')))?>"/>

<?php endforeach;?>

Faster than:

<?php

$article = 123456; 

$connection = new connection_to_db();

$sql = "SELECT file_name, file_description from file where article_id = $article";

$result = $connection->query($sql);

?>

<?php while($image = $result->fetch()): ?>

<img src="/imgs/article/<?=$article_id?>/<?=$image['file_name']?>" alt="$image['file_description']?>"/>

<?php endwhile; ?> 




I would simply conclude why the title: Do we still need DBMS in web systems ?


Français: 
Ces dernier temps je travaillais (et pas qu'un peu) sur la refonte d'un système d'un de mes clients. En gros, il s'agit d'un système de gestion en ligne pour aider leurs clients à gérer leur business. Le gros problème avec ce système est que la plupart des informations sont générées et non pas traitées en plus d'un trafic relativement élever. Dans ce cas de figure, quel est le point de rupture ? Le SGBD et personne ne me contredira.


Comme la raison principale de cette refonte et du au fait que le précédant système  utilisé de manière intensive la SGBD ce qui a eu pour conséquence que le système était devenu lent à en mourir. Bien sur je connais les optimisation de sql et ces conneries, mais une sql super optimisée qui retourne 5000 enregistrements, reste une sql qui retourne 5000 enregistrements. 5000 enregistrements qui doivent être traités, affichés etc... Et je ne parle pas de l'espace mémoire.

 Je me suis alors retrouvé penser un système qui solicite le moins possible la bd. Et le pire c'est que j'ai réussit à designer un système où le nombre de connection à la bd a été réduit de 90% par rapport à la précédente version (peut-être plus, mais faut que je trouve le moyen de calculer ça), le tout sans perte fonctionnel et avec un grand gain en terme de vitesse et de charge serveur.


Je me suis alors demandé: Pourquoi utiliser un bd à usage applicatif ? je ne remet pas en cause l'intérêt d'une base de données, je comprend très clairement leurs bénéfices dans les domaines du reporting, de l'analyse et autre traitement hors-ligne.


Ceci fut possible grace a ce que j'appelle SOCS (SMART OBJECT CACHING SYSTEM, en français Système de Cache Objet Intelligent) et pas utiliser la base de données du tout. SOCS c'est un peut comme ORM, à l'exception faite que dans ORM l'objet est un pont entre la base de données et l'application alors que dans SOCS les données sont stockées dans l'objet qui décide s'il faut lire l'information depuis la base ou écrire dans la base ou rien faire :P J'écrirais un article à ce sujet quand le concept sera "suffisamment clair" dans mon esprit.



Quand je disais, "pas utiliser la base de données du tout", je déconnais pas. Prenons l'exemple de l'association contenue/fichier associés. La "best practice" et de faire:
L'utilisateur accède au contenue -> on connecte à la base de données pour récupérer les fichiers associés -> on les incorpores dans le document
Vous pensez pas qu'il ai un problème là ? On m'a toujours dis que le chemin le plus court et le plus rapide entre deux points était un ligne droite (je sais il n'y a pas longtemps j'ai remis en cause le concept de ligne droite mais bon).
Discutons alors du au combien récurent exemple de l'article.




Un article (un ticket de blog, une page informative etc..) est le plus souvent associé avec des fichiers: images, pdf etc...Je ne discuterais pas la stupide pratique qu'on retrouve dans tout les cms qui consiste à stocker les article dans la base de données au lieu d'un fichier html statique. Toujours est-il,  dans un système qui à une structure décente, chaque article à un identifiant unique. Posez-vous la question suivante: Pourquoi connecter la base de donnée pour obtenir la localisation d'une image etc. quand on peut utilise le système "speedy gonzales" fichier de la machine ? Pourquoi stocker la description d'un fichier dans la base de données quand on peut utiliser le nom du fichier ? Le problème des espaces et des accents ? Connaissez-vous l'encodage en url ou l'encodage en base 64 etc..? (perso j'ai un faible pour l'encodage en url)

N'est-il pas plus rapide de faire:

<?php

$article = 123456;

$file_list = scandir("/imgs/article/$article_id");

 ?>

<?php foreach($file_list as $image): ?>

<img src="/imgs/article/<?=$article_id?>/<?=$image?>" alt="<?=urldecode(substr($image,0,strrpos($image,'.')))?>"/>

<?php endforeach;?>


plutôt que :

<?php

$article = 123456; 

$connection = new connection_to_db();

$sql = "SELECT file_name, file_description from file where article_id = $article";

$result = $connection->query($sql);

?>

<?php while($image = $result->fetch()): ?>

<img src="/imgs/article/<?=$article_id?>/<?=$image['file_name']?>" alt="$image['file_description']?>"/>

<?php endwhile; ?>


Je conclurai avec le titre de cet article: A-t'on encore besoin des SGBD dans les systèmes orientés web ?

 

sample of the opencv 2's python interface || example d'utilisation de l'interface python d'opencv 2

English:

I recently was playing with opencv and had a hard time compiling the c code samples (apparently my C/C++ knowledge is outdated) so i decided to take a look at the python samples (that i am way more familiar with). But i quickly realized that the code sample and the new interface don't match (T_T). So after hours of ready this page  and getting crazy on non-exsitent types (ndlr cvSize, cvPoint), i realize that i wasn't reading the most import part of the previous link that say that simple type such as cvSize etc.. are so simple that we can use tuple !!!

Knowing that, i was then able to rewrite the facedect.py (code at the end of the article).

Conclusion: Everything is always in the documentation, we just need to read it !

P.S. : Does anyone know if there is a code plugin for blogspot ?

Francais:

Recement je fasais mumuse avec opencv et rencontrais des difficultes a compiler le code c (visiblement mes connaissance en C/C++ sont depassees). J'ai ansi decide de me jeter sur le code python (que je connais la bien mieux). Cependant, je me suis vite rendu compte que les codes fournis et la nouvelle interface ne colle pas. Donc apres des heures a lire cette page et a m'arrache les cheveux sur des types non existant (cf. cvSize, cvPoint etc..), j'ai remarque que je louper le passage le plus important de l'article sus-cite: les type simple comme cvSize sont maintenant remplace par des tuples !

Etant maintenat au clair avec j'ai pu reecrire la source facedetect.py.

Moralite: Tout est dans la doc, faut juste la lire !

P.S. : vous savez pas s'il existe un plugin code pour blogspot ?

import sys
# i kept it this was to highlight the function from the module but in a real life application
# use form cv import *
import cv
# Global Variables
cascade = None;
storage = cv.CreateMemStorage(0);
cascade_name = "../../data/haarcascades/haarcascade_frontalface_alt.xml";
input_name = "../c/lena.jpg";

# Parameters for haar detection
# From the API:
# The default parameters (scale_factor=1.1, min_neighbors=3, flags=0) are tuned 
# for accurate yet slow object detection. For a faster operation on real video 
# images the settings are: 
# scale_factor=1.2, min_neighbors=2, flags=CV_HAAR_DO_CANNY_PRUNING,
# min_size=
min_size = (20, 20)
image_scale = 1.3
haar_scale = 1.2
min_neighbors = 2
haar_flags = 0

def detect_and_draw(img):
    gray = cv.CreateImage((img.width, img.height), 8, 1);
    small_img = cv.CreateImage((cv.Round (img.width / image_scale), cv.Round (img.height / image_scale)), 8, 1);
    cv.CvtColor(img, gray, cv.CV_BGR2GRAY);
    cv.Resize(gray, small_img, cv.CV_INTER_LINEAR);
    cv.EqualizeHist(small_img, small_img);
    if(cascade):
        faces = cv.HaarDetectObjects(small_img, cascade, storage, haar_scale, min_neighbors, 0);
        if faces:
            for (x, y, w, h), n in faces:
                print "coord (%d,%d) and height:%d width:%d" % (x * image_scale, y * image_scale, w * image_scale, h * image_scale);
        else:
            print "no face found";

if __name__ == '__main__':
    if len(sys.argv) > 1:
        if sys.argv[1].startswith("--cascade="):
            cascade_name = sys.argv[1][ len("--cascade="): ]
            if len(sys.argv) > 2:
                input_name = sys.argv[2]
        elif sys.argv[1] == "--help" or sys.argv[1] == "-h":
            print "Usage: facedetect --cascade='' [filename|camera_index]" ;
            sys.exit(-1)
        else:
            input_name = sys.argv[1]
    cascade = cv.Load(cascade_name);
    if not cascade:
        print "ERROR: Could not load classifier cascade"
        sys.exit(-1)
    image = cv.LoadImage(input_name);
    if(image):
        detect_and_draw(image);

What if straight line doesn't exist ? || Et si les droites n'existaient pas ?

(English version coming soon)

Récemment je me suis pris des vacances et en ai profité pour faire le tour du Japon. Là vous vous dites; Quel est le rapport entre ses vacances et un concept mathématique fondamental ?

Et bien c'est très simple, j'étais sur la somptueuse plage de Shirahama sur la péninsule de Izu et regardait l'horizon. Et quel fut ma stupeur, la ligne d'horizon si chère au marins n'était pas si droite. Je me suis rendu alors compte que si on s'amusait à tracer une droite, le périple ne nous emmènerait pas aux confins de l'univers mais à notre point de départ; Et oui la Terre est ronde !

Ce qui remet en cause le côté 'infini' de la droite (outch). Et surtout que l'on viens de dessiner un cercle sur le plan yz ,à supposer que l'on trace notre « droite » sur le plan xz (deuxième outch).

Ce qui remet en cause pas mal de chose comme, par exemple les tangentes définies comme des « droites qui touchent un cercle, une courbe, etc. en un seul point ». Ainsi la tangente serait un disque qui contiendrait ce point de contact (quid de savoir où dans le disque).

Nous pouvons alors conclure qu'une droite est en réalité d'une longueur égale au diamètre du cercle dont ses points font parti, et quand à notre exemple de la tangente, ce pose également un problème de profondeur (tengant en un point certe, mais lequel ?).