5 ms·

> For rapid prototyping of new projects, it could be entirely reasonable to trade off long term data-consistency benefits of having a well-defined schema in ret

> For rapid prototyping of new projects, it could be entirely reasonable to trade off long term data-consistency benefits of having a well-defined schema in return for faster iteration times. But taking that schemaless prototype to production directly is decidedly unwise, so the final step in a prototyping process like this should involve a refactoring of your data model to introduce a schema/migrations system before that point. I don't get it. If you're not in production anyway, you're not working with real data. And if you're not working with real data, you don't have to migrate anything. The entire problem just straight-up disappears. Just blow away your database and recreate it with the new schema. Modify your test data insertion scripts to match and load them.

lewisl9029 9y ago
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.
tomc1985 9y ago
Or alter your schema in the client. Quite easy to right-click and 'Add New Column' or ADD COLUMN or whatnot. I'm trying this with a new project and it is resulting in a data model that feels cleaner and hand-built. One can simply capture the schema when they've found a good structure, and then use that as the starting point for a migration system (like ActiveRecord).

lewisl9029 9y ago

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.

tomc1985 9y ago

Or alter your schema in the client. Quite easy to right-click and 'Add New Column' or ADD COLUMN or whatnot. I'm trying this with a new project and it is resulting in a data model that feels cleaner and hand-built. One can simply capture the schema when they've found a good structure, and then use that as the starting point for a migration system (like ActiveRecord).