Slashdot Mirror
MSSQL 2005 Finally Released
mnovotny writes "Computerworld reports that Microsoft is finally set to release their belated SQL Server 2005. From the article: 'Despite a two-year delay, several users who have tested the software cited the improved performance and new functionality it brings as positive developments that likely will convince them to upgrade soon.' The free version can be downloaded directly from Microsoft."
Microsoft has a serious Beta Testing problem. Partially due to the fact there is little incentive for the Beta Testers to release the bugs, and Microsoft arrogance. Beta Testers should should be rewarded with their work with free copies of the final version, plus they shouldn't have to pay Microsoft for the honor of Beta Testing. Most of the Beta Testers I have seen are people who just want to learn the tool before it is released to the public so they get those jobs that are just popping up asking for people with 2 years of MS SQL 2005 experience.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
Yes, if by "free" you mean "free to use for one year":
That "for the term of that license" sounds like a loophole to me. Anyone seen the licenses that these "free" versions come with? Do they have a time period written into them?
Read my blog.
great. Microsoft to deprecate t-sql for C# stored procedures. As a bonus they encourage you to not write orr understand SQL at all, well visual studio writes it for you. Well guess what, they want to obscure and redefine what a database is and what it is supposed to be. t-sql is a great language, queries are first class and it is designed from top to bottom to perform quickly and well.
What problem are they trying to solve...I'll tell you what. SQL works well and is defiened by a standards committe outside their control...why don't we all do everything in vb instead. I betcha one of the reasons it took so long to get out was they couldn't make it run anywhere as fast as 2000 without tons of tweaking.
"Stored procedures" written in C# should really be thought of in the same way as the extended procedures from SQL Server 2000. In otherwords, you probably will never use that feature, and if you do find that you need it you must really scrutinize why and the security implications of doing so. In most cases, you're better off with straight T-SQL procedures, and that hasn't changed for SQL Server 2005.
Personally, I haven't yet found a good reason to use C# stored procedures, but I'm also not using SQL Server 2005 yet. When my team migrates in the coming months, I might change my tune, but for now I'm more interested in other feature enhancements like try/catch error handling semantics and the snapshot isolation levels (allows for better concurrency without having to risk dirty reads by using (nolock) or setting a "read uncommitted" isolation level).
Do you have examples of procedures gone horribly wrong? Preferably not something completely obvious, like a proc that takes a varchar(8000) as input and just passes that to exec (completely stupid, negates all of the benefits of using stored procs). From my experience, you're better off using stored procedures than dynamic SQL in your code, so long as a few sanity check requirements are in place -- limit the amount of dynamic SQL in your procedures, prefer table variables over temp tables (to prevent recompilations), and general T-SQL best practices: limit your use of cursors and looping since SQL is a set-based language, keep your transactions as short as possible, avoid forcing index hints, count() on an indexed column or better yet * (allows the plan engine to pick the best column to count on), etc.
Depends on what you mean by "application logic". If you meant to say "business logic", then I must vehemently disagree -- business logic should live close to the data, in a reusable form so it need not be implemented in each app that wants to use the data. Ideally that means stored procedures. If you can't implement your business logic in T-SQL, then you need to re-think your logic requirements and your schema. If it still can't be done, then you can go ahead and start moving it into external libraries, but you should try your best to keep your logic as close to your data as possible.
Where were you pricing this? Some VAR that was trying to rape you?
I mean out of the box for server 2000 pricing last time I checked with a source of mine(3 years ago)(just checked an old email) and had a quote for 16k a cpu. And street price from Microsoft at the time direct was 20k per cpu.
Hell, even the new 2005 is only 24k per proc from MS on their site, and I am sure Tech Data, or some other company could get them two you cheaper. Whoever you were dealing with was charging you double.
So either this is FUD or just a rip off vendor.
Our shop supports MS, Oracle, DB2, and postgres. And you can move freely between any of those from one to the other, no vendor lock in.
Vendor lock in is when you use specific functionality inherent to MSSQl(or db2, oracle, post) so that if you need to move from one to the other, that is the guy who built the databases fault, not the company that supplies it.
Puto
The Revolution Will Not Be Televised
The persistence layer is nice for separating the logic in the app, but it doesn't mean you have to sacrifice the database server's built-in power & functionality. Persistence layers can map to stored procedures, views, etc.
Also, like the man says, sometimes there's other types of apps connecting to your DB, maybe not all within your control. If you're responsible for the health of the data and the system, you may not be able to trust that every developer or system is playing nice.
TODO: come up with a clever sig