3 ms·

Since no one else seems to be doing so, let me put in a plug for MSSQL. If you're using the Microsoft stack, it ought to be the default choice. The integration

by stuki 19y ago

Since no one else seems to be doing so, let me put in a plug for MSSQL. If you're using the Microsoft stack, it ought to be the default choice. The integration with the rest of the environment (LINQ, db process LCR, Visual Studio integration, async transactional queuing, one heck of a molap engine, a great etl tool and more) is just too good to give up. And it's a darned nice database to boot, with 2008 on the way being even nicer. Also, Microsoft has publicly assured customers they will continue to license per socket, not per core. While still more expensive than the free db's (duh), at least you're not stuck handing over all future Moore's law gains to Larry Ellison.

mpc 19y ago
Hand over those gains to Steve Ballmer instead? I use .net and mssql at work and will admit that the tooling around ms products is superb. However, I really don't know what we pay to deploy on it. A lot more than a mysql deployment I am sure.
- stuki 19y ago
  The point I was trying to make is that since processors now almost exclusively gain performance by adding cores rather than by speeding up each individual core, a per socket license lets the customer continue to keep the gains from processor evolution. With Oracle's per core license, if you swap out your dual cores for quads, you owe twice (or thereabouts) as much in license fees, essentially guaranteeing your (some processor performance metric) / (license fee) ratio no longer increases over time.
  - mpc 19y ago
    OK, I see your point now. What case can you make for choosing a commercial product over MySQL when it's just as good? (but lacks tooling)
    - stuki 19y ago
      Tooling and integration are definitely major points. I guess any time you get the whole app stack from a single vendor; you're likely to get a more integrated product (os/400, db2, RPG and green screens; ...maybe not.....:)), while at the same time forfeiting opportunity to pick the individual components that suits you the best. You're obviously more dependent on developments at your vendor as well. So if you believe MS is dying, you should probably choose another database. Considering Word's dictionary includes RPG, yet neither Postgres nor MySQL, that belief might not even be that farfetched:). Now, for what I am trying to do, easy access to a proven distributed transaction infrastructure is non negotiable. MS provides this. So does Oracle, and certainly IBM. The Java world provides this in spades as well, but I'm not sure how nicely the popular open source db's play along. Last time I looked at Postgres, this seemed at best a medium priority work in progress. Since it doesn't take too many systems left in disagreement about the status of a million dollar transfer to annoy the heck out of some people, in this case I'd rather stick with one of the known entities. For somewhat similar reasons, I prefer MSSQL's ability to replicate in synchronous mode over the asynchronous / possibly lossy replication that MySQL ships with (.net client auto failover is a nice added bonus). I believe there are add on products for MySQL and Postgres to accomplish the same, but that they are neither free nor used, developed and tested as widely as MS' version. In addition, MSSQL comes with non rdbms features that Postgres/MySQL lacks. Some of these may have Unix/Linux/open source, or at least Java, competitors/equivalents, but since I intend to use several of them, combined they add a lot of value to Sql Server. For example, a pet peeve of mine is that the root of at least some evil is doing synchronously that which could be done asynchronously (obviously not db replication:)). Since my app is financial enough to 'require' strong transactional support, Service Broker asynchronous transactional message queues alone might have been enough to sell me on Sql Server. I'm also assuming many end users will be Excel jockeys. Hence, giving them access to slice and dice 'their' data in Analysis Services cubes (still trying to wrap my head around the security implications of this one), and integrate said cubes into their own worksheets, instead of just providing canned reports, looks advantageous. Less work on my part as well:). And, although I have written my share of database transfer and replication scripts in Perl and Python, the latest SSIS seems a better tool for that purpose. I'm assuming I need to generate reports involving data from multiple outside systems. Damn, this ended up being a long post. Hopefully some will find it valuable. If nothing else, the pills I popped are finally winning the war against my Saturday 'morning' hangover:).

by stuki 19y ago

mpc 19y ago

Hand over those gains to Steve Ballmer instead? I use .net and mssql at work and will admit that the tooling around ms products is superb. However, I really don't know what we pay to deploy on it. A lot more than a mysql deployment I am sure.

stuki 19y ago
The point I was trying to make is that since processors now almost exclusively gain performance by adding cores rather than by speeding up each individual core, a per socket license lets the customer continue to keep the gains from processor evolution. With Oracle's per core license, if you swap out your dual cores for quads, you owe twice (or thereabouts) as much in license fees, essentially guaranteeing your (some processor performance metric) / (license fee) ratio no longer increases over time.
- mpc 19y ago
  OK, I see your point now. What case can you make for choosing a commercial product over MySQL when it's just as good? (but lacks tooling)
  - stuki 19y ago
    Tooling and integration are definitely major points. I guess any time you get the whole app stack from a single vendor; you're likely to get a more integrated product (os/400, db2, RPG and green screens; ...maybe not.....:)), while at the same time forfeiting opportunity to pick the individual components that suits you the best. You're obviously more dependent on developments at your vendor as well. So if you believe MS is dying, you should probably choose another database. Considering Word's dictionary includes RPG, yet neither Postgres nor MySQL, that belief might not even be that farfetched:). Now, for what I am trying to do, easy access to a proven distributed transaction infrastructure is non negotiable. MS provides this. So does Oracle, and certainly IBM. The Java world provides this in spades as well, but I'm not sure how nicely the popular open source db's play along. Last time I looked at Postgres, this seemed at best a medium priority work in progress. Since it doesn't take too many systems left in disagreement about the status of a million dollar transfer to annoy the heck out of some people, in this case I'd rather stick with one of the known entities. For somewhat similar reasons, I prefer MSSQL's ability to replicate in synchronous mode over the asynchronous / possibly lossy replication that MySQL ships with (.net client auto failover is a nice added bonus). I believe there are add on products for MySQL and Postgres to accomplish the same, but that they are neither free nor used, developed and tested as widely as MS' version. In addition, MSSQL comes with non rdbms features that Postgres/MySQL lacks. Some of these may have Unix/Linux/open source, or at least Java, competitors/equivalents, but since I intend to use several of them, combined they add a lot of value to Sql Server. For example, a pet peeve of mine is that the root of at least some evil is doing synchronously that which could be done asynchronously (obviously not db replication:)). Since my app is financial enough to 'require' strong transactional support, Service Broker asynchronous transactional message queues alone might have been enough to sell me on Sql Server. I'm also assuming many end users will be Excel jockeys. Hence, giving them access to slice and dice 'their' data in Analysis Services cubes (still trying to wrap my head around the security implications of this one), and integrate said cubes into their own worksheets, instead of just providing canned reports, looks advantageous. Less work on my part as well:). And, although I have written my share of database transfer and replication scripts in Perl and Python, the latest SSIS seems a better tool for that purpose. I'm assuming I need to generate reports involving data from multiple outside systems. Damn, this ended up being a long post. Hopefully some will find it valuable. If nothing else, the pills I popped are finally winning the war against my Saturday 'morning' hangover:).