3 ms·

> To me, it's about reducing the impedance mismatch between your data model and the implementation of that model in the database schema. The whole point of tha

> To me, it's about reducing the impedance mismatch between your data model and the implementation of that model in the database schema. The whole point of that "impedance" in the relational model is to for people to think about their data and describe it in a program-independent way: years of experience in the field is what led to its development and what contributes to its continued relevance. Saying that's a problem with the relational model is like saying that design patterns are flawed because they describe commonly used OO designs. > To me, it's about reducing the impedance mismatch between your data model and the implementation of that model in the database schema. I'm not sure what sort of impedance mismatch could exist between a program and a relational model but not between a program and a document model. The latter is trivially implementable in terms of the former.

_pius 17y ago
Take a look at my comment again, I think you think I'm saying something I didn't. The whole point of that "impedance" in the relational model is to for people to think about their data and describe it in a program-independent way .... The relational model is hardly the only way to reason about data in a program-independent way. ... years of experience in the field is what led to its development and what contributes to its continued relevance. I agree, never said otherwise. Saying that's a problem with the relational model is like saying that design patterns are flawed because they describe commonly used OO designs. I didn't say there's a problem with the relational model. I'm not sure what sort of impedance mismatch could exist between a program and a relational model ... I never said the word "program," you did. I said "data model." You're conflating the data model with the program code (or maybe you think I am, can't really tell). They are not the same thing. http://en.wikipedia.org/wiki/Abstract_data_type http://en.wikipedia.org/wiki/Abstract_data_type All I said is that there are some domains for which relational models make sense and there are others for which document-oriented (or other "NoSQL") models make sense.

_pius 17y ago

Take a look at my comment again, I think you think I'm saying something I didn't. The whole point of that "impedance" in the relational model is to for people to think about their data and describe it in a program-independent way .... The relational model is hardly the only way to reason about data in a program-independent way. ... years of experience in the field is what led to its development and what contributes to its continued relevance. I agree, never said otherwise. Saying that's a problem with the relational model is like saying that design patterns are flawed because they describe commonly used OO designs. I didn't say there's a problem with the relational model. I'm not sure what sort of impedance mismatch could exist between a program and a relational model ... I never said the word "program," you did. I said "data model." You're conflating the data model with the program code (or maybe you think I am, can't really tell). They are not the same thing. http://en.wikipedia.org/wiki/Abstract_data_type http://en.wikipedia.org/wiki/Abstract_data_type All I said is that there are some domains for which relational models make sense and there are others for which document-oriented (or other "NoSQL") models make sense.