|<- [[Understanding partitioning]]|[[MongoDB]] ->|

Qu'est-ce que le "CAP theorem" ?
  - proposé par Eric Brewer en 2000
  - originellement conceptualisé autour de données partagées en réseau.
  - souvent utilisé pour généraliser les //tradeoffs// entre différentes BDD.

Centré sur trois propriétés désirables :
  - //consistency// : tous les utilisateurs obtiennes les mêmes données, qu'importe d'où ils la lise
  - //availability// (disponibilité) : les utilisateurs peuvent écrire et lire à tout moment
  - //partition tolerance// : fonctionne lorsque divisée au sein d'un réseau.

Le théorème :
  * au mieux, vous ne pouvez garantir que deux de ces trois propriétés en simultané :
    * AP : disponible, //partition-tolerant//
    * CP : //consistent//, //partition-tolerant//
    * CA : //consistent//, disponible

note: ce n'est pas exclusif, il peut y avoir des variations sur les trois point (dans le sens ou on peut avoir un 'score' par ex de C**,A****,P** ou C*,A****,P***)

//CAP theorem and SQL VS NoSQL
  * les BDD relationnelles tendent à la /consistency// et la disponibilité mais avec généralement une mauvaise //partition-tolerance//
  * les BDD NoSQL  tendent vers la //partition-tolerance// (dans l'idée ou l'on va ajouter des nodes à la BDD au fur et à mesure de sa croissance.
  * Par exemple CouchDB est une BDD AP

Est-ce que le //CAP theorem// est important pour vous ?
  - selon la taille de votre application, les //CAP tardeoff// peuvent être //irrelevant//
  - ex: petit site a faible trafic, pas forcément besoin de partition
  - les //tradeoffs// de //consistency// peuvent ne pas être notables dans certains cas (ex: youtube n'affiche pas le même nombre de vues partout)