As noted in a least one other answer here, all ORMs are not the same. Some ORMs make very significant assumptions about how the database should be structured. The tooling should provide some support for going outside of this model but the more you go outside of that model, the less value the ORM has. If you are working with a more domineering ORM tool, you will have a much better experience if you design the database around its implicit assumptions.

I've never really understood why ORMs are seen by many developers and architects as essential. This may be due to the fact that I almost have had a green-field database to work with and the time an effort required to get the ORM mapping done was far more work than writing the SQL. Either the mapping was simple (and so was the SQL) or it was complicated and I needed SQL (or something similar) anyway. The transactional 'support' included in ORM has been more a source of bugs and problems than a help, in my experience.

Your mileage may vary but I've come to believe that it's better to think about database persistence as just a special case of data serialization. And just as I think it makes no sense to believe you can 'send' an object over the wire, I don't think it really makes sense to think of writing objects to a database. I even think it's completely valid to have multiple object representations of the same data for different needs. Mapping objects to tables and vice-versa has become an end to itself as opposed to a solution to a problem. I'm not convinced most people that use these tools even have a clear reason for wanting to do it. It's become a default.

As noted in a least one other answer here, all ORMs are not the same. Some ORMs make very significant assumptions about how the database should be structured. The tooling should provide some support for going outside of this model but the more you go outside of that model, the less value the ORM has. If you are working with a more domineering ORM tool, you will have a much better experience if you design the database around its implicit assumptions.

I've never really understood why ORMs are seen by many developers and architects as essential. This may be due to the fact that I have almost never had a green-field database to work with and the time and effort required to get the ORM mapping done was far more work than writing the SQL. Either the mapping was simple (and so was the SQL) or it was complicated and I needed SQL (or something similar) anyway. The transactional 'support' included in ORM has been more a source of bugs and problems than a help, in my experience.

Your mileage may vary but I've come to believe that it's better to think about database persistence as just a special case of data serialization. And just as I think it makes no sense to believe you can 'send' an object over the wire, I don't think it really makes sense to think of writing objects to a database. I even think it's completely valid to have multiple object representations of the same data for different needs. Mapping objects to tables and vice-versa has become an end to itself as opposed to a solution to a problem. I'm not convinced most people that use these tools even have a clear reason for wanting to do it. It's become a default.

As noted in a least one other answer here, all ORMs are not the same. Some ORMs make very significant assumptions about how the database should be structured. The tooling should provide some support for going outside of this model but the more you go outside of that model, the less value the ORM has. If you are working with a more domineering ORM tool, you will have a much better experience if you design the database around it's implicit assumptions.

I've never really understood why ORMs are seen by many developers and architects as essential. This may be due to the fact that I almost have had a green-field database to work with and the time an effort required to get the ORM mapping done was far more work than writing the SQL. Either the mapping was simple (and so was the SQL) or it was complicated and I needed SQL (or something similar) anyway. The transactional 'support' included in ORM has been more a source of bugs and problems than a help, in my experience.

Your mileage may vary but I've come to believe that it's better to think about database persistence as just a special case of data serialization. And just as I think it makes no sense to believe you can 'send' an object over the wire, I don't think it really makes sense to think of writing objects to a database. I even think it's completely valid to have multiple object representations of the same data for different needs. Mapping objects to tables and vice-versa has become a end to itself as opposed to a solution to a problem. I'm not convinced most people that use these tools even have a clear reason for wanting to do it. It's become a default.

As noted in a least one other answer here, all ORMs are not the same. Some ORMs make very significant assumptions about how the database should be structured. The tooling should provide some support for going outside of this model but the more you go outside of that model, the less value the ORM has. If you are working with a more domineering ORM tool, you will have a much better experience if you design the database around its implicit assumptions.

I've never really understood why ORMs are seen by many developers and architects as essential. This may be due to the fact that I almost have had a green-field database to work with and the time an effort required to get the ORM mapping done was far more work than writing the SQL. Either the mapping was simple (and so was the SQL) or it was complicated and I needed SQL (or something similar) anyway. The transactional 'support' included in ORM has been more a source of bugs and problems than a help, in my experience.

Your mileage may vary but I've come to believe that it's better to think about database persistence as just a special case of data serialization. And just as I think it makes no sense to believe you can 'send' an object over the wire, I don't think it really makes sense to think of writing objects to a database. I even think it's completely valid to have multiple object representations of the same data for different needs. Mapping objects to tables and vice-versa has become an end to itself as opposed to a solution to a problem. I'm not convinced most people that use these tools even have a clear reason for wanting to do it. It's become a default.