6 ms·

The need to maintain an explicit schema and update it every time your data model changes is the point of friction here, not the migrations system. To be perfect

The need to maintain an explicit schema and update it every time your data model changes is the point of friction here, not the migrations system. To be perfectly clear, I'm not suggesting maintaining a schema is onerous enough to outweigh the numerous other benefits having an explicit schema provides, even at the prototype stage, but when you're prototyping and don't need to worry about data migrations, having to maintain a schema is certainly not going to be _faster_ than not having to maintain a schema, as the original post claimed.

twic 9y ago
If you're using an ORM, you can generate the schema automatically. With Hibernate, you set the hibernate.hbm2ddl.auto property [1]. If you set it to 'create' or 'update', it will alter the database schema so that it matches your objects, which is handy for prototyping, and terrible for production. If you set it to 'validate', it will check that the database schema matches your objects, and refuse to start if it doesn't, useless for prototyping but ideal for production. [1] https://stackoverflow.com/questions/438146/hibernate-hbm2ddl-auto-possible-values-and-what-they-do https://stackoverflow.com/questions/438146/hibernate-hbm2ddl...
- lewisl9029 9y ago
  That's a neat feature, but as you may already know, ORMs come with their own baggage in the form of object-relational impedance mismatch. There's an entire rather-substantial Wikipedia article on it, so I won't go into it any further myself: https://en.wikipedia.org/wiki/Object-relational_impedance_mismatch https://en.wikipedia.org/wiki/Object-relational_impedance_mi... The sibling thread also brings up similar issues with ORMs: https://news.ycombinator.com/item?id=15127058 https://news.ycombinator.com/item?id=15127058
  - twic 9y ago
    Eh. I've used ORMs and SQL extensively for many years. I think the concerns over mismatch are routinely overstated.
  - aryehof 9y ago
    ORMs are a solution to the problem of the impedance mismatch between an object model and its corresponding relational model. It's not that ORMs come with the problem. I think it increasingly rare today to see real object domain models anyway - the original raison d'etre of ORMs. Instead it's common to see domain concepts modeled in the data layer and modified by logic (often limited to CRUD) in an application/service/controller layer. The problem with this of course is that as complexity increases, that app/service/controller layer increasingly approaches a big ball of mud. Edit: grammar
jimktrains2 9y ago
It's such a small amount of friction compared to the advantages of a good RDBMS.
wvenable 9y ago
You always have to maintain an explicit schema -- it's just defined in your code instead of the database. And depending on your tooling, it's not easier/faster to maintain that schema in code vs. the database. What is worse for schemaless databases is schema versioning. Your code will forever have to support every schema that has ever existed in production data. I have code to support schemaless data that was entered well over a decade ago. If I had simply used a relational database I would just have a single schema to deal with. During development, schema changes are quite frictionless. It also provides extra safety and documentation that any friction is completely worth it.
- lewisl9029 9y ago
  > You always have to maintain an explicit schema -- it's just defined in your code instead of the database. This is normally known as an implicit schema. It's implicit precisely because you don't explicitly maintain a schema separately from your application code. > During development, schema changes are quite frictionless. It also provides extra safety and documentation that any friction is completely worth it. The second sentence contradicts the first. And I'm not disagreeing with the second. The friction may be worth it, but calling it _frictionless_ was my issue with this post and the original (which went even further by asserting the friction somehow accelerated development).
  - wvenable 9y ago
    > It's implicit precisely because you don't explicitly maintain a schema separately from your application code. But that's not completely true. There is plenty of code necessary for managing the schema and just the schema in a document database. Default values, relationships, validation, and managing previous version of the schema. I have plenty of code that just exists to handle documents in the "old" format. > The second sentence contradicts the first. Maybe I should have said almost frictionless instead of quite. And honestly, some things are less work with a schema (like creating a new defaulted boolean column) in an RDBMS than in a schemaless design. So the friction is relative. > The friction may be worth it, but calling it _frictionless_ was my issue with this post and the original I have a similar issue with calling a document-store _schemaless_. It's not schemaless, it has a schema. In fact, it has as many schemas as there are changes to the structure of the data. And this, in my opinion, is the biggest negative to that kind of design.

