As a newbie, I am proud I understand the question after reading mongoosejs.com/docs/discriminators.... I mean SQL is super flexible, you just make it say whatever you need it to say. E.g. I can imagine a table called question and survey, you can guess how those 2 are related. Then you could have an every slightly so generic table called answer (in general you don't want to be generic in SQL so don't go overboard here, just be pragmatic). On answer you could have multiple fields for different types of answers, such as text_essay which could be a text type and yes_no which could be a boolean type, and choice which could be a simple integer which references options through a multiple_choice table. You can make everything link up super flexibly by giving everything an id and using simple foreign key references and then just test out and write your SQL in your favorite client, it's fun! Then use a simple driver to convert the sql types to code types and then perhaps do some simple algebraic choices in your client. There is one language to return the information and you can query it and change it indefinitely. I am new to all of this so might be over simplifying but I am pretty confident after years of trying to be more than a newbie, that you just shouldn't use an ORM and just work and work the SQL and you will be fine. SQL is built to be generic itself, so you can just declare exactly what you want. Don't try to build super abstract things on top of it, just build the things you need.
Thanks for the suggestion. I hadn't considered just having nullable field on the answer table representing the question variants. It does make sense. I'll also check if there are constraints that prevent more than one of those columns being non-null.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
As a newbie, I am proud I understand the question after reading mongoosejs.com/docs/discriminators.... I mean SQL is super flexible, you just make it say whatever you need it to say. E.g. I can imagine a table called
questionandsurvey, you can guess how those 2 are related. Then you could have an every slightly so generic table calledanswer(in general you don't want to be generic in SQL so don't go overboard here, just be pragmatic). Onansweryou could have multiple fields for different types of answers, such astext_essaywhich could be a text type andyes_nowhich could be abooleantype, andchoicewhich could be a simple integer which references options through amultiple_choicetable. You can make everything link up super flexibly by giving everything anidand using simple foreign key references and then just test out and write your SQL in your favorite client, it's fun! Then use a simple driver to convert the sql types to code types and then perhaps do some simple algebraic choices in your client. There is one language to return the information and you can query it and change it indefinitely. I am new to all of this so might be over simplifying but I am pretty confident after years of trying to be more than a newbie, that you just shouldn't use an ORM and just work and work the SQL and you will be fine. SQL is built to be generic itself, so you can just declare exactly what you want. Don't try to build super abstract things on top of it, just build the things you need.Thanks for the suggestion. I hadn't considered just having nullable field on the answer table representing the question variants. It does make sense. I'll also check if there are constraints that prevent more than one of those columns being non-null.