Hello, Bubblers and experts of the Bubble community
I have a question about efficiency in Bubble.
Let’s imagine this case : a man has 1000 houses. I want to inject all thoses address in my DB.
I have 2 options :
Create a data-type "addresse and inject all the 1000 address in this field
create a table “address” and create 1000 lines (1 for each address) + one field “owner” in which i’ll write the name of the owner (1 time on each 1.000 lines).
In your opinion, what would be the best option in terms of speed and efficiency?
One data type “Properties” where you have all informations about this property (with address) and with a field that can be of type “user” that will be related to the owner.
You don’t need to write the name of the owner, just link it to the owner (you can select data type as type for a field).
Thank you for you message.
As I’m a french speaking guy (and also a beginner with Bubble), I realise that my message was not clear. So here is an image to illustrate my question.
Ma reponse décrit ton exemple 2. Tu dois créer une table propriétés qui contiendra les informations des propriétés ainsi qu’un champ du type ou l’information sur le propriétaire sont consignées. Pas du type texte mais bien du type de la table.
Merci pour l’explication. Il va falloir trouvé comment enregistrer les adresses en lignes séparées depuis un formulaire. J’étais plutôt parti sur l’option numéro 1 car enregistrer les items au départ d’un formulaire (les adresses sont écrites dans “n” champs sur un formulaires) en item séparés semble être assez galère dans Bubble…
Je sèche sur ce truc… Ca m’ennuie de lire que la solution que j’avais trouvé n’est pas la bonne…
Tu peux toujours créé une ligne de type liste (text ou geographic address) mais je pense que ce ne serait pas l’idéal. Si tu donnes plus d’informations sur le formulaire, il y a sûrement un moyen de gérer cela de manière plus simple
Je pense que ton idée d’avoir une table avec les adresse en ligne et la relation avec le propriétaire est la plus efficiente.
Ce qu’il faudrait, c’est que je puisse faire en sorte que si une personne à 50 maisons, qu’au moment de soumettre le formulaire, cela crée 50 lignes dans la db “proriétés”. Et c’est ça que je n’arrive pas à faire malgré mes tests et mes recherches. Pourtant cela doit être possible. Comment ferait-on sinon pour une boutique en ligne ou chaque article serait une transaction ?
En partant de ta liste de propriétés, tu fais un API workflow on a list et en backend tu crées l’API workflow qui crée simplement une propriété. Ca marche jusqu’à 100’000 lignes sauf erreur.
2)Et comment fait-on pour que, en backend, l’api sache qu’elle doit tourner 10 fois (s’il y a 10 maisons) ou 50 fois (s’il y a 50 maisons) ? Il faut compter les éléments de la liste et faire une boucle ?
La question me semblait plus en lien avec un formulaire que tu as déjà dans Bubble ou l’utilisateur entre ses propriétés ? Dans ce cas je ne vois pas l’utilité des backend wf. Tout est dans le wf du formulaire
Hello @Jici , oui effectivement, c’est un formulaire Bubble. Et au moment de cliquer sur enregistrer, je stocke toutes les adresses dans le champs “propriétés” de la table “Owner”.
Je pourrais peut être faire un enregistrement à chaque modifications du champs adresse (via un “When address value is change”) mais cela ne risque-t-il pas de consommer pas mal de WU ?
La proposition de @yannandco revient aussi assez souvent dans les post qui traitent de cette problématique. Mais je ne sais pas comment on constitue la liste des adresses (qu’il faut ensuite envoyer vers l’api workflow on a list (dans le champs “list to run”)… C’est bête, je sais mais je n’arrive pas à avoir une réponse et je galère depuis des jours à essayer l’une ou l’autre manip…
En fait, le problème vient d’abord de la configuration du formulaire. Peux-tu envoyer soit un lien avec ton formulaire soit une capture d’écran que l’on voit comment tu as construit le tout?
La méthode simple: les champs propriété (disons adresse pour l’instant) et un bouton +/ajouter (peu importe) une fois que le champ est rempli. Le workflow: Create a new thing dans la base Propriétés en liant l’item à l’utilisateur actuel (current user, dans l’optique où ce dernier est authentifié) et Reset input fields. Ensuite, un Repeating group qui affiche la liste des propriétés. Rien de plus, pas besoin d’envoyer en backend WF. La solution des backend WF fonctionne dans le cas où on ne sauve pas dans la BD directement, mais plutôt dans des states par exemple. Mais c’est plus complexe et souvent pas nécessaire. Finalement, reste la solution API pour des listes qui est plus performantes et économique, mais encore là, je ne vois pas l’intérêt ici.
Désolé de la réponse tardive, je me réveille seulement
Voici le formulaire en question. J’avais parlé des maisons pour simplifier la problématique dans le forum. En fait c’est un peu plus complexe mais le principe reste le même :
j’ai une console dans laquelle je crée des événements (events)
chaque événement peut être lié à :
* un ou plusieurs type(s) de prestation
* et à un ou plusieurs site(s)
Donc à ce stade, les sites et les utilisateurs ont déjà été “rentrés” en db.
Pour gérer cela, j’ai donc créé un formulaire dans lequel, via un multidropdown je peux sélectionner un ou plusieurs sites et un ou plusieurs type de prestation et venir les “attacher” à l’événement
Au final, tout est sauvé en db et dans le champs eventType_useOnThisSIte, j’écris l’uniqueID de tous les sites sur lesquels l’événement va être présent
Sauf qu’il peut y avoir vraiment beaucoup de sites. Et donc j’ai des craintes en terme de performance si Bubble doit aller lire dans un champs ou il va y avoir peut être 500 uniqueID (en sera-t-il capable ?).
Donc on pourrait faire une sorte de table de contextualisation et pour cela, au lieu de stocker tous les sites dans un champs, je voudrais pouvoir, dans un table à part (qui s’appellerait “contexte”, créer un ligne par site.
Et c’est là que je bloque… Donc comment faire en sorte que les sites renseignés dans le champs “specific on this sites” de mon formulaire se retrouvent stockés individuellement sous forme de lignes dans un db et non plus tous stockés dans un seul champs d’un seule ligne…
Je comprends. Tu dois donc restructuré ta BD. Et en effet, ce sera fait en utilisant les backend WF.
Est-ce que Bubble sera capable de lire les 500 unique ID (est-ce qu’ils sont stockés en liste de texte et non en liste de BD?) la réponse est oui. Est-ce performant. En général non. En plus d’être plus coûteux en WU. En plus d’être limités dans la quantité d’items dans la liste.
Pour restructuré le tout, il me manque des informations. Mais en gros, si on revient au concept propriétés, propriétaire, et que la liste de propriétés est des unique ID en liste de texte dans propriétaire, tu aurais un backend WF avec un champ “propriétare (type propriétaire)”. Dans ce workflow une seule action “Make change to a list” avec La liste qui serait Do a search for propriétés (where unique ID is in propriétaire’s propriétés).
Le schedule on a list (mais dans ton cas, ce serait plutôt un Bulk Workflow à partir de l’onglet BD) serait de type propriétaire et la liste to run on serait Do a search for propriétaire. Le champ propriétaire serait: This propriétaire
Admettons qu’au lieu d’un unique ID, tu as une adresse et aucune BD propriétés. Alors dans ce cas, tu auras besoin de deux wf (après avoir créé la BD propriétés):
A) un avec un champ texte (ou geographic address selon le type de ta liste d’adresse). 1 action: Create a new thing: Propriétés, le champ adresse utilisera “Adresse” du workflow
B) un deuxième qui appelera le premier. Celui-ci aura le champ propriétaire (type propriétaire). Une action: Schedule API Workflow on a list (workflow A)) la liste sera de type texte ou geographic address et tu utiliseras pour la liste “Propriétaire’s propriétés”. Dans le champ propriété, ce sera This text (ou this geographic address)
Merci pour ton retour. et pour ces pistes. C’est super sympa de prendre un peu de ton temps pour moi… Je ne suis vraiment pas encore en mesure de pouvoir rendre la pareille car ma maitrise de Bubble est très limitée mais merci mille fois pour ça…
Si je comprends bien ton message, j’ai l’impression que tu proposes une solution qui se base sur le schéma de DB existant et tenter d’aller replacer les données au “bon endroit”. Mais ce serait mettre une sorte de patch correctif sur un schema de db qui n’est pas bien designé.
Je serai plutôt partant pour changer mon schéma de db. Je ne stockerai plus les uniquesID dans un seul champs mais plutôt dans une nouvelle table avec n lignes et 2 colonnes (adresse propriété et propriétaire).
Ils sont stockés sous la forme des uniqueID
Et pour revenir au formulaire initial (celui au départ duquel les sites sont encodés par l’utilisateur), je ne vais donc plus stocker ces données dans un seul champs mais dans une nouvelle table.
Et si j’ai bien compris ce que tu expliques, il faudra que je le fasse avec une API Workflow on a list ? C’est bien cela ?
J’appelle l’api depuis un workflow, je passe les paramètres vers le backend et dans le backend, cette API Workflow on a list sera composé d’une api workflow qui va enregistrer tous les références des sites dans une table (avec autant de lignes qu’il y a de sites dans le champ du formulaire).