Forum Programmation.SQL Intégration du Qr Code

Posté par . Licence CC by-sa
0
30
juil.
2014

Bonjour,

Je me construis une petite base de données pour une appli (android) que l'on développe avec un ami.
Explication rapide de l'appli : On se sert d'un smartphone pour scanner le QrCode qui nous renverra une liste d'information sur le produit (nom, numéro de série, marque, prix etc…)

Par contre je ne vois absolument comment intégrer le QrCode dans la base de données, en gros on stocke l'image du QrCode dans la BDD et quand il y matching des "images" ça nous renvoi les infos que l'on veut selon les requêtes qu'on y affecte ?

Si quelqu'un peut m'éclairer sur ce point, je suis preneur…

Merci d'avance, je reste dispo pour toutes questions !

Cordialement,
Bobmoutarde

  • # pour donner des idées

    Posté par (page perso) . Évalué à 2.

    http://sametmax.com/introduction-a-wamp-en-python/

    If you choose open source because you don't have to pay, but depend on it anyway, you're part of the problem.evloper) February 17, 2014

  • # SQL ne permet pas de recherche par image

    Posté par . Évalué à 5.

    Un QrCode n'est que la représentation graphique d'une information :
    ton produit possède un ID dans la base, à partir de cet ID tu génères une image que tu distribues.
    Lorsque tu scannes ton code, l'information est décodée donc tu retrouves ton ID et tu peux faire ta requête.

    • [^] # Re: SQL ne permet pas de recherche par image

      Posté par (page perso) . Évalué à 2.

      C'est ça. Si tu veux stocker ton QrCode, il faut en réalité stocker les informations encodées dans le QrCode. En plus, se sera moins gros, et les recherches sur du texte fonctionne beaucoup mieux.

      • [^] # Re: SQL ne permet pas de recherche par image

        Posté par . Évalué à 1.

        En gros mon objet aura l'ID 10232645210, je vais sur un site de QRcode et je crée un QRcode qui me fournira cette série de chiffre lorsque je le scanne ?

        C'est le même concept que le code barre en faite, sauf que le QRcode offre plus de possibilités ?

        • [^] # Re: SQL ne permet pas de recherche par image

          Posté par . Évalué à 5. Dernière modification le 30/07/14 à 16:22.

          Le Qr code est simplement un code barre à deux dimensions
          Il permet de représenter plus de données qu'un code barre classique à une dimension

        • [^] # Re: SQL ne permet pas de recherche par image

          Posté par (page perso) . Évalué à 3.

          C'est ça. un QRCode, c'est un code barre alternatif, codé sur 2 dimensions au lieu d'une, ce qui permet de stocker plus d'informations.

        • [^] # Re: SQL ne permet pas de recherche par image

          Posté par . Évalué à 3. Dernière modification le 30/07/14 à 17:38.

          Utilise qrencode, il est dans toutes les distributions.

          Sinon oui, un code QR peut encoder des chaines soit numériques, soit alpha numériques, soit latin-1, man qrencode pour les possibilités.

          Ajout : je vois pas trop pourquoi passer par une base de données, un code QR peut encoder en gros 4ko d'informations (plus avec les qr code structuré), ça fait pas mal.

          Please do not feed the trolls

          • [^] # Re: SQL ne permet pas de recherche par image

            Posté par . Évalué à 2.

            Merci pour vos explications !

            En fait je vais utiliser le QrCode pour faire une petite appli GMAO, et vu qu'elle sera évolutive je préfère tout de suite mettre une BDD derrière que de stocker directement dans le QrCode, comme ça je pourrais ajouter une multitude d'info sans pour autant rechanger de QrCode à chaque fois (après je peux utiliser un code barre tout simple aussi).

            Imaginons que tu scannes un équipement, routeur par exemple, sur l'appli tu vas avoir les différentes informations : version, numéro de série, dernière maintenance etc… Mais je souhaite aussi y attacher les documents relatifs (manuel d'installation, mode opératoire etc…) qui seront eux un peu plus lourd que 4ko.

            • [^] # Re: SQL ne permet pas de recherche par image

              Posté par . Évalué à 2.

              Mais je souhaite aussi y attacher les documents relatifs (manuel d'installation, mode opératoire etc…) qui seront eux un peu plus lourd que 4ko.

              En général, c'est déconseillé les gros "blob" en base de données.

              Une solution est de créer un répertoire par produit et d'y ranger les fichiers.

              On peut aussi faire un répertoire pour tous les qrcode, un autre pour tous les manuels …

              • [^] # Re: SQL ne permet pas de recherche par image

                Posté par . Évalué à 2. Dernière modification le 31/07/14 à 22:02.

                En général, c'est déconseillé les gros "blob" en base de données.

                Pourquoi ?

                Je pense que bobmoutarde pensait à stocker les chemins des fichiers en question, pas de coller les fichiers eux-mêmes dans un champ BLOB…

                • [^] # Re: SQL ne permet pas de recherche par image

                  Posté par . Évalué à 1.

                  Pourquoi ?

                  Je crois que c'est à cause des index.

                  Un champs "blob" est de taille variable et il rend l'enregistrement variable. On ne peut plus calculer des positions pour les index. Ca nécessite un tableau intermédiaire.

                  Sinon, je ne mets pas les images dans des tables mais c'est juste pour pouvoir les voir directement.

                  • [^] # Re: SQL ne permet pas de recherche par image

                    Posté par . Évalué à 2.

                    Un champs "blob" est de taille variable et il rend l'enregistrement variable. On ne peut plus calculer des positions pour les index. Ca nécessite un tableau intermédiaire.

                    Un varchar a tout autant une taille variable qu'un blob…

                    Un SGBD performant ne devrait-il pas mesurer la taille maximum des enregistrements d'un champ donné afin de créer l'index de manière optimum ?

                    Si je prends MySQL, un BLOB a une taille maximum, tout comme un VARCHAR(longueur maximum)…

                    Enfin bon je pense que tu n'as pas tort en vérité, extrait de la page de manuel MySQL que j'ai cité :

                    Instances of BLOB or TEXT columns in the result of a query that is processed using a temporary table causes the server to use a table on disk rather than in memory because the MEMORY storage engine does not support those data types (see Section 8.8.5, “How MySQL Uses Internal Temporary Tables”). Use of disk incurs a performance penalty, so include BLOB or TEXT columns in the query result only if they are really needed. For example, avoid using SELECT *, which selects all columns.
                    […]

                    In some cases, it may be desirable to store binary data such as media files in BLOB or TEXT columns.

                    La doc ne précise pas quels sont les cas en question…

                    • [^] # Re: SQL ne permet pas de recherche par image

                      Posté par . Évalué à 2.

                      La doc ne précise pas quels sont les cas en question…

                      le texte que tu cites dit clairement qu'il faut eviter les colonnes BLOBs ou TEXT doivent etre eviter si l'on utilise une table teporaire,
                      car cette table temporaire se fera forcement sur le disque dur plutot qu'en memoire, le moteur "MEMORY" ne supportant pas ces types de colonnes.
                      du coup cela reduit les performances.

                      neanmoins dans certains cas, on peut quand meme vouloir stocker les infos dans les colonnes BLOB ou TEXT.

                      ca c'est le developpeur qui gere,
                      parfois ca peut etre plus performant de retrouver le fichier dans la base de donnée que sur le disque dur,

                      c'est plus facilement transportable
                      un simple dump de la base sauvegarde aussi les fichiers…

                      • [^] # Re: SQL ne permet pas de recherche par image

                        Posté par (page perso) . Évalué à 2.

                        Cela dépend complètement du SGBD. Mais maintenant, certains propose une gestion transparente quant à la gestion des fichiers : stocké en BD… mais en réalité sur le disque dur !

                        Par exemple, SQL Server (je sais, ça pu c'est pas libre, mais je l'utilise au boulot), permet cela, via les FileStream. Mais je ne serais pas étonné qu'une telle fonctionnalité existe dans d'autre SGBD.

                        Et le gros avantage malgré tout, c'est qu'une sauvegarde des données, c'est un simple dump de la BD, alors que si on fait une gestion en direct via un système de fichier, il faut aussi sauvegarder les fichiers…

                        • [^] # Re: SQL ne permet pas de recherche par image

                          Posté par . Évalué à 1.

                          Cela dépend complètement du SGBD. Mais maintenant, certains propose une gestion transparente quant à la gestion des fichiers : stocké en BD… mais en réalité sur le disque dur !

                          MySQL fait ça aussi. Ils appellent ça des "moteur de table" (ou stockage).

                          On peut même en écrire en PHP.

                          Il y a un moteur aussi pour les CSV.

                    • [^] # Re: SQL ne permet pas de recherche par image

                      Posté par . Évalué à 1.

                      Un SGBD performant ne devrait-il pas mesurer la taille maximum des enregistrements d'un champ donné afin de créer l'index de manière optimum ?

                      J'ai déjà essayé d'optimiser les index de MySQL. C'était pour faire un moteur de recherche "full text".

                      J'ai laissé tombé car il y a pleins de conditions qui rendent l'enregistrement variable.

                      J'avais d'autres raison aussi comme le fait que les "stop words" sont en dur.

                      Au final, j'ai fait ça avec "grep" dans un gros fichier texte placé dans "/dev/shm" (un "ram disk"). C'est plus performant. C'est dingue.

                      La doc ne précise pas quels sont les cas en question…

                      Il y des commandes genre "describe" qui donnent des informations à ce sujet.

  • # TEXT, similaire au BLOB ?

    Posté par . Évalué à 1.

    J'étais parti, effectivement, sur le fait de stocker une URL des différents documents qui seront stockés sur un FTP par exemple.

    Par contre dans votre discussion, il semblerait que le TEXT soit similaire au BLOB. Du coup j'ai une question :
    J'ai un champ commentaire sur les interventions qui seront réalisés sur les équipements, en gros pour chaque intervention il y aura potentiellement un commentaire (taille variable).
    Comment puis-je gérer ça ?

    La base de données n'a pas vocation à être énorme non plus, mais par la suite si ça fonctionne bien je ne dis pas qu'elle ne sera pas "plus" utilisée… Donc vaut peut être mieux l'optimiser maintenant non ?

    Merci encore.

    • [^] # Re: TEXT, similaire au BLOB ?

      Posté par . Évalué à 2.

      le texte cité dit juste que si tu utilises des tables intermediaires lors de tes parcours de bases de données, celles-ci seront ecrites sur le disque dur si y a des champs BLOB ou TEXT.

      si tu tapes directement dans les tables, rien ne t'inderdit d'avoir des champs BLOB/TEXT

    • [^] # Re: TEXT, similaire au BLOB ?

      Posté par . Évalué à 1.

      Comment puis-je gérer ça ?

      Personnellement , j'ai fini par mettre tous les champs texte en "TEXT". Je sais que ce n'est "pas bien" mais je pense qu'on peut gérer les performances après si ça devient critique.

      Il y a toujours la possibilité de mettre un cache en mémoire style memcache ou Redis par dessus si c'est trop lent.

      Ce n'est pas pratique pour gérer les contrôles ou l'intégrité référentielle en MySQL comme j'ai pu voir dans Access. Je le fait à l'"input" (en PHP par exemple).

      Si tu fais de l'embarqué, il y a sqlite qui est très connu. Elle est dans Android, je crois.

      • [^] # Re: TEXT, similaire au BLOB ?

        Posté par . Évalué à 1.

        J'ai déjà tout bien défini pour ce qui est de mes champs.

        Il y a juste la problème du QrCode qui est maintenant résolu, ça sera soit une URL soit un ID. Faut que je défnisse ce qui sera le plus simple.
        Sachant que je vais utiliser un module REST pour faire '"l'interface" entre ma BDD /Web/Appli.

        Pourquoi me parles-tu de SQL lite ? Je n'aurai rien sur le téléphone (est-ce la meilleure solution ?). Je pense qu'avoir des bouts de BDD à droite à gauche c'est pas vraiment pratique.

        HS : quelqu'un sait comment à partir d'un diagramme EER (sur mysql-workbench) créer une "bdd". J'avais réussi à faire l'inverse bdd => diagramme avec reserve engineer.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.