6 ms·

There are tons of reasons for that. Let me pull some of them from my butt: Reason #1: Devs aren't Ops. Reason #2: Devs need something new on their resume. Re

There are tons of reasons for that. Let me pull some of them from my butt: Reason #1: Devs aren't Ops. Reason #2: Devs need something new on their resume. Reason #3: Certain type of Devs would read blogs and get excited and skipping scientific mumbo-jumbo and directly take the blogs as _the_ source of truth. Reason #4: It's easy to bootstrap (schemaless, etc) your weekend project. Dealing with DB apparently is tedious for devs. I'm sure others can add more... Let me feel your love HN-ers ;)

viraptor 15y ago
Why do I get the feeling that you're an op and look down on development people? If that's really true, try to start developing some project and see how you like frequent schema changes, trying to synchronise schemas with peers, resolving relation issues when merging features, etc. On the other hand if you abstract your interaction with data enough, you can change the whole backend later once it's stable and not care about it up-front. What I hear you saying is unfortunately - it's worse for ops, so noone should use it.
- hello_moto 15y ago
  I've been dev since I graduated. I had been everything else during my intern (dev, qa, test-automation developer, tools dev, build engineer, integration engineer, etc). Are you saying that Rails schema migration can only solve 10% of your migration needs? That kinda suck bro.
  - viraptor 15y ago
    Migration tools are great once you stop changing the schema very often like it happens when a project starts. This of course depends on the project... if you can have a full design from the start, it's probably going to work too. If you don't know the exact requirements or way to get there - not so much.
    - hello_moto 15y ago
      If you change your schema once every 2-3 days, something wrong with whomever leading the software project. That's like writing a software with zero planning or lack of knowledge for the problem domain. I don't care if it is a startup or not. Come up with a very simple idea, draw the models in ER diagram, implement that stuff. It's very hard to imagine that tomorrow suddenly all relationships need to be changed. Even if that is the case, scrap your Repository/Entity model and start from the beginning. Nothing can help you much if the fundamentals are wrong.
      - mrkurt 15y ago
        Everything else in a software project changes frequently, especially during the early days. "Fundamentals" don't help you know more ahead of time and it's really nice to be able to quickly adjust when you come across something you hadn't anticipated. I tried building a small side project with Postgres about 8 months ago (after not really doing rdbms stuff for 18 months before) and was amazed at how inflexible it felt, and how much frustration used to seem normal.
        lwat 15y ago
        Could you elaborate please? What were you doing and what made it feel frustrating and inflexible exactly?
        einhverfr 15y ago
        That's what prototyping and peer review are for, I write up a schema, send to everyone else on the team, get feedback. If users are invovled get it from them too.... take in all the feedback, write up a new draft, wash, rinse, repeat until running out of shampoo (i.e. feedback)..... Once things are pretty stable, do a prototype, address any oversights, do the real thing. It's not rocket science.
      - Joakal 15y ago
        As a startup, change of minds is pretty normal to the point that it's far more better to have the tools to quickly implement it rather than plan/document it well. The only documentation is the general gist behind the database. If it prototypes well, then further refine it with ER diagrams for future maintenance. Why is planning everything without validation better than above?
  - moe 15y ago
    Are you saying that Rails schema migration can only solve 10% of your migration needs? Rails is a bad example here as their primitive migration-system still forces the developer to write those stupid migrations by hand. Django/South just auto-generates them which removes a huge chore from the daily development workflow.
    - hello_moto 15y ago
      That's excellent! I think it's time for me to learn some Django.
- zzzeek 15y ago
  > On the other hand if you abstract your interaction with data enough, you can change the whole backend later once it's stable and not care about it up-front. have to disagree with this. By forcing yourself to work with a data layer so abstracted that you can't even reference whether you're dealing with a JSON document or a set of twelve joinable tables, you're going to write the most tortured and inefficient application. Non trivial applications require leaky abstractions.
  - einhverfr 15y ago
    And you lose the ability to do data constraints well. Put clearly: Declarative data constraints (including referential integrity, but also check constraints and the like) are the single most important features of RDBMS's for most applications.......
