mais j'avoue que j'aime débattre et me battre sur les forums 
> la différence entre vamechercher et donnemoi est vraiment légère...
bien au contraire, c'est la différence fondamentale, d'un coté tu te repose sur le langage sql pour que celui ci se démerde et te récupère ce que tu veut, de l'autre coté c'est toi qui à conçus entièrement la structuration de tes données, donc tu sait exactement ou se trouve tes données et fait juste le nécessaire pour les récupérer
> et tes données nosql, si tu ajoutes, supprimes ou modifie un champ, il se passe quoi à ton avis ? tu vas probablement être obligé de t'assurer que l'existant ne sera pas impacté...
si tu change l'identifiant unique de ton user oui, forcement tu va renommer toute tes clef l'utilisant, chercher dans chaque liste l'id et devoir patcher ...
mais dans la réalité tu ne fera jamais ca, il change son nom d'utilisateur, tu va faire hset clef_user nick nouveau_nick
l'existant lui si il est bien conçu devra aller chercher le nick de l'user pour l'afficher, donc une mise à jour immédiate
et en sql tu fera exactement la même chose
sauf qu'en sql, tu va faire une requêtes compliqué pour qu'il te récupère aussi à la volé le nom d'user, ici tu le fait toi même
à noter que dans le cas de redis, tu peu lancer directement dans redis des scripts en lua pour éviter de multiplier les requêtes, et sans faire de lua, tu va pipeliner tes requêtes pour avoir le max de résultats en un seul appel
> 300 champs dans la table ? déjà je suis pas sûr que ça soit nécessaire
j'ai mis 300, 3000 aurais été plus judicieux, le truc c'est que le nombre de colonne est illimité, un user peu avoir 10 colonnes un autre 100, le code lui va regarder ce qui est dispo et faire en fonction, c'est une différence énorme !
c'est pour souligner le fait qu'en sql c'est figé à la création, ici c'est tres tres souple
> ensuite l'idée d'avoir des tables en référence ça permet de mutualiser et d'optimiser la gestion de l'espace (parce que bon, si on continue dans ta pensée, ça veut dire qu'on va stocker 67 millions de fois "FRANCAIS" ? )
non, ici en l'occurrence dans le cas d'un système avec plusieurs millions d'inscription comme tu le suggère je ferais une liste avec le nom des caractéristiques, et une liste par caractéristique pour contenir les résultats, histoire d'éviter les redondances
ensuite en réalité les carac de chaque users serais dans un hash dédié "monsite:mesusers:4224:carac" le nom de chaque valeur serais l'id de la carac, la valeur en elle même, l'id de la réponse
(pour pousser encore utiliser un phonème comme id des carac serais pertinent ici)
> donc si le mec il a watmille octets dans ses 300 champs mais que tu veux que son nom et son prénom tu load watmille octets ?...
non, je loade seulement les champs qui m’intéresse
redis> HMGET myhash field1 field2 nofield
1) "Hello"
2) "World"
3) (nil)
hmget est O(N) ou N est le nombre de champs à récupérer
pour avoir ses carac complètes sur sa fiche :
// je prend toute les carac
$res = $redis->hgetall("monsite:mesusers:4224:carac");
redis->multi() // pipeline start
foreach($res as $caracid => $value)
{
$redis->hget('monsite:mescarac',$caracid); // nom de la carac
$redis->hget('monsite:mescarac:'.$caracid,$value); // valeur de l'user pour cette carac
}
$carac = $redis->exec(); // je récupère tout
print('vos caractéristiques ...<br>');
$nbcarac = count($res)*2;
for($n=0;$n<$nbres;$n+=2) print 'carac : '.$carac[$n].', valeur : '.$carac[$n+1].'<br>';
voila, deux appels à redis, ou un seul en passant par du lua mais c'est encore différent
montre moi l’équivalent sql pour voir ?
ici je montre que c'est simple, pas de prise de tête avec des heures à debuguer, et surtout, ce n'est pas nécessaire d’apprendre le langage sql
> les vues reprennent ta description des listes...
j'en sais rien, c'est possible, mais il existe plusieurs type de liste ici
* les listes, pop/push droite gauche, insert, récupération de range depuis n'importe ou etc ...
* les sets, contenant des valeurs uniques, tu met 20 fois "hello" il n'est présent qu'une fois, c'est super utile, aucune vérification préalable à faire, pas de doublons, possibilité de croiser des set entre eux etc ...
* les zset, des set ou chaque entrée possède un "score" associé, genre pour les phonèmes entre français et francais à chaque fois qu'un user s'ajoute j'incrémente le score de son orthographe, le score le plus haut est considéré comme étant la bonne => le con qui à mis "francais" aura marqué dans sa fiche "français"
ici aussi on peu croiser les zset entres eux
donc, tu as des choses (encore une fois) simple, puissante, et aussi rapides
> le coup du cron pour les password expirés là encore, y'a les procédures stockées et les triggers pour ça...
et galère 100 ans pour mettre en place tout ça
ici $redis->expire("maclef",100); et dans 100 seconde elle n'existera plus, bien sur on peu aussi spécifier un timestamp unix de fin
> (et puis pour le "prédéfinis avant de coder" > tu ne sais pas ce qu'est l'analyse ? l'écriture de specs ? l'architecture ?)
bien sur que si, ici aussi je le fait hein, mais la souplesse que ca procure permet de modifier ensuite de manière bien plus simple qu'avec sql
je n'ai pas non plus dis que c'est la manière ultime de stocker ses info (et surtout chercher dedans)
mais, ce n'est pas diabolique
> Au final, à tout stocker dans une base NoSQL sans trop y réfléchir, tu risques aussi de te retrouver à recréer un SGBDR-like qui ne sera pas nécessairement aussi puissant qu'une vraie solution.
chercher qq chose est très simple en sql, like %truc% c'est pawa à mort, et ici c'est impossible !
par exemple j'avais fait ca : http://procvor.free.fr/postal/
pas prise de tête en sql, une table avec toute les villes, et je laisse le soin à mysql de chercher dans les 36000 communes mon code postal ou ma ville ...
ici j'ai du faire la même chose, mais ce n’étais pas réglé en deux lignes de sql
j'ai implémenté cette méthode, http://antirez.com/post/autocomplete-with-redis.html
et au final c'est ultra rapide, mais ca ma demandé bien plus de temps de dev :- )
après rien n’empêche d'utiliser les deux type de base suivant les besoin ...
> Sinon, c'est que de base tu t'étais attaqué à un ensemble de problèmes très restreint…
je crée des sites pas le système de gestion de la secu, d'origine mes blèmes sont restreints, le max à faire actuellement c'est une gestion de clients/produits/variantes/stock/commandes/promotions
bref, refaire plus ou moins prestashop et pour tout ça c'est très adapté