4 ms·

> Think about a web developer who shows up to a hackathon, ready to break out his new side project. He doesn’t want to spend hours planning schema or creating d

> Think about a web developer who shows up to a hackathon, ready to break out his new side project. He doesn’t want to spend hours planning schema or creating databases and tables. He just wants a quick way to persist and retrieve data. When you say that, this is what I hear: > MongoDB is the quickest way to accrue large quantities of technical debt. In this analogy, fast accrual of debt leads to one place: bankruptcy. Which, in software engineering, is the ground-up rewrite.

batgaijin 14y ago
Uh, what? What's wrong with using MongoDB to screw around while you are developing it? It's not like you have to marry it. Figure out what schema you are going to be using, and then write your table layouts for Postgres.
- taligent 14y ago
  Sorry but what you are suggesting is crazy. MongoDB has a completely different data model to PostgreSQL. You can't just build your app around one approach and then trivially move to another. Pick the database for the data model not the other way around.
  - zacharyvoase 14y ago
    I could not fail to disagree with you less. (^ that means I agree). This idea that you can arbitrarily switch between database X and database Y with radically different models is a really harmful fallacy. Code which attempts to ‘abstract away the details’ is often leaky, buggy, complex, and just as prone to tight coupling as any other solution. At the very least, such has been my experience. And I think certain individuals have a policy of downvoting those comments they disagree with rather than explaining their counterpoints in a comment.
    - Morg 14y ago
      But no, it's actually worse my dear. For example, let's say you start with mysql. You have no features whatsoever, implement your own workarounds or simplified model, create your own text search because there is none (except in Myisam but then that's totally fucked up), and then you migrate to postgres, where every feature is available and working as advertised, you still have your workarounds and text search to remove, and your data model is all wrong because it was made on a pitiful dbms. MongoDB is the same but worse, it has even less features than MySQL and is not even particularly fast so ... Those who believe it's slow to design a database are just not DBAs and should leave it to the pros. I write data models for full applications in SQL directly without any document or plan or layout, and it doesn't take long. But then, I know why mysql is a piece of crap, I have truly kick ass instead of triggers on views on information_schema that maintain historifying triggers on any table whatsoever, so not exactly a first-timer. Really, those people are only afraid of learning (the real powerful tools), and will stick to the shittiest ones provided they're just a bit easier to learn. When google does not use an SQL database, it's because for the very simple task at hand, a full-fledged DBMS is overkill. Because what they do is indexed search. not run a database. thinking you can replace a database with indexed search is going back to the dark ages before databases were invented.
    - lusr 14y ago
      In my experience there isn't an issue. It all comes down to how well you design your application. Here's the interface to a service in a fun side project I'm currently working on (comments removed): public interface IAnalysisService { Guid CreateAnalysis(Guid ownerId, string name); void LoadingAnalysisInputs(Guid analysisId); void RequestAnalysis(Guid analysisId, string number, IEnumerable<Records> inputs); Guid CreateAndRequestAnalysis(Guid ownerId, string name, string number, params Records[] inputs); Guid CreateAndRequestAnalysis(Guid ownerId, string name, string number, IEnumerable<Records> inputs); Analysis FindAnalysis(Guid analysisId); Analysis FindAnalysisForProcessing(Guid analysisId); void CompletedAnalysis(Guid analysisId, AnalysisResults results); void FailedAnalysis(Guid analysisId, string reason, params object[] args); } These methods implement some business rules, do some database work and throw a few messages onto a service bus. Why is it so hard to believe that the database implementation for any of these methods affects the consumers? Here's a sample implementation: public void FailedAnalysis(Guid analysisId, string reason, params object[] args) { AnalysisRepository.Failed(analysisId, string.Format(reason, args)); Bus.Send(new AnalysisCompleted {AnalysisId = analysisId}); } I don't see any obvious bugs, complexity or leaky abstractions.
      - edandersen 14y ago
        Your comment is lost on most people here - Ruby doesn't have interfaces.
        batgaijin 14y ago
        And ruby doesn't have macros that would make such a db switch even simpler.
zacharyvoase 14y ago
I’m questioning whether it’s productive to consider popularity when building components that will underly the long-term architecture of other people’s software. Overnight success can disappear as quickly as it arrives, and I, for one, have a lower time preference for these things. I’d rather be responsible for a tool that gains a lot of respect for being a robust, reliable and high-performance piece of kit over a long period of time, than one which had blazing popularity in the beginning but then proved to be the source of many a developer’s nightmare later.
- slurgfest 14y ago
  Popularity of a non-overnight type is one of the biggest reasons to use something like Postgres or Rails: this means it gets beat on a lot, there is documentation and you can find people who know how to use it. Some projects with this kind of popularity (n.b.: not the ones I mentioned by name) are designed like shit, do irrational things, have performance problems, have security problems, whatever. But they have been used and they are usable and you can find documentation and experts to deal with them.
rdtsc 14y ago
> In this analogy, fast accrual of debt leads to one place: bankruptcy. Which, in software engineering, is the ground-up rewrite. Bankruptcy can be just that -- bankruptcy and loss of job, liquidation of a company. It can go either way. Spending years perfecting a product and polishing it to 100% only wake up and find out that someone else used something crappy fast and easy to setup thing, got the product out, and started getting real customers. Now they have enough to go double their team and start rewriting if they want. Or picking something fast and easy to setup and after getting a few initial customers finding that scaling out doesn't work. The site crashes and everything is going to shit, data is silently corrupted, it has already been backed up and overwrote older backups and customers are leaving for something else, maybe not as flashy and cool, but something that works.

batgaijin 14y ago

Uh, what? What's wrong with using MongoDB to screw around while you are developing it? It's not like you have to marry it. Figure out what schema you are going to be using, and then write your table layouts for Postgres.

taligent 14y ago
Sorry but what you are suggesting is crazy. MongoDB has a completely different data model to PostgreSQL. You can't just build your app around one approach and then trivially move to another. Pick the database for the data model not the other way around.
- zacharyvoase 14y ago
  I could not fail to disagree with you less. (^ that means I agree). This idea that you can arbitrarily switch between database X and database Y with radically different models is a really harmful fallacy. Code which attempts to ‘abstract away the details’ is often leaky, buggy, complex, and just as prone to tight coupling as any other solution. At the very least, such has been my experience. And I think certain individuals have a policy of downvoting those comments they disagree with rather than explaining their counterpoints in a comment.
  - Morg 14y ago
    But no, it's actually worse my dear. For example, let's say you start with mysql. You have no features whatsoever, implement your own workarounds or simplified model, create your own text search because there is none (except in Myisam but then that's totally fucked up), and then you migrate to postgres, where every feature is available and working as advertised, you still have your workarounds and text search to remove, and your data model is all wrong because it was made on a pitiful dbms. MongoDB is the same but worse, it has even less features than MySQL and is not even particularly fast so ... Those who believe it's slow to design a database are just not DBAs and should leave it to the pros. I write data models for full applications in SQL directly without any document or plan or layout, and it doesn't take long. But then, I know why mysql is a piece of crap, I have truly kick ass instead of triggers on views on information_schema that maintain historifying triggers on any table whatsoever, so not exactly a first-timer. Really, those people are only afraid of learning (the real powerful tools), and will stick to the shittiest ones provided they're just a bit easier to learn. When google does not use an SQL database, it's because for the very simple task at hand, a full-fledged DBMS is overkill. Because what they do is indexed search. not run a database. thinking you can replace a database with indexed search is going back to the dark ages before databases were invented.
  - lusr 14y ago
    In my experience there isn't an issue. It all comes down to how well you design your application. Here's the interface to a service in a fun side project I'm currently working on (comments removed): public interface IAnalysisService { Guid CreateAnalysis(Guid ownerId, string name); void LoadingAnalysisInputs(Guid analysisId); void RequestAnalysis(Guid analysisId, string number, IEnumerable<Records> inputs); Guid CreateAndRequestAnalysis(Guid ownerId, string name, string number, params Records[] inputs); Guid CreateAndRequestAnalysis(Guid ownerId, string name, string number, IEnumerable<Records> inputs); Analysis FindAnalysis(Guid analysisId); Analysis FindAnalysisForProcessing(Guid analysisId); void CompletedAnalysis(Guid analysisId, AnalysisResults results); void FailedAnalysis(Guid analysisId, string reason, params object[] args); } These methods implement some business rules, do some database work and throw a few messages onto a service bus. Why is it so hard to believe that the database implementation for any of these methods affects the consumers? Here's a sample implementation: public void FailedAnalysis(Guid analysisId, string reason, params object[] args) { AnalysisRepository.Failed(analysisId, string.Format(reason, args)); Bus.Send(new AnalysisCompleted {AnalysisId = analysisId}); } I don't see any obvious bugs, complexity or leaky abstractions.
    - edandersen 14y ago
      Your comment is lost on most people here - Ruby doesn't have interfaces.
      - batgaijin 14y ago
        And ruby doesn't have macros that would make such a db switch even simpler.

zacharyvoase 14y ago

I’m questioning whether it’s productive to consider popularity when building components that will underly the long-term architecture of other people’s software. Overnight success can disappear as quickly as it arrives, and I, for one, have a lower time preference for these things. I’d rather be responsible for a tool that gains a lot of respect for being a robust, reliable and high-performance piece of kit over a long period of time, than one which had blazing popularity in the beginning but then proved to be the source of many a developer’s nightmare later.

slurgfest 14y ago
Popularity of a non-overnight type is one of the biggest reasons to use something like Postgres or Rails: this means it gets beat on a lot, there is documentation and you can find people who know how to use it. Some projects with this kind of popularity (n.b.: not the ones I mentioned by name) are designed like shit, do irrational things, have performance problems, have security problems, whatever. But they have been used and they are usable and you can find documentation and experts to deal with them.

rdtsc 14y ago

> In this analogy, fast accrual of debt leads to one place: bankruptcy. Which, in software engineering, is the ground-up rewrite. Bankruptcy can be just that -- bankruptcy and loss of job, liquidation of a company. It can go either way. Spending years perfecting a product and polishing it to 100% only wake up and find out that someone else used something crappy fast and easy to setup thing, got the product out, and started getting real customers. Now they have enough to go double their team and start rewriting if they want. Or picking something fast and easy to setup and after getting a few initial customers finding that scaling out doesn't work. The site crashes and everything is going to shit, data is silently corrupted, it has already been backed up and overwrote older backups and customers are leaving for something else, maybe not as flashy and cool, but something that works.