Discussion :

[Mirande]

Bonjour le forum

Je suis désespéré !!!

Je suis développeur sur un projet où nous rencontrons un problème que nous n'arrivons pas à identifier.
Le projet :
- une flotte de distributeurs automatiques de plats cuisinés
- des bornes de commandes (application développée en Delphi XE10, WIN7)
- une application centralisée de gestion des commandes clients (application développée en Delphi XE10, WIN7)
- une base de données centralisée MySQL installée sur une VM Linux. La base est liée à un prestashop.

Sur le principe, lorsqu'un client fait une commande depuis une borne, nous utilisons l'id (numérotation automatique) pour générer un code à barres d'identification et imprimer un ticket. Des commandes passées depuis les bornes et pour lesquelles nous avons pu imprimer un ticket ne sont pas visibles dans la base de données. Ni via le back-office prestashop, ni MySQL Workbench ou l'application centralisée de traitement. Certaines commandes finissent par apparaître plusieurs heures plus tard, d'autres non. Lorsque ce problème est apparu au mois d'août, les commandes sont apparues 24h après avoir été créées ...

Le système fonctionne plutôt bien depuis 18 mois mais depuis le mois d'août, nous avons eu 3 ou 4 fois ce problème et nous n'arrivons pas à le sourcer.

Nous avons vu avec l'hébergeur du système qui ne détecte pas de soucis de connexion ou de serveur (machine) à ce moment là.

Est-ce que ce comportement parle à quelqu'un ?

D'avance merci de vos retours.

FM

[SQLpro]

Vous cumulez toutes les emmerdes :
1) MySQL n'est pas vocation à servir de SGBDR pour les entreprises. C'est bon pour gérer sa cave à vin; Cela ne tient pas le route dès que l'on a de la charge en accès...
A lire : https://blog.developpez.com/sqlpro/p...oudre_aux_yeux
2) Delphi est un outil de développement obsolète qui a eut son heure de gloire dans les années 90. Il n'est plus du tout à la page en ce qui concerne les techniques d'accès aux SGBDR Modernes.
https://www.g2crowd.com/categories/i...nvironment-ide
3) Prestashop est un outil gratuit extrêmement mal modélisé, destiné aux bricoleurs qui veulent leur petite appli pour vendre des saucisses au coin de la rue !
pour information, lire la page 31, figure 1.2, de notre livre "Modélisation des bases de données" (Soutou, Brouard, ed Eyrolles)
https://books.google.fr/books?id=AHP...tashop&f=false
Cela ne tient pas la route dès qu'on a de la volumétrie...

Bref, vous êtes suicidaire !

A +

[bstjean]

Vous cumulez toutes les emmerdes :
1) MySQL n'est pas vocation à servir de SGBDR pour les entreprises. C'est bon pour gérer sa cave à vin; Cela ne tient pas le route dès que l'on a de la charge en accès...

Probablement pour cela que MySQL est utilisé par Facebook, Spotify, Netflix, YouTube, Twitter, Uber, etc.

[Mirande]

Bonjour

SQLpro, pour être poli, je dirai qu'un réponse comme la votre, je m'en passe !

Si quelqu'un d'autre a une idée vraiment pertinente, je suis toujours preneur.

Bonne journée

FM

[SQLpro]

Probablement pour cela que MySQL est utilisé par Facebook, Spotify, Netflix, YouTube, Twitter, Uber, etc.

A quel niveau ???

Ces entreprises utilisent toutes une version customisée de MySQL totalement différentes de mariaDB ou MySQL, et hors de portée de l'utilisateur lambda et généralement pas pour gérer des transactions….
Exemples :
1) Uber
Uber, utilise "Schemaless", une couche de partage de bases de données basée sur MySQL :
https://eng.uber.com/schemaless-part-one/

2) Spotify :
"
What database system does Spotify use?
Answer (Andreas Blixt, former Technology Lead at Spotify - Feb 29, 2016)
Spotify predominantly uses Cassandra for their services. Some solutions use PostgreSQL if it fits the use case much better, but it is more work to set it up to work properly across data sites (continents), hence why Cassandra is preferred.
"
https://www.quora.com/What-database-...es-Spotify-use
https://labs.spotify.com/2013/02/25/...ng-technology/
Donc, pas de MySQL… fake news… !

3) YouTube
https://arxiv.org/abs/1609.08675
Base propriétaire noSQL….

Je vais pas plus loin…. des affirmations fausse !

A +

[Mirande]

Re-bonjour le forum

Je me permet de revenir sur le besoin qui est le mien. Même si le contexte technique déplaît, il est comme il est et il n'est pas question de le remettre en cause maintenant ni dans un avenir proche.

Même si être considéré comme un vendeur de saucisses au coin de la rue peut paraître péjoratif lorsque l'on n'a aucune connaissance du projet en question, ça me va très bien !

Je voudrais donc recentrer le débat qui n'était pas de discuter des SGBD des uns et des autres mais bien d'essayer de trouver une piste à défaut d'une explication à mon problème.

Merci d'avance de vos réponses constructives à mon questionnement

Bonne journée

FM

[skuatamad]

Le problème c'est qu'on a pas beaucoup d'informations.
Que disent les logs sur les bornes et sur le serveur mysql.
Est-ce que pour générer un ticket vous vous appuyez sur un ID généré par la base, ce qui est censé empêcher la génération d'un ticket si la base n'est pas joignable ?

Le seul point auquel je pourrais penser, notamment pour MySQL Workbench, c'est de vérifier le niveau d'isolation des connections en lecture.
Par défaut certains clients sont configurés en REPEATABLE READ, ce qui vous oblige à COMMIT dans la session qui sélectionne pour pouvoir lire les nouvelles modifications des autres sessions.