- quanticle 15y ago
  On the other hand, if you abstract your interaction with data enough, you can change the whole backend later once it's stable and not care about it up-front. This is a conception of data that is more true in theory than it is in practice. In practice, if you want to query your data and efficiently, you'll need to worry about how it's stored. You'll have to worry about the failure cases. Of course, it is definitely application dependent. If you're just writing a Wordpress-replacement, you can probably choose whatever data store you want and just write an abstraction layer on top of it (especially if you don't care about performance). On the other hand, if you're looking at querying and indexing terabytes (or more) of data, you'll have to work very closely with your data store to extract maximum performance.
- sausagefeet 15y ago
  > If that's really true, try to start developing some project and see how you like frequent schema changes, trying to synchronise schemas with peers, resolving relation issues when merging features, How does something like MongoDB actually help with this, though? Certainly a lack of a schema lets you be more nimble in changing it, but you still have to write code to handle whatever schema you decide rather than letting a battle tested RDBMS handle it. I think NoSQLs have their uses but not forcing correctness on your data as a feature is not one of them. But I also believe in static typing.
- einhverfr 15y ago
  "If that's really true, try to start developing some project and see how you like frequent schema changes, trying to synchronise schemas with peers, resolving relation issues when merging features, etc. On the other hand if you abstract your interaction with data enough, you can change the whole backend later once it's stable and not care about it up-front." I can sort of sympathize with this a little. I used to use MySQL for schema prototyping and then move stable stuff to PostgreSQL back when PostgreSQL lacked an alter table drop column capability. However today, this is less of a factor. Good database engineering is engineering. It's a math intensive discipline. Today I work often with intelligent database design approaches, while trying to allow for agility in higher levels of the app. Don't get me wrong, NoSQL is great for some things. However it is NEVER a replacement for a good RDBMS where this is needed.
Devilboy 15y ago
Right there with you. The excuses I hear for not wanting to use a good 'ole RDBMS just does not make sense to me sometimes. CREATE TABLE too hard? Time consuming? Difficult? Those who do not study the history of databases are doomed to repeat it. Soon we'll add back row-level write locks, transaction logging, schemas, multiple indexes and one day they wake up with MongoSQL.
- hello_moto 15y ago
  Well, mostly the migration part that Devs don't want to deal with. Most modern languages have migration utilities (Flyway for Java, Rails migration for Ruby, Python should have their de-facto migration for Django by now or else they fail hard, and JS... well.. let's wait until Node.js users decided to use RDBMS).
  - stevelosh 15y ago
    Python should have their de-facto migration for Django by now or else they fail hard Yep: http://south.aeracode.org/ http://south.aeracode.org/
- mnutt 15y ago
  You say that like it's a failure on the devs' part, but that's kind of like blaming regular users for not switching to Linux because they don't like editing network configuration files.* It's masking the problem that there are real developer-friendliness issues with the existing databases. And taunting users will not get them to switch back. * but then Linux distros get network autoconfiguration and suddenly it's obvious that it was the right solution all along.
  - ehthere 15y ago
    Every major RDBMS has both command-line and GUI interfaces to create and change schemas. What exactly is missing in the dev-friendlyness department?
    - LeafStorm 15y ago
japherwocky 15y ago
Well here's a fuck you back from a dev: my time is finite and everyone wants a piece of it; If I can save an hour a day by never having to think about my database? If I can shave a week or two of labor off a project? It's really easy to work with. This is why people keep using it.
- ehthere 15y ago
  What about all the time you'll waste debugging your app because you can't make good assumptions about the structure of your data?
  - rmgraham 15y ago
    Isn't that the same argument some use against dynamic typing in programming languages?
    - einhverfr 15y ago
      One reason Moose rocks for Perl is it gives you the ability to get some stronger type checking in the dynamically typed language. So yes, I think dynamic typing can lead to debugging nightmares. It just so happens that often the fact that other factors make up for this in many cases.....
- hello_moto 15y ago
  Back at you boy. I'm a dev. I hate dealing with other dev that wasted my time just because he ain't lover with RDBMS and decided to write more code and add more infrastructure components (that includes message queue unless you absolutely have no choice). My time is finite. Ops time is finite. Obviously you decided to dick around with mine and Ops. How bout I send you to the QA department to write automation and software tools so you don't dick around with production code? You can write with any language and any storage systems you'd like there.
  - japherwocky 15y ago
    Let me guess, you're the guy who makes sure there's a "Senior" in his title and you use django because the docs are so great. I'm sorry you work with incompetent people. Sounds like you're in a cubicle farm somewhere. While you're in a meeting swinging your seniority around, I'll be over here shipping products faster than your team.

