5 ms·

"No schemas. This was wonderful. What are schemas even for? They just make things hard to change for no reason." While they do mention the need to enforce cons

"No schemas. This was wonderful. What are schemas even for? They just make things hard to change for no reason." While they do mention the need to enforce constraints on your data, it's comments like these that make me wish all application developers were required to work as a DBA for a few months. A properly normalized and "constrained" database prevents data loss from stupid mistakes.

baconner 14y ago
Seriously, after that line I gave up on reading the rest. There's plenty to be said about schema vs no schema but its pretty ignorant to just dismiss the entire concept out of hand. Guess what - in lots of applications data integrity is more important than developer convenience.
- JamisonM 14y ago
  I made it to the next one before I gave up: "Relational databases grew up solving problems where data integrity was paramount and availability was not a big concern."
  - sk5t 14y ago
    Yow... is there a word for the special kind of bubble we're in now, with the profusion of Javascript and schema-free datastore-lovin' folks whose lack of experience in static typing and relational databases does not--in even the slightest way--constrain them from pronouncing their irrelevance?
    - ithkuil 14y ago
      NoOb ?
      - mh- 14y ago
        that's probably already reserved by some new fad where the notion of objects is considered absurd.
- jmathes 14y ago
  It was colorful language, not dismissal out of hand. It can be hard to communicate emotion online, so it's easy to take offense where none was meant. I think that's what happened here.
  - baconner 14y ago
    Definitely agree on communication of emotion, for instance I'm not offended in the least. :) all I'm saying is its hard for me to take someone's opinions on data stores seriously given that quote.
  - deleted 14y ago
    [deleted]
deleted 14y ago
[deleted]
SkyMarshal 14y ago
Also, they should be forced to read Fabian Pascal's rants about the end of Western Civilization, aggressive ignorance, and lack of understanding of the Relational Model. http://www.dbdebunk.com/ http://www.dbdebunk.com/
mattbriggs 14y ago
"no schemas" means "schema in the application layer". sometimes its nice for the additional flexibility, but its never as reliable.
- baudehlo 14y ago
  And not only that, your application becomes littered with: if (data.schema_version === 1) { ... } else if (data.schema_version === 2) { ... } UGH!
  - sreeix 14y ago
    But it is better than not having the ability to change the schema when there are more than a few million rows, thanks to the enormous time taken
    - baudehlo 14y ago
      That's just a limitation of MySQL, not relational databases in general. In Postgres you can do it live in a transaction.
    - mattbriggs 14y ago
      Schemaless would let you add/remove a field easily. What is hard is if you need to restructure things, which is also probably a more common occurence in a document db then a relational one. If you hit a few million rows, you are in for a world of hurt changing things in any data store
stephen 14y ago
Yeah, I don't get the anti-schema sentiment either. Coincidentally, I just wrote up my thoughts on it yesterday: http://draconianoverlord.com/2012/05/08/whats-wrong-with-a-schema.html http://draconianoverlord.com/2012/05/08/whats-wrong-with-a-s...
jmathes 14y ago
'A properly normalized and "constrained" database prevents data loss from stupid mistakes.' A properly written application layer also prevents data loss from stupid mistakes. A stupid mistake made while setting up a properly normalized database also causes data loss. You have to be very smart to be able to design a normalized constrained DB well. The fact that only smart people can do it doesn't mean that people who don't do it aren't smart.
- johnbender 14y ago
  "A properly written application layer also prevents data loss" Agreed but the application layer _generally_ doesn't have the abstractions at a point where it's trivially easy to put these safe guards in place like it is at the database layer. Also, "stupid mistakes" does not in any way imply that the people who make them are stupid. Nor am I implying that you have to be particularly intelligent to normalize and constrain a database properly. I'm simply lamenting how undervalued a "good schema" can be. [side note: upvoted your comment :D]
- stephen 14y ago
  > You have to be very smart to be able to design a normalized constrained DB well. Eh, nit picking, but I think "very smart" is overkill--I think "just smart" people should still be capable of designing normalized constrained schemas. If they are incapable of doing this, then I don't want them writing any code anyway. Being capable of doing it and choosing not to is either at least forgivable or completely understandable, depending on the situation.
- autarch 14y ago
  "You have to be very smart to be able to design a normalized constrained DB well." But you can be a complete moron and write "[a] properly written application layer [that] prevents data loss from stupid mistakes"? What's the difference? Writing correct code can be hard. I don't think it's particularly easier to apply all your constraint in app code unless you just don't know about the database backend you're using.
  - lmm 14y ago
JPKab 14y ago
It seems like there is a huge amount of ignorance (on the parts of both developers and DBAs) about the fact that NoSQL doesn't necessarily mean "no schema." For whatever reason, the "cool kids" in the Web dev world completely ignore the ugly stepchildren of the NoSQL world, graph databases. Graph databases provide the protections of a schema, but the schema can be altered without massive pain on the parts of developers. Even better, the RDF style graph databases have a W3C standard query language called SPARQL. Don't get me wrong, I love my RDBMS (MySQL and PostgreSQL) and I also use Mongo and love its extreme simplicity, but I wish more developers understood that schemas exist in places other than RDBMS.

baconner 14y ago

Seriously, after that line I gave up on reading the rest. There's plenty to be said about schema vs no schema but its pretty ignorant to just dismiss the entire concept out of hand. Guess what - in lots of applications data integrity is more important than developer convenience.

JamisonM 14y ago
I made it to the next one before I gave up: "Relational databases grew up solving problems where data integrity was paramount and availability was not a big concern."
- sk5t 14y ago
  Yow... is there a word for the special kind of bubble we're in now, with the profusion of Javascript and schema-free datastore-lovin' folks whose lack of experience in static typing and relational databases does not--in even the slightest way--constrain them from pronouncing their irrelevance?
  - ithkuil 14y ago
    NoOb ?
    - mh- 14y ago
      that's probably already reserved by some new fad where the notion of objects is considered absurd.
jmathes 14y ago
It was colorful language, not dismissal out of hand. It can be hard to communicate emotion online, so it's easy to take offense where none was meant. I think that's what happened here.
- baconner 14y ago
  Definitely agree on communication of emotion, for instance I'm not offended in the least. :) all I'm saying is its hard for me to take someone's opinions on data stores seriously given that quote.
- deleted 14y ago
  [deleted]

deleted 14y ago

[deleted]

SkyMarshal 14y ago

Also, they should be forced to read Fabian Pascal's rants about the end of Western Civilization, aggressive ignorance, and lack of understanding of the Relational Model. http://www.dbdebunk.com/ http://www.dbdebunk.com/

mattbriggs 14y ago

"no schemas" means "schema in the application layer". sometimes its nice for the additional flexibility, but its never as reliable.

baudehlo 14y ago
And not only that, your application becomes littered with: if (data.schema_version === 1) { ... } else if (data.schema_version === 2) { ... } UGH!
- sreeix 14y ago
  But it is better than not having the ability to change the schema when there are more than a few million rows, thanks to the enormous time taken
  - baudehlo 14y ago
    That's just a limitation of MySQL, not relational databases in general. In Postgres you can do it live in a transaction.
  - mattbriggs 14y ago
    Schemaless would let you add/remove a field easily. What is hard is if you need to restructure things, which is also probably a more common occurence in a document db then a relational one. If you hit a few million rows, you are in for a world of hurt changing things in any data store

stephen 14y ago

Yeah, I don't get the anti-schema sentiment either. Coincidentally, I just wrote up my thoughts on it yesterday: http://draconianoverlord.com/2012/05/08/whats-wrong-with-a-schema.html http://draconianoverlord.com/2012/05/08/whats-wrong-with-a-s...

jmathes 14y ago

'A properly normalized and "constrained" database prevents data loss from stupid mistakes.' A properly written application layer also prevents data loss from stupid mistakes. A stupid mistake made while setting up a properly normalized database also causes data loss. You have to be very smart to be able to design a normalized constrained DB well. The fact that only smart people can do it doesn't mean that people who don't do it aren't smart.

johnbender 14y ago
"A properly written application layer also prevents data loss" Agreed but the application layer _generally_ doesn't have the abstractions at a point where it's trivially easy to put these safe guards in place like it is at the database layer. Also, "stupid mistakes" does not in any way imply that the people who make them are stupid. Nor am I implying that you have to be particularly intelligent to normalize and constrain a database properly. I'm simply lamenting how undervalued a "good schema" can be. [side note: upvoted your comment :D]
stephen 14y ago
> You have to be very smart to be able to design a normalized constrained DB well. Eh, nit picking, but I think "very smart" is overkill--I think "just smart" people should still be capable of designing normalized constrained schemas. If they are incapable of doing this, then I don't want them writing any code anyway. Being capable of doing it and choosing not to is either at least forgivable or completely understandable, depending on the situation.
autarch 14y ago
"You have to be very smart to be able to design a normalized constrained DB well." But you can be a complete moron and write "[a] properly written application layer [that] prevents data loss from stupid mistakes"? What's the difference? Writing correct code can be hard. I don't think it's particularly easier to apply all your constraint in app code unless you just don't know about the database backend you're using.
- lmm 14y ago

JPKab 14y ago

It seems like there is a huge amount of ignorance (on the parts of both developers and DBAs) about the fact that NoSQL doesn't necessarily mean "no schema." For whatever reason, the "cool kids" in the Web dev world completely ignore the ugly stepchildren of the NoSQL world, graph databases. Graph databases provide the protections of a schema, but the schema can be altered without massive pain on the parts of developers. Even better, the RDF style graph databases have a W3C standard query language called SPARQL. Don't get me wrong, I love my RDBMS (MySQL and PostgreSQL) and I also use Mongo and love its extreme simplicity, but I wish more developers understood that schemas exist in places other than RDBMS.