Ce niveau d'isolation est trop restrictif, et généralement READ COMMITED est préférable.

[bstjean]

Je vais pas plus loin…. des affirmations fausse !

A +

Mes infos sont directement tirés de la page "Customers" sur le site officiel de MySQL.

Mais j'imagine que vous n'avez pas eu le temps de vérifier...

https://www.mysql.com/customers/

[SQLpro]

Mes infos sont directement tirés de la page "Customers" sur le site officiel de MySQL.

Mais j'imagine que vous n'avez pas eu le temps de vérifier...

https://www.mysql.com/customers/

Ce n'est pas du tout à jour et c'est du marketing ! De plus on pourrait aussi dire que tous ces clients utilisent aussi du SQL Server !!!! Ce qui est vrai compte tenu de la diversité de leur système informatique. Mais avoir du papier cul dans les chiottes, ce n'est pas la même chose, que d'affirmer être éditeur de livres ! Il convient donc de savoir pour quel usage précis… Notez aussi que ces entreprises utilisent la version commerciale de MySQL et donc pas la version gratuite ni MariaDB !!!! et la différence n'est pas petite….



A +

[Artemus24]

Salut à tous.

Sur le principe, lorsqu'un client fait une commande depuis une borne, nous utilisons l'id (numérotation automatique) pour générer un code à barres d'identification et imprimer un ticket.

Dois-je comprendre que chaque borne produit son propre numéro d'identification ? Que se passe-t-il si deux bornes produisent le même numéro d'identification ?

Des commandes passées depuis les bornes et pour lesquelles nous avons pu imprimer un ticket ne sont pas visibles dans la base de données.

Quelles commandes ? Il faudrait identifier celles qui posent des problèmes par rapport à celle où tout se passe bien.
Entre autre identifier les bornes, les plages horaires, l'influence de la clientèle, voire aussi des problèmes techniques, par exemple le réseau.

A priori, si vos tickets ne sont pas visible dans la base de données, c'est qu'ils ne sont pas encore arrivés. Il y a quelques choses qui bloquent l'acheminement de ces informations.

Lorsque ce problème est apparu au mois d'août, les commandes sont apparues 24h après avoir été créées ...

Si la seule observation que vous faites est le décalage dans le temps, je pense que vous devez vérifier pourquoi la date est importante dans le déclenchement de la commande.
Que vaut la date lorsque la commande est apparue 24 heures après ?

Je pense à un problème de synchronisation entre la borne et votre application centrale. Cela se traduit pas un goulot d'étranglement.
Sont-ce toujours les mêmes bornes qui posent problèmes ? Le problème se pose-il à certaines heures de la journée ou pas ?

Le système fonctionne plutôt bien depuis 18 mois mais depuis le mois d'août, nous avons eu 3 ou 4 fois ce problème et nous n'arrivons pas à le sourcer.

Quand on fait des tests de fonctionnalités, il ne faut pas tester les cas généraux, mais ceux qui sont hors limites.

Nous avons vu avec l'hébergeur du système qui ne détecte pas de soucis de connexion ou de serveur (machine) à ce moment là.

Ce n'est pas un problème d'hébergement, mais un problème applicatif ou réseau.

@+

[Mirande]

Salut à tous.

Bonjour Artemus24, bonjour tout le monde

Dois-je comprendre que chaque borne produit son propre numéro d'identification ? Que se passe-t-il si deux bornes produisent le même numéro d'identification ?

Une borne de commande est associée à un automate de livraison. Le code à barres qui est imprimé est généré à partir de l'ID de la commande dans prestashop, du numéro de l'automate associé et les secondes de l'heure de création. Deux codes à barres ne peuvent pas être identiques et une commande est destinée à un automate de distribution précis.

Quelles commandes ? Il faudrait identifier celles qui posent des problèmes par rapport à celle où tout se passe bien.
Entre autre identifier les bornes, les plages horaires, l'influence de la clientèle, voire aussi des problèmes techniques, par exemple le réseau.

On n'identifie pas de commande particulière qui pose problème. Nous avons également eu le problème avec une commande passée par internet sur le site marchand Prestashop. Le problème ne s'est jamais posé aux heures de pointe de fréquentation du système. On essaie de cherche un peu dans tous les sens. On se demande si le système ne dérive pas petit à petit ...

Si la seule observation que vous faites est le décalage dans le temps, je pense que vous devez vérifier pourquoi la date est importante dans le déclenchement de la commande.
Que vaut la date lorsque la commande est apparue 24 heures après ?

Certaines commandes ne sont jamais apparues alors que nous avons pu générer un ticket à partir de l'ID.

Je pense à un problème de synchronisation entre la borne et votre application centrale.

Les applications ne sont pas synchronisées, les échanges se font par la base de données.
Le cycle de commande est le suivant :
1) Une commande est enregistrée dans la base de données suite à son règlement. Commande passé depuis une borne ou le site web ==> Code à barre donc commande enregistrée
2) Le client scanne le code à barres généré au niveau de l'automate de distribution
3) Le programme de supervision vient scanner périodiquement les automates de distribution pour récupérer les commandes à traiter
4) Le programme de supervision va récupérer la commande associée au code à barres dans la base de données ==> Commande introuvable quand nous avons le soucis !
5) Le programme de supervision envoi la séquence de livraison à l'automate de distribution
6) Après livraison, le programme de supervision scanne la mémoire de l'automate pour traiter les erreurs éventuelles de livraison.

Sont-ce toujours les mêmes bornes qui posent problèmes ? Le problème se pose-il à certaines heures de la journée ou pas ?

Quand ça part en sucette, toutes les commandes sont concernées. Même les commandes web.

Le problème pourrait faire penser à des problèmes de contexte, comme c'est le cas sur les bases Interbase/FireBird.

Bonne journée

FM