viraptor 15y ago

Why do I get the feeling that you're an op and look down on development people? If that's really true, try to start developing some project and see how you like frequent schema changes, trying to synchronise schemas with peers, resolving relation issues when merging features, etc. On the other hand if you abstract your interaction with data enough, you can change the whole backend later once it's stable and not care about it up-front. What I hear you saying is unfortunately - it's worse for ops, so noone should use it.

hello_moto 15y ago
I've been dev since I graduated. I had been everything else during my intern (dev, qa, test-automation developer, tools dev, build engineer, integration engineer, etc). Are you saying that Rails schema migration can only solve 10% of your migration needs? That kinda suck bro.
- viraptor 15y ago
  Migration tools are great once you stop changing the schema very often like it happens when a project starts. This of course depends on the project... if you can have a full design from the start, it's probably going to work too. If you don't know the exact requirements or way to get there - not so much.
  - hello_moto 15y ago
    If you change your schema once every 2-3 days, something wrong with whomever leading the software project. That's like writing a software with zero planning or lack of knowledge for the problem domain. I don't care if it is a startup or not. Come up with a very simple idea, draw the models in ER diagram, implement that stuff. It's very hard to imagine that tomorrow suddenly all relationships need to be changed. Even if that is the case, scrap your Repository/Entity model and start from the beginning. Nothing can help you much if the fundamentals are wrong.
    - mrkurt 15y ago
      Everything else in a software project changes frequently, especially during the early days. "Fundamentals" don't help you know more ahead of time and it's really nice to be able to quickly adjust when you come across something you hadn't anticipated. I tried building a small side project with Postgres about 8 months ago (after not really doing rdbms stuff for 18 months before) and was amazed at how inflexible it felt, and how much frustration used to seem normal.
      - lwat 15y ago
        Could you elaborate please? What were you doing and what made it feel frustrating and inflexible exactly?
      - einhverfr 15y ago
        That's what prototyping and peer review are for, I write up a schema, send to everyone else on the team, get feedback. If users are invovled get it from them too.... take in all the feedback, write up a new draft, wash, rinse, repeat until running out of shampoo (i.e. feedback)..... Once things are pretty stable, do a prototype, address any oversights, do the real thing. It's not rocket science.
    - Joakal 15y ago
      As a startup, change of minds is pretty normal to the point that it's far more better to have the tools to quickly implement it rather than plan/document it well. The only documentation is the general gist behind the database. If it prototypes well, then further refine it with ER diagrams for future maintenance. Why is planning everything without validation better than above?
- moe 15y ago
  Are you saying that Rails schema migration can only solve 10% of your migration needs? Rails is a bad example here as their primitive migration-system still forces the developer to write those stupid migrations by hand. Django/South just auto-generates them which removes a huge chore from the daily development workflow.
  - hello_moto 15y ago
    That's excellent! I think it's time for me to learn some Django.
zzzeek 15y ago
> On the other hand if you abstract your interaction with data enough, you can change the whole backend later once it's stable and not care about it up-front. have to disagree with this. By forcing yourself to work with a data layer so abstracted that you can't even reference whether you're dealing with a JSON document or a set of twelve joinable tables, you're going to write the most tortured and inefficient application. Non trivial applications require leaky abstractions.
- einhverfr 15y ago
  And you lose the ability to do data constraints well. Put clearly: Declarative data constraints (including referential integrity, but also check constraints and the like) are the single most important features of RDBMS's for most applications.......
