The MPP architecture helps enable better scalability, better and more predictable performance, reduced risk and a lower cost per terabyte than other DW solutions.

A Madison MPP appliance acts as an enterprise “hub” that publishes data as needed to various business units or departments (spokes). For dedicated high performance requirements, individual business units can redeploy SQL Server 2008 data marts, or
deploy their own Madison appliances, as spokes.

I'm type 1. I can do the following:
- Connect to the database
- Standard basic queries

That's pretty much it. But it is certainly a cause for concern as far as my skill set goes. I just haven't decided what route I want to take in order to increase my SQL knowledge without doing it on-the-job. Anyone know a good resource to help self-teach
SQL? Like a *cough* free *cough* course with exercises and some tips thrown in?

I'm type 1. I can do the following:
- Connect to the database
- Standard basic queries

That's pretty much it. But it is certainly a cause for concern as far as my skill set goes. I just haven't decided what route I want to take in order to increase my SQL knowledge without doing it on-the-job. Anyone know a good resource to help self-teach
SQL? Like a *cough* free *cough* course with exercises and some tips thrown in?

Writing highly efficient T-SQL code in scalable environment, and understanding what goes into type of code, has been one of the bigger challenges that I've enjoyed taking on in my humble developement career.
In many interviews that I've held to hire these type of people, you'd be surprised how few candidates really know their stuff in this regard.

I am definitely a type 2 developer, though my current job is more based around WPF and components. We are using WPF for example, but the UI is the basic Aero one, and I don't think that will be changed.

The problem with Linq to SQL and Entity Framework, is that they are just higher abstractions that generate T-SQL anyway. The reason most people struggle with T-SQL is because it is a pure functional language. The forthcoming EF will have a feature that allows
you to define a class, and then an option that says "generate database" that creates all the SQL for you. I just don't get why one would want to waste time learning Linq to SQL when you can open up SQL Sever Management Studio and compose you queries and SPROCS
there

I am definitely a type 2 developer, though my current job is more based around WPF and components. We are using WPF for example, but the UI is the basic Aero one, and I don't think that will be changed.

The problem with Linq to SQL and Entity Framework, is that they are just higher abstractions that generate T-SQL anyway. The reason most people struggle with T-SQL is because it is a pure functional language. The forthcoming EF will have a feature that allows
you to define a class, and then an option that says "generate database" that creates all the SQL for you. I just don't get why one would want to waste time learning Linq to SQL when you can open up SQL Sever Management Studio and compose you queries and SPROCS
there

The Type 1 developers I have known can do perfectly well with the basic CRUD T-SQL and the basics of aggregating for summary reports. The stuff we have problems with are complex logic that you wouldn't use an ORM wrapper for anyway: like the calculation
and posting of an annual invoice for rental agreements (for each account, find out how much they owe, and how many discounts offers they have allocated but not taken this year, generate the journal postings to the rent ledger, splitting out any separate parts
to different nominal codes in the accounting system, reverse calculating and splitting out the VAT components as well and then post to the master-detail ledger tables).

This is complex logic that (in C#) takes several hundred lines of code. A Type 2 developer converted the whole thing to T-SQL (again several hundred lines of code but somewhat fewer than the C#). Testing was a nightmare (our customers run SQL2000, so we
have to run SQL2000 - no step through debugging of stored procs), but the final result is significantly faster. I would have (probably) been able to write a storec proc for this but it would have taken me weeks, instead of days that the Type 2 took.

I am definitely a type 2 developer, though my current job is more based around WPF and components. We are using WPF for example, but the UI is the basic Aero one, and I don't think that will be changed.

The problem with Linq to SQL and Entity Framework, is that they are just higher abstractions that generate T-SQL anyway. The reason most people struggle with T-SQL is because it is a pure functional language. The forthcoming EF will have a feature that allows
you to define a class, and then an option that says "generate database" that creates all the SQL for you. I just don't get why one would want to waste time learning Linq to SQL when you can open up SQL Sever Management Studio and compose you queries and SPROCS
there

I agree I stuggled with why you would want to learn LINQ - I don't get it either, is there something I've missed?

The Entity Framework in .Net 4.0 is going to be a design time tool to help with Class and Schema design, so I believe. So it's actually going to be a good thing, however I not sure if it offers anything new we haven't seen before with things like
Rational Software Modeller and
ORM tools other than being included with Visual Studio and not having to pay extra for it.

I agree I stuggled with why you would want to learn LINQ - I don't get it either, is there something I've missed?

