IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

NoSQL Discussion :

[mongoDB & Doctrine] Unicité des entrées sur plusieurs champs


Sujet :

NoSQL

  1. #1
    Membre régulier
    Homme Profil pro
    Inscrit en
    Octobre 2012
    Messages
    172
    Détails du profil
    Informations personnelles :
    Sexe : Homme

    Informations forums :
    Inscription : Octobre 2012
    Messages : 172
    Points : 70
    Points
    70
    Par défaut [mongoDB & Doctrine] Unicité des entrées sur plusieurs champs
    Bonjour,

    Je cherche à faire une chose simple, du moins le pensais-je, à savoir : m'assurer de l'unicité d'une entrée/Document dans ma base MongoDB.
    Pourtant, et je parcours leS documentationS en long en large et en travers, je ne trouve pas comment réaliser cela.

    > A la base, je cherchais une simple @annotation qui me permettrait de m'assurer de l'unicité d'une entrée en base se basant sur plusieurs champs du Document.

    Malheureusement, j'en suis à une 30aine d'onglets ouverts (sans compter ceux déjà fermés) et ne sais même plus si je dois le faire via mongoDB ou via Doctrine ni même si je cherche une @annotation ou autre chose...

    Mon soucis ::
    J'ai un simple Document ::
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
     
    /**
    *  @MongoDB\Document(repositoryClass=".../EventRepository")
    **/
    class Event{
     
    /**
    * @MongoDB\Id
    */
    protected $id;
     
    /**
    * @var string
    * @MongoDB\Field(type="string")
    */
    protected $userId;
     
    /**
    * @var \DateTime
    * @MongoDB\Field(type="date")
    */
    protected $date;
     
    /**
    * @var string
    * @MongoDB\Field(type="string")
    */
    protected $moment;
     
    public _construct(string userId, \DateTime $date , string $moment){
          $this->date = $date;
          $this->moment = $moment;
          $this->userId = $userId;
    }
       [... getters/setters ...]
    }
    Cela sert à enregistrer des inscriptions à des événements donc, et l'unicité repose sur tous les champs puisqu'un utilisateur peut s'inscrire à 1 ou plusieurs événements le même jour.
    Je cherche simplement à éviter plusieurs inscriptions au même événement.

    J'aimerais éviter la requête en amont "findBy()" et si size == 0 alors insertion en bdd sinon c'est qu'on a déjà une entrée.

    Je suis sûr qu'il existe une façon plus "sexy" et surtout plus propre de réaliser cela,
    Des idées svp ?

    D'avance merci.

  2. #2
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 736
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 736
    Points : 52 448
    Points
    52 448
    Billets dans le blog
    5
    Par défaut
    ça n'est simplement pas possible. En effet, à la base des fameux SGBD noSQL il y a le concept de partitionnement, donc éclatement des données sur plusieurs nœuds. Or aucun éditeur de SGBD noSQL n'a réussit à faire en sorte que tous les nœuds d'un même cluster noSQL soient mis à jour de manière synchrone…. Il y a toujours un délai du au réseau, surtout si l'on emploi un transport de type non déterministe comme c'est le cas de la couche TCP/IP. Partant de là, aucun système NoSQL n'est capable de vous garantir une unicité quelconque à travers l'ensemble de vos données. Donc cette unicité n'a pas été implémentée du tout !

    En effet, le temps de lire toutes les valeurs de tous les nœuds, certains auront déjà changé de valeur. La seule solution dans ce cas consisterait à geler toute activité de mise à jour sur tous les nœuds pendant le traitement de calcul de l'unicité… Et par conséquent rendre le système hyper lent, alors qu'il a été conceptuellement vendu comme plus rapide que les SGBD Relationnels !!!

    SI vous voulez de l'unicité il faut vous tourner vers un SGBD Relationnel qui permet de poser des contraintes garantissant l'unicité d'une ou plusieurs colonnes….

    De plus dans votre cas, vous traitez de données complexes basées sur le temps, ce que les SGBD noSQL ne savent pas faire de manière native… Aujourd'hui un SGBDR comme SQL Server sait travailler les données temporelles y compris sur les deux axes que sont le temps opérationnel et le temps transactionnel (cela nécessite le support des "temporal table" de la norme SQL 2016) et consacre les bases de données bi-temporelles voire tri temporelles....
    A lire : http://www2.cs.arizona.edu/~rts/tdbbook.pdf

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  3. #3
    Membre du Club
    Homme Profil pro
    none
    Inscrit en
    Janvier 2020
    Messages
    36
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : none

    Informations forums :
    Inscription : Janvier 2020
    Messages : 36
    Points : 69
    Points
    69
    Par défaut
    Quelques mois après... mais bon, ce forum semble assez peu actif.

    Tant qu'on est sur la notion de contrainte logique, je vois pas vraiment de rapport entre la question et la notion d'eventual consistency.
    Quoi qu'il en soit, même en distribuant/shardant (pas français ça), MongoDB est CP (CAP theorem) par défaut. La consistance peut être assurée.

    Si on sur une contrainte au niveau de la collection: MongoDB supporte les index uniques, y compris composés, avec quelques restrictions quand il y a sharding.
    https://docs.mongodb.com/manual/core/index-unique/

    Pour les timeseries, il y a quelques offres NoSQL dédiées, ainsi que des offres SGBDR, qui se sont adaptés, comme SQLpro le signale.

    Have fun

Discussions similaires

  1. Réponses: 2
    Dernier message: 13/03/2012, 16h19
  2. contrôle des doublons sur plusieurs champs
    Par christy1 dans le forum Modélisation
    Réponses: 3
    Dernier message: 09/12/2011, 15h13
  3. [AC-2007] Identifier des doublons sur plusieurs champs.
    Par neiluj26 dans le forum Requêtes et SQL.
    Réponses: 15
    Dernier message: 22/09/2010, 21h49
  4. Gestion des homonymes sur plusieurs champs
    Par riete dans le forum Requêtes
    Réponses: 2
    Dernier message: 31/01/2008, 18h34
  5. [Swing] Imprimer des JeditorPane sur plusieurs pages ?
    Par bilou_lelapinou dans le forum AWT/Swing
    Réponses: 22
    Dernier message: 29/11/2006, 23h28

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo