There’s ready no sure-fire way to say exactly when you have too many fields, as it depends on different factors: what do the fields contain, what are you using the data type for, etc.
200 fields is certainly a lot, but I can’t say if it’ll slow your app down or not. I’d recommend looking at the chapter on database structuring where we look at data concept requirements to try and determine if you’ve set it up in the right way. Relevant questions in your case would be:
Do I need to frequently/quickly search for this Thing?
Do I need all 200 fields on every instance I’m loading, or just in specific cases?
What’s the total data weight on the Type (are the fields containing structured or unstructured data)
It may make sense to set up a satellite Type for searching for example, if you’re planning to use that frequently. The good thing about a Search satellite type is that it’s pretty easy to set up at any point later. You may want to hold back that decision a little bit to see if the fields actually affect your performance or not - if searches do become slow and/or the download too big, you can set up the search satellite and create one for each record using a recursive workflow. If they work just fine, then there’s no reason to.
If you’d like to test it a bit before going live, you may also want to generate a bunch of records with random data (again using a recursive workflow to generate as many as you need) and do some testing on the performance side. If it’s starts slowing down quickly, you’re better off knowing before you have live users.
@emmanuel said in an panel talk on the Zeroqode no-code conference that they’d had users adding thousands of fields to a data type. Initially they were hesitant how to react, as it’s not really good database practice to do that, but from my understanding, they decided that “we need to facilitate for whatever our users are actually doing, not what the should optimally be doing” (I’m paraphrasing here) - I don’t know how that translated into actual optimization in Bubble to handle that many fields, but it’s an interesting statement nonetheless, and may be worth checking out with Bubble support. Let us know if you do!
Hi @petter thanks for the updated version. I enjoyed the first version and your updates were perfectly timed for my own app’s evolution.
I have a question about the dataType option set on page 137. As you include the dataTypes for GEO and POI in a single option set, would you say that you are inclined to support a single/unified option set that hosts all dataTypes across the app? Prior to your update I had started to make similar dataType option sets for each of my data types. To use your examples, I would have had an option set for POI data types and another for GEO data types, and so forth. My ‘siloed’ approach made sense to me as these options wouldn’t be used across multiple data types, and if they did I could add a new field.
For example, i’m making a financial app. I have “Assets” and “Vehicles” and “Markets”. Assets can be grouped at two levels: I have an option set for assetClass that every asset will have, and an option set called assetType that breaks down each assetClass even further (where relevant). Each assetType references its ‘parent’ assetClass as an attribute. Vehicles follow a similar structure. No asset ever needs to reference a vehicle-specific option set, nor vice-versa. However, a Market is a unique data point that references (is made up of) an Asset and a Vehicle (and some other data types), and therefore has reason to reference both of their relevant option sets (assetClass, [assetType], vehiclePrimary, [vehicleSecondary, {vehicleType, (vehicleStyle)}]) - I hope that those consecutive brackets help to detail the depth/detail/dependancies.
Do you think that I should place all of the data-types (options) in a single and much longer option-set? Will this help with searching? Or is my approach good given my use case? As they’re currently structured, I feel that these groups (option sets) will work well as user-operated filters for tables (repeating groups), filters that only appear when the ‘parent’ option is present. If you agree with my approach but also feel that it may hinder searches, is there a way to ‘solve’ that problem simply?
Thanks in advance, I hope that I didn’t ramble too badly.
Sounds like a great book, but I would really like a paperback version. I will buy ebook now, because I need it so badly, but will also buy paperback when available. Putting it from ebook onto Amazon Createspace as a paperback is quite simple. Dave Wommack. 619-255-3876. dwommack@gmail.com
@petter Hi Petter, I have a request about your website interface…
Right now, it’s not accessible for automatic translation tools.
I’m working in Japan and my colleagues cannot read English. Would be great to fix the website so that Google Translate can pick up the rest of the page.
This is what it looks like when running the translation:
Ok, I see. This is Gumroad’s built-in book-reader, so there’s not much I can do to change it unfortunately.
I may be able to run the original editable document through Google Translate and create a PDF for you, but I have to warn it will probably be a far from perfect translation. Let me know if you want me to check that possibility.
I’ve looked into getting it properly translated to Japanese, as it’s the most requested language outside of English, but I can’t say if or when that will happen at this time unfortunately.
Yes, that would be great, even though the automatic translation may not make sense from time to time, that would already be helpful for the colleagues (I hope).
And indeed, Bubble is taking off in Japan. And the lack of Japanese resource on it shows that there’s a real market opportunity here. Especially as most Japanese people do not speak English, so it’s usually a closed market when it comes to dealing with information and knowledge.
I’ll be waiting for the auto-translated PDF in the meantime, thanks a lot, on their behalf.
I’ve published a machine translated Japanese version of the book. I’ve also sent you a DM with the file so you can check it out. Obviously this is not going to be a translation of human quality, but I hope it can still be helpful. Feel free to let me know if you spot any ridiculous errors
I see this as an experiment as of now - if the feedback turns out to be negative, I’ll see it as a failed one
I’ll give the pdf to my colleagues. As I do not read Japanese myself, I won’t be able to evaluate whether the translation is understandable or not.
And I also have a Korean colleague (living 10+ years in Japan), he’s very good at Japanese but not sure he’ll be able to pinpoint mistakes.
Last but not least, Japanese people tend to not say anything when they don’t understand something (especially when it’s in a foreign language). So, I hope it’ll be understandable enough for them. So, their absence of feedback should not be taken as a “negative” feedback ^^.
Thanks again for your work! Very much appreciated.
Ah, Google states to have a 10 mb limit for translations, but it seems they have a much lower limit than that in reality, and with no warning whatsoever I only checked the first twenty pages.
While I’m thinking about it, if that was not too much work (well, everything is relative… ), do you think you could also do a Korean version the same way? For our Korean colleague. He’s more likely to give a feedback (but still no guarantee).
I would understand if that’s too much hassle for you though no worries!
I’m open to doing that, but would be interested to know whether the quality of the Japanese version is good enough or a complete mess. It’s hard for me to verify, so would love if you could get some general feedback from your colleagues. Not asking for proofreading or corrections, just a general impression, if they’d be willing.
The Ultimate Guide to Bubble Performance - how to build fast, scalable applications in Bubble (Japanese edition - 日本語版)
I only checked the first twenty pages.
), do you think you could also do a Korean version the same way? For our Korean colleague. He’s more likely to give a feedback (but still no guarantee).