The Entity Framework in .Net 4.0 is going to be a design time tool to help with Class and Schema design, so I believe. So it's actually going to be a good thing, however I not sure if it offers anything new we haven't seen before with things like
Rational Software Modeller and
ORM tools other than being included with Visual Studio and not having to pay extra for it.

LINQ to Objects is foresightful if you use PLINQ in .NET 4.0 and beyond to parallelize your LINQ queries across multiple cores on a machine.

Then there's DryadLINQ, which would enable you to distribute your LINQ to Objects queries across multiple machines.

Combining both PLINQ and DryadLINQ would enable developers to parallelize LINQ to Objects queries massively. (number of cores per PC) x (number of PCs per compute cluster) = profit!

Scientific and other high-performance computing could become .NET's next killer applications.

It is only specific scenarios that will benefit client machines, especially like the ones you have just mentioned, and I don't see Windows 7's main customer base being scientific or high performance gamers. What will my mum use a quad core for? Nothing!

The vast majority of applications don't really need to utilise many-core, but unzipping files, encoding video, heavy mathematical calculations are more the exception than the rule on most machines. With SQL being a more functional language, it stands
to reason that parallel database support will benefit client machines so SQL trumps again rather than the meltdown your servers have when a Windows beta or RC is released

It is only specific scenarios that will benefit client machines, especially like the ones you have just mentioned, and I don't see Windows 7's main customer base being scientific or high performance gamers. What will my mum use a quad core for? Nothing!

The vast majority of applications don't really need to utilise many-core, but unzipping files, encoding video, heavy mathematical calculations are more the exception than the rule on most machines. With SQL being a more functional language, it stands
to reason that parallel database support will benefit client machines so SQL trumps again rather than the meltdown your servers have when a Windows beta or RC is released

The vast majority of applications just use SQL as a data store, and only do CRUD.

This is a serious question. If I am writing an application, why exactly would I spend thousands of dollars on a database when there are databases that are free of charge (MySQL, PostgresSQL), and also SQL-99 compliant?

The vast majority of applications just use SQL as a data store, and only do CRUD.

Granted Bazza but doesn't mean it's right!

Information is many an organisations most important asset. What happens to that data and how change happens is becoming of upmost importance to business even in the smallest, most unimportant system because if it's adding value everyday it certainly not
something you would want to do without and search for opportunities to greater leverage what you have.

At the very least developers should not only look at good CRUD but how they can plug the database into a company wide SOA and also the BI platform.

This is a serious question. If I am writing an application, why exactly would I spend thousands of dollars on a database when there are databases that are free of charge (MySQL, PostgresSQL), and also SQL-99 compliant?

"This is a serious question. If I am writing an application, why exactly would I spend thousands of dollars on a database when there are databases that are free of charge (MySQL, PostgresSQL), and also SQL-99 compliant?"

One of the serious weaknesses of the Open Source movement was to only recognise the need to reduce CAPEX (Capital Expenditure - tangabile stuff like hardware and software) when OPEX (Operational Expenditure) was the real thing that most businesses spend
the most money on ....... by far!

... and Open Source would want you to increase OPEX because you would need to have more and/or a change of skills and then want to give away the fruits of their labour ... and that could benefit a competitor. This doesn't make business sense.

Up until recently MySQL and PostgresSQL haven't been anywhere near as easy to manage or have such vast control as Oracle ... let alone SQL Server where hunderds of databases are managed by only afew people ... and these people get to go home at night.

So look at this from a business context. Would you spend out a little CAPEX (in comparison) in a reduced risk way to bring down OPEX? Or have no CAPEX but increase your OPEX in a way that has risk.

Now do you get why Open Source has to be easy and less risk before the moral high ground not because of it.

And why moan about companies that write close source software they are selling to a vast majority of companies that are just like themselves in business to make money.

I am definitely a type 2 developer, though my current job is more based around WPF and components. We are using WPF for example, but the UI is the basic Aero one, and I don't think that will be changed.

The problem with Linq to SQL and Entity Framework, is that they are just higher abstractions that generate T-SQL anyway. The reason most people struggle with T-SQL is because it is a pure functional language. The forthcoming EF will have a feature that allows
you to define a class, and then an option that says "generate database" that creates all the SQL for you. I just don't get why one would want to waste time learning Linq to SQL when you can open up SQL Sever Management Studio and compose you queries and SPROCS
there

Simply because the LINQ query EDSL gives you a cleaner, more flexible, more composable
programming model.