5 ms·

> Schema-less design allows data to be modeled more flexibly than in relational databases, which lock the developer into a single schema at any given point in o

> Schema-less design allows data to be modeled more flexibly than in relational databases, which lock the developer into a single schema at any given point in operations. Implying that schemaless design is a GOOD thing

xj9 12y ago
I've always been interested in NoSQL databases, but I never understood the advantage of a schema-less design. Migrations make it so you can change the structure of your data at any time so you really aren't locked into anything. Even ignoring that, your data has to have some kind of shape to it (a kind of ad-hoc schema) and you still have to deal with data whose shape has changed (which migrations take care of for you).
- zenbowman 12y ago
  There is no advantage of a schema-less design, because there is always a schema. It is just a matter of whether the schema is made explicit and enforced, or whether it is scattered all over the application code.
  - nrser 12y ago
    it can make it much easier to do on-demand migrations: in massive online apps, a large percentage of data is essentially 'dead' - it's unlikely anyone will ever access it again. and massive online apps (call it 'web-scale' if you will ;) can accumulate a lot of data. the systems they're discussing make it easier to migrate data as needed instead of at once (which sometimes isn't even possible if the infrastructure is really being pounded).
- threeseed 12y ago
  The advantage of schemaless is that if you are adding extra attributes (most common database change) then you don't have to do any migration. And migrations have a long history of having side effects as well as requiring Database/Operations teams involvement if you work in the enterprise. And as I mentioned before the "shape of your data" is quite often defined in your application anyway.
  - collyw 12y ago
    I imagine that side effects exist and are more difficult to spot in a NoSQL migration.
- skybrian 12y ago
  Migrations get expensive and risky when you have lots of data. Being able to do them incrementally is sometimes worth the complication of maintaining code to read older versions. A traditional database doesn't let you do that; you have to execute an "alter table" statement all at once.
  - nrser 12y ago
    yup. once upon a time we had a MySQL db on commodity hardware doing around 6K QPS with over 100M rows in the biggest table. you can't do much to it without taking it offline, and even then you have no idea if/when the migration will complete.
  - Rapzid 12y ago
    The current state-of-the art with MySQL uses temporary tables and triggers to perform online migrations.
threeseed 12y ago
Database schemas are a complete waste of time for many applications. If you have a well defined application data model and you use an ORM that what does a database schema actually get you ? You can centralise and better enforce data integrity within your application.
- TylerE 12y ago
  > You can centralise and better enforce data integrity within your application. Right up until someone rights an import script! That's WebScale(tm)
- collyw 12y ago
  How is it better enforced in your application? I realize that having worked with dynamic languages for many years, I rely on the database for keeping my data types in check. That way the language can be more relaxed about it. Nulls are still a major pain in the arse though.
spullara 12y ago
The best way to handle this is through schema evolution rather than migration. No red flag days or downtime. Works with rolling upgrades. See strategies like my own avrobase, facebook/twitter thrift or google's protocol buffers.
Argorak 12y ago
Schemaless design is a tradeoff like many things. There are systems where being able allow the client to write new data structures can be important. (one example I've seen was a system that tracked arbitrary metric messages from devices that could add fields based on their device type. The system needed to be forward-compatible without speaking to the parties implementing those devices). Also, some of those systems have a _dynamic_ schema, e.g. Elasticsearch, where they learn the data type on the fly, but disallow incompatible changes on fields already known, which is a bit of an inbetween.

xj9 12y ago

I've always been interested in NoSQL databases, but I never understood the advantage of a schema-less design. Migrations make it so you can change the structure of your data at any time so you really aren't locked into anything. Even ignoring that, your data has to have some kind of shape to it (a kind of ad-hoc schema) and you still have to deal with data whose shape has changed (which migrations take care of for you).

zenbowman 12y ago
There is no advantage of a schema-less design, because there is always a schema. It is just a matter of whether the schema is made explicit and enforced, or whether it is scattered all over the application code.
- nrser 12y ago
  it can make it much easier to do on-demand migrations: in massive online apps, a large percentage of data is essentially 'dead' - it's unlikely anyone will ever access it again. and massive online apps (call it 'web-scale' if you will ;) can accumulate a lot of data. the systems they're discussing make it easier to migrate data as needed instead of at once (which sometimes isn't even possible if the infrastructure is really being pounded).
threeseed 12y ago
The advantage of schemaless is that if you are adding extra attributes (most common database change) then you don't have to do any migration. And migrations have a long history of having side effects as well as requiring Database/Operations teams involvement if you work in the enterprise. And as I mentioned before the "shape of your data" is quite often defined in your application anyway.
- collyw 12y ago
  I imagine that side effects exist and are more difficult to spot in a NoSQL migration.
skybrian 12y ago
Migrations get expensive and risky when you have lots of data. Being able to do them incrementally is sometimes worth the complication of maintaining code to read older versions. A traditional database doesn't let you do that; you have to execute an "alter table" statement all at once.
- nrser 12y ago
  yup. once upon a time we had a MySQL db on commodity hardware doing around 6K QPS with over 100M rows in the biggest table. you can't do much to it without taking it offline, and even then you have no idea if/when the migration will complete.
- Rapzid 12y ago
  The current state-of-the art with MySQL uses temporary tables and triggers to perform online migrations.

threeseed 12y ago

Database schemas are a complete waste of time for many applications. If you have a well defined application data model and you use an ORM that what does a database schema actually get you ? You can centralise and better enforce data integrity within your application.

TylerE 12y ago
> You can centralise and better enforce data integrity within your application. Right up until someone rights an import script! That's WebScale(tm)
collyw 12y ago
How is it better enforced in your application? I realize that having worked with dynamic languages for many years, I rely on the database for keeping my data types in check. That way the language can be more relaxed about it. Nulls are still a major pain in the arse though.

spullara 12y ago

The best way to handle this is through schema evolution rather than migration. No red flag days or downtime. Works with rolling upgrades. See strategies like my own avrobase, facebook/twitter thrift or google's protocol buffers.

Argorak 12y ago

Schemaless design is a tradeoff like many things. There are systems where being able allow the client to write new data structures can be important. (one example I've seen was a system that tracked arbitrary metric messages from devices that could add fields based on their device type. The system needed to be forward-compatible without speaking to the parties implementing those devices). Also, some of those systems have a _dynamic_ schema, e.g. Elasticsearch, where they learn the data type on the fly, but disallow incompatible changes on fields already known, which is a bit of an inbetween.