twic 9y ago

If you're using an ORM, you can generate the schema automatically. With Hibernate, you set the hibernate.hbm2ddl.auto property [1]. If you set it to 'create' or 'update', it will alter the database schema so that it matches your objects, which is handy for prototyping, and terrible for production. If you set it to 'validate', it will check that the database schema matches your objects, and refuse to start if it doesn't, useless for prototyping but ideal for production. [1] https://stackoverflow.com/questions/438146/hibernate-hbm2ddl-auto-possible-values-and-what-they-do https://stackoverflow.com/questions/438146/hibernate-hbm2ddl...

lewisl9029 9y ago
That's a neat feature, but as you may already know, ORMs come with their own baggage in the form of object-relational impedance mismatch. There's an entire rather-substantial Wikipedia article on it, so I won't go into it any further myself: https://en.wikipedia.org/wiki/Object-relational_impedance_mismatch https://en.wikipedia.org/wiki/Object-relational_impedance_mi... The sibling thread also brings up similar issues with ORMs: https://news.ycombinator.com/item?id=15127058 https://news.ycombinator.com/item?id=15127058
- twic 9y ago
  Eh. I've used ORMs and SQL extensively for many years. I think the concerns over mismatch are routinely overstated.
- aryehof 9y ago
  ORMs are a solution to the problem of the impedance mismatch between an object model and its corresponding relational model. It's not that ORMs come with the problem. I think it increasingly rare today to see real object domain models anyway - the original raison d'etre of ORMs. Instead it's common to see domain concepts modeled in the data layer and modified by logic (often limited to CRUD) in an application/service/controller layer. The problem with this of course is that as complexity increases, that app/service/controller layer increasingly approaches a big ball of mud. Edit: grammar

jimktrains2 9y ago

It's such a small amount of friction compared to the advantages of a good RDBMS.

wvenable 9y ago

You always have to maintain an explicit schema -- it's just defined in your code instead of the database. And depending on your tooling, it's not easier/faster to maintain that schema in code vs. the database. What is worse for schemaless databases is schema versioning. Your code will forever have to support every schema that has ever existed in production data. I have code to support schemaless data that was entered well over a decade ago. If I had simply used a relational database I would just have a single schema to deal with. During development, schema changes are quite frictionless. It also provides extra safety and documentation that any friction is completely worth it.

lewisl9029 9y ago
> You always have to maintain an explicit schema -- it's just defined in your code instead of the database. This is normally known as an implicit schema. It's implicit precisely because you don't explicitly maintain a schema separately from your application code. > During development, schema changes are quite frictionless. It also provides extra safety and documentation that any friction is completely worth it. The second sentence contradicts the first. And I'm not disagreeing with the second. The friction may be worth it, but calling it _frictionless_ was my issue with this post and the original (which went even further by asserting the friction somehow accelerated development).
- wvenable 9y ago
  > It's implicit precisely because you don't explicitly maintain a schema separately from your application code. But that's not completely true. There is plenty of code necessary for managing the schema and just the schema in a document database. Default values, relationships, validation, and managing previous version of the schema. I have plenty of code that just exists to handle documents in the "old" format. > The second sentence contradicts the first. Maybe I should have said almost frictionless instead of quite. And honestly, some things are less work with a schema (like creating a new defaulted boolean column) in an RDBMS than in a schemaless design. So the friction is relative. > The friction may be worth it, but calling it _frictionless_ was my issue with this post and the original I have a similar issue with calling a document-store _schemaless_. It's not schemaless, it has a schema. In fact, it has as many schemas as there are changes to the structure of the data. And this, in my opinion, is the biggest negative to that kind of design.