4 ms·

Non-scalar data violates 1NF [0]. You _can_ have composite types, arrays, JSON, etc. as others have said, but you are likely giving up relational integrity in d

Non-scalar data violates 1NF [0]. You _can_ have composite types, arrays, JSON, etc. as others have said, but you are likely giving up relational integrity in doing so, which is the raison d'être of RDBMS. The reason they're so strict is to protect you from yourself (and others). When you get a foreign key violation, that should be cause for alarm, not an annoyance to figure out how to overcome. > Solving every problem with tables might seem clever from a technical perspective, but its just not how humans think. Not without practice, no. You can in fact learn to do data modeling. [0]: https://en.wikipedia.org/wiki/First_normal_form https://en.wikipedia.org/wiki/First_normal_form

sa46 2y ago
Composite types can be atomic--a string is a composite type. The point (123, 456) is a composite type but is atomic. Good discussion at https://dba.stackexchange.com/questions/2342/what-is-atomic-relation-in-first-normal-form https://dba.stackexchange.com/questions/2342/what-is-atomic-...
- sgarland 2y ago
  Good point. I’ll also add to my previous comment, that it’s fine to violate normal form if you are aware that you’re doing so, and have a good reason. There are some instances where an array happens to make excellent sense from a performance standpoint, for example, and storing it in RDBMS doesn’t magically make everything explode. I do disagree with people’s tendency to shift towards treating RDBMS as a way to store schema in JSON, though. Not only is it massively unperformant, and indexing it is a pain, but you can quite easily get yourself into situations where there are multiple versions of your schema-within-a-schema, and that can be a nightmare.
  - josephg 2y ago
    I don't think I was clear above. I want embedded objects. I wish there was a more "database-native" way to do it than using JSON, and all the ugliness that JSON brings. (Like dynamic typing, schema-within-a-schema, more complex indexing & querying, etc.) Sounds like something the databases should be able to provide natively, without needing to use JSON at all. (And apparently support for this sort of stuff is slowly improving! Thanks to all the sibling comments for details!)

sa46 2y ago

Composite types can be atomic--a string is a composite type. The point (123, 456) is a composite type but is atomic. Good discussion at https://dba.stackexchange.com/questions/2342/what-is-atomic-relation-in-first-normal-form https://dba.stackexchange.com/questions/2342/what-is-atomic-...

sgarland 2y ago
Good point. I’ll also add to my previous comment, that it’s fine to violate normal form if you are aware that you’re doing so, and have a good reason. There are some instances where an array happens to make excellent sense from a performance standpoint, for example, and storing it in RDBMS doesn’t magically make everything explode. I do disagree with people’s tendency to shift towards treating RDBMS as a way to store schema in JSON, though. Not only is it massively unperformant, and indexing it is a pain, but you can quite easily get yourself into situations where there are multiple versions of your schema-within-a-schema, and that can be a nightmare.
- josephg 2y ago
  I don't think I was clear above. I want embedded objects. I wish there was a more "database-native" way to do it than using JSON, and all the ugliness that JSON brings. (Like dynamic typing, schema-within-a-schema, more complex indexing & querying, etc.) Sounds like something the databases should be able to provide natively, without needing to use JSON at all. (And apparently support for this sort of stuff is slowly improving! Thanks to all the sibling comments for details!)