doug
doug3mo ago

Schema analysis paralysis

I’m working on setting up a project focused around the real estate niche and I find myself getting into analysis paralysis over my schema. At the moment, it’s really the only thing that’s holding me back. Does anyone have any resources they recommend looking into to help with this problem?
15 Replies
Matt Luo
Matt Luo3mo ago
You could turn off schema validation while you iterate
erquhart
erquhart3mo ago
You can also make things optional while you're early on, so you can still keep some schema awareness and not have to turn it off completely - your schema doesn't have to be a commitment until you want it to be.
Gustavo
Gustavo3mo ago
Also, ask o1 and Sonnet 3.5 for advise
Omar
Omar3mo ago
jot down enough schema to get you to the next milestone
jamwt
jamwt3mo ago
@doug I often, weirdly enough, find the first few tables ther hardest to write then things get easier to avoid paralysis, I often start without a schema and just throw some documents in there liberally use convex's "delete table data" feature on the dashboard and iterate again once it feels like i'm really now starting to develop my app instead of just come up with the start of the data model, I use the dashboard's schema generation to give me my first schema. and I usually find it easier to extend it from there so that's my personal advice in the start of projects. if you're not quite sure what you're making yet, maybe just YOLO some records in there instead of making a type specification first
Omar
Omar3mo ago
ah yeah, that "YOLO some records" is also what i mean by "jot down enough schema" in my workflow is there a global way of doing this besides wrapping everything in v.optional()
Matt Luo
Matt Luo3mo ago
I don't think so. I was talking about the defineSchema() funciton as opposed to individual table columns
erquhart
erquhart3mo ago
Disabling schema validation as Matt mentioned is effectively the global alternative to wrapping everything in v.optional(). https://docs.convex.dev/database/schemas#schemavalidation-boolean
Omar
Omar3mo ago
Ah there it is, got it. Thanks
sshader
sshader3mo ago
I'm also a fan of some strategic v.any()s -- like myTable: { fieldImSureAbout: v.string(), metadata: v.any() } or even tableIDontHaveASolidSchemaForYet: v.any()
Matt Luo
Matt Luo3mo ago
Oh yeah, I recall you mentioning that earlier. I suppose the benefit of that is that you get Intellisense and autocomplete that that table exists.
ampp
ampp3mo ago
I think since switching to cursor i'm even less worried about schema changes as its even faster to refactor in pre production. - Having a validator variables and use them in the schema - Unique names for global find and replace. - Using ents with edges forces you to consider a structured design create relationships. - Anytime if you think a table is too big it probably is. - Assume you will get it wrong and refactor everything a few times anyway.
Matt Luo
Matt Luo3mo ago
Globally unique column names is actually really useful
doug
dougOP3mo ago
I just wanted to thank everyone for their thoughts on this. I decided to stop thinking about it and just build out my front end so that I could focus on the UX of the people who will eventually be filling out my forms. Many of you were correct taking this approach. I’m getting a clear picture of what the final schema should look like.
erquhart
erquhart3mo ago
A major benefit of Convex is precisely not having to think about this stuff early on. Hard to not do though, muscle memory.

Did you find this page helpful?