quanticle 15y ago
On the other hand, if you abstract your interaction with data enough, you can change the whole backend later once it's stable and not care about it up-front. This is a conception of data that is more true in theory than it is in practice. In practice, if you want to query your data and efficiently, you'll need to worry about how it's stored. You'll have to worry about the failure cases. Of course, it is definitely application dependent. If you're just writing a Wordpress-replacement, you can probably choose whatever data store you want and just write an abstraction layer on top of it (especially if you don't care about performance). On the other hand, if you're looking at querying and indexing terabytes (or more) of data, you'll have to work very closely with your data store to extract maximum performance.
sausagefeet 15y ago
> If that's really true, try to start developing some project and see how you like frequent schema changes, trying to synchronise schemas with peers, resolving relation issues when merging features, How does something like MongoDB actually help with this, though? Certainly a lack of a schema lets you be more nimble in changing it, but you still have to write code to handle whatever schema you decide rather than letting a battle tested RDBMS handle it. I think NoSQLs have their uses but not forcing correctness on your data as a feature is not one of them. But I also believe in static typing.
einhverfr 15y ago
"If that's really true, try to start developing some project and see how you like frequent schema changes, trying to synchronise schemas with peers, resolving relation issues when merging features, etc. On the other hand if you abstract your interaction with data enough, you can change the whole backend later once it's stable and not care about it up-front." I can sort of sympathize with this a little. I used to use MySQL for schema prototyping and then move stable stuff to PostgreSQL back when PostgreSQL lacked an alter table drop column capability. However today, this is less of a factor. Good database engineering is engineering. It's a math intensive discipline. Today I work often with intelligent database design approaches, while trying to allow for agility in higher levels of the app. Don't get me wrong, NoSQL is great for some things. However it is NEVER a replacement for a good RDBMS where this is needed.

Devilboy 15y ago

Right there with you. The excuses I hear for not wanting to use a good 'ole RDBMS just does not make sense to me sometimes. CREATE TABLE too hard? Time consuming? Difficult? Those who do not study the history of databases are doomed to repeat it. Soon we'll add back row-level write locks, transaction logging, schemas, multiple indexes and one day they wake up with MongoSQL.

hello_moto 15y ago
Well, mostly the migration part that Devs don't want to deal with. Most modern languages have migration utilities (Flyway for Java, Rails migration for Ruby, Python should have their de-facto migration for Django by now or else they fail hard, and JS... well.. let's wait until Node.js users decided to use RDBMS).
- stevelosh 15y ago
  Python should have their de-facto migration for Django by now or else they fail hard Yep: http://south.aeracode.org/ http://south.aeracode.org/
mnutt 15y ago
You say that like it's a failure on the devs' part, but that's kind of like blaming regular users for not switching to Linux because they don't like editing network configuration files.* It's masking the problem that there are real developer-friendliness issues with the existing databases. And taunting users will not get them to switch back. * but then Linux distros get network autoconfiguration and suddenly it's obvious that it was the right solution all along.
- ehthere 15y ago
  Every major RDBMS has both command-line and GUI interfaces to create and change schemas. What exactly is missing in the dev-friendlyness department?
  - LeafStorm 15y ago

japherwocky 15y ago

Well here's a fuck you back from a dev: my time is finite and everyone wants a piece of it; If I can save an hour a day by never having to think about my database? If I can shave a week or two of labor off a project? It's really easy to work with. This is why people keep using it.

ehthere 15y ago
What about all the time you'll waste debugging your app because you can't make good assumptions about the structure of your data?
- rmgraham 15y ago
  Isn't that the same argument some use against dynamic typing in programming languages?
  - einhverfr 15y ago
    One reason Moose rocks for Perl is it gives you the ability to get some stronger type checking in the dynamically typed language. So yes, I think dynamic typing can lead to debugging nightmares. It just so happens that often the fact that other factors make up for this in many cases.....
hello_moto 15y ago
Back at you boy. I'm a dev. I hate dealing with other dev that wasted my time just because he ain't lover with RDBMS and decided to write more code and add more infrastructure components (that includes message queue unless you absolutely have no choice). My time is finite. Ops time is finite. Obviously you decided to dick around with mine and Ops. How bout I send you to the QA department to write automation and software tools so you don't dick around with production code? You can write with any language and any storage systems you'd like there.
- japherwocky 15y ago
  Let me guess, you're the guy who makes sure there's a "Senior" in his title and you use django because the docs are so great. I'm sorry you work with incompetent people. Sounds like you're in a cubicle farm somewhere. While you're in a meeting swinging your seniority around, I'll be over here shipping products faster than your team.