4 ms·

I agree, he could easily be using a JVM-based stack to get the same or better efficiency out of his 1-server configuration. Also there's some clearly naivety w

I agree, he could easily be using a JVM-based stack to get the same or better efficiency out of his 1-server configuration. Also there's some clearly naivety when bragging about his "low cost" $200/month setup. His SQL Server licenses alone will probably triple or quadruple his costs when his Bizspark status runs out.

sljd 13y ago
Well, AFAIK he can easily switch to MySQL for instance, under the same ORM.
- hapless 13y ago
  MySQL is possibly the single hardest database to port to/from, because it supports nothing.
  - twistedpair 13y ago
    In that case porting FROM it should be simple. TO it would be hard if you're using all those fancy features of your current DB. That's why I eschew all the sirens from Oracle DBA's of "oh... but Oracle can do that too!" Keep database activities in the database and application activities in the app.
    - regularfry 13y ago
      In my experience, MySQL lets you get into a state where questions like "hang, on - what's the difference between a DATE of '0000-00-00' and NULL?" are commonplace. This makes porting from it... not simple.
      - deleted 13y ago
        [deleted]
      - sljd 13y ago
        Although I have no experience with MySQL, this kind of problems have to be resolved by using LINQ to SQL since every db type is automatically mapped to its .NET counterpart. The DateTime .NET type then has only one representation of null.
      - sljd 13y ago
        Or what you're saying is that if you store a date of zero VALUE to MySQL it could be magically replaced by NULL internally? That would be really crazy.
        hapless 13y ago
        I seem to recall it is actually the other way around, and storing a null results in a nonsense date. Added bonus: some versions will segfault if you pass an un-formattable date value.
    - hapless 13y ago
      The problem is that MySQL deviates from the standards (all of them) in surprising and uncomfortable ways. porting from MySQL is fun, when, for example, your target database actually ENFORCES the constraints that MySQL accepted but silently ignored. MySQL doesn't have that feature, but it won't bother to tell you. Postgres, Oracle, MS SQL all support a (very large) common subset of features, so if you avoid stored procedures and db-specific features, you can port among them easily. This is not true for MySQL.
pmelendez 13y ago
>"I agree, he could easily be using a JVM-based stack" Maybe but believe it or not, there are people who HATE Java (that would includes me)
- obviouslygreen 13y ago
  I'm not a huge fan of Java either, but sometimes it's important to get past that and either try and work with a language that's extremely effective for some deployments, or consider that the JVM supports quite a bit more platforms than just Java.
- city41 13y ago
  There's always Scala, clojure, groovy, etc.
- hkarthik 13y ago
  Oh you're not alone. I dislike Java as well, but there's no denying the power of the JVM and the ecosystem around it. If you really dig into it and look at it as a polyglot platform with choices like Groovy, Clojure, JRuby, and Scala, it becomes more palatable. Regardless this post is not about .NET tooling, more about server efficiency and cost. Two areas where I think the JVM is a little further ahead.

sljd 13y ago

Well, AFAIK he can easily switch to MySQL for instance, under the same ORM.

hapless 13y ago
MySQL is possibly the single hardest database to port to/from, because it supports nothing.
- twistedpair 13y ago
  In that case porting FROM it should be simple. TO it would be hard if you're using all those fancy features of your current DB. That's why I eschew all the sirens from Oracle DBA's of "oh... but Oracle can do that too!" Keep database activities in the database and application activities in the app.
  - regularfry 13y ago
    In my experience, MySQL lets you get into a state where questions like "hang, on - what's the difference between a DATE of '0000-00-00' and NULL?" are commonplace. This makes porting from it... not simple.
    - deleted 13y ago
      [deleted]
    - sljd 13y ago
      Although I have no experience with MySQL, this kind of problems have to be resolved by using LINQ to SQL since every db type is automatically mapped to its .NET counterpart. The DateTime .NET type then has only one representation of null.
    - sljd 13y ago
      Or what you're saying is that if you store a date of zero VALUE to MySQL it could be magically replaced by NULL internally? That would be really crazy.
      - hapless 13y ago
        I seem to recall it is actually the other way around, and storing a null results in a nonsense date. Added bonus: some versions will segfault if you pass an un-formattable date value.
  - hapless 13y ago
    The problem is that MySQL deviates from the standards (all of them) in surprising and uncomfortable ways. porting from MySQL is fun, when, for example, your target database actually ENFORCES the constraints that MySQL accepted but silently ignored. MySQL doesn't have that feature, but it won't bother to tell you. Postgres, Oracle, MS SQL all support a (very large) common subset of features, so if you avoid stored procedures and db-specific features, you can port among them easily. This is not true for MySQL.

pmelendez 13y ago

>"I agree, he could easily be using a JVM-based stack" Maybe but believe it or not, there are people who HATE Java (that would includes me)

obviouslygreen 13y ago
I'm not a huge fan of Java either, but sometimes it's important to get past that and either try and work with a language that's extremely effective for some deployments, or consider that the JVM supports quite a bit more platforms than just Java.
city41 13y ago
There's always Scala, clojure, groovy, etc.
hkarthik 13y ago
Oh you're not alone. I dislike Java as well, but there's no denying the power of the JVM and the ecosystem around it. If you really dig into it and look at it as a polyglot platform with choices like Groovy, Clojure, JRuby, and Scala, it becomes more palatable. Regardless this post is not about .NET tooling, more about server efficiency and cost. Two areas where I think the JVM is a little further ahead.