4 ms·

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

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.

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.