Is there a hard (or practical) max limit of fields we should add to a Table?

1

This will help me decide if I need a multi-table approach or not, thanks!

2

Hey @akarmach ! I’ve never run into or been communicated by our team a limit on the number of fields on a specific table.

That said, I’m not sure whether or not to use multiple tables or one table with many columns is a decision that’s best determined by whether or not tables present a field count limit. Instead, whether or not to break up a data model into multiple tables would best be determined through a normalization exercise.

Additionally, if you do have a table that is core to your project, on which you’d like to store some more arbitrary or even ephemeral data, you can always add a JSON field to the table in which you store key-value pairs. For example, if you want to store random key-value pairs on a User record, you could add a JSON type field called “meta” to it, in which any JSON document could be added and updated.

Hope this helps

3

Hi @sebastian.scholl thanks for your thoughtful response. In short :slight_smile: I agree with all of that and we are using JSON fields; they are particularly great for settings/options and external form submissions.

So in agreement with you about table decisions. In this scenario, we’re building a multi-faceted system to handle two different kinds of “Lead” data. I don’t have the complete data model from the client yet and I’m planning ahead if I might use two tables (if the data is vastly different and/or if each one needs a lot of fields {100+}) or one table if they share enough common fields, say 50%. Hope this makes more sense. Would like to hear any insights now you have the whole story, thanks! cc @tulsi

4

Nice!

Well, I’m a measure twice cut once kind of guy. So my best insight would be to wait to collect all the information from the client before developing the solution. That said, I understand that you may need to show progress along the way, which may be the pickle you’re finding yourself in…

That’s a lot of fields on a table! In this case, I’d just go with your two-table approach, as you can always do I migration once you have the full scope of information defined that merges the two tables if needed.