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 palm123 (site web personnel) . Évalué à 2.
http://sametmax.com/introduction-a-wamp-en-python/
ウィズコロナ
# SQL ne permet pas de recherche par image
Posté par denxp . É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.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: SQL ne permet pas de recherche par image
Posté par bobmoutarde . É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 Anonyme . Évalué à 5. Dernière modification le 30 juillet 2014 à 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
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: SQL ne permet pas de recherche par image
Posté par Zylabon . Évalué à 3. Dernière modification le 30 juillet 2014 à 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 qrencodepour 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 bobmoutarde . É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 keyser.dyson . Évalué à 2.
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 Marotte ⛧ . Évalué à 2. Dernière modification le 31 juillet 2014 à 22:02.
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 keyser.dyson . Évalué à 1.
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 Marotte ⛧ . Évalué à 2.
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é :
La doc ne précise pas quels sont les cas en question…
[^] # Re: SQL ne permet pas de recherche par image
Posté par NeoX . Évalué à 2.
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…
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: SQL ne permet pas de recherche par image
Posté par keyser.dyson . Évalué à 1.
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 keyser.dyson . Évalué à 1.
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.
Il y des commandes genre "describe" qui donnent des informations à ce sujet.
# TEXT, similaire au BLOB ?
Posté par bobmoutarde . É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 NeoX . É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 bobmoutarde . Évalué à 1.
Qu'appelles-tu tables intermédiaire ?
Normalement je devrais taper en direct dedans, sauf si j'ai pas tout saisi…
[^] # Re: TEXT, similaire au BLOB ?
Posté par keyser.dyson . Évalué à 1.
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 bobmoutarde . É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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.