There always seems to be a buzz around .Net or UI stuff but I don't get the impression that there is the same feeling with SQL Server stuff.

I get this impression because when I talk to developers they aren't really interested to talk about the new stuff in 2008 and what is coming in 2008 R2, it's all abit mehhh ...

... which is the same feeling I get when I look at the stuff they've made in SQL it literally is CRUD and never very good at that.

So tell me if I'm right ... or that I'm talking utter tosh!

I would love to know so I can work out how to get them interest so I can get better written databases because they work but not as good as they could do, but these same guys produce some amazing .Net.

Thanks!

I love the 08 T-SQL enhancements like CTEs, windowing functions, pivoting, better xml support, new data types, and geometry constructs.  Although the geometry constructs feel rather half baked.

So, from my perspective, you're talking utter tosh.

-Josh

I definitely understand what you're saying though. My boss uses Toad for everything even if it means many more steps than writing a simple update statement. She's just not interested in learning the queries.

As far as new features go, coming from the Oracle side of things, these features are almost always geared towards the DBA and not the developer, so I tend not to pay too much attention.

spivonious said:

I thought the whole point of Linq-to-SQL and Entity Framework was to take the SQL out of development?

I definitely understand what you're saying though. My boss uses Toad for everything even if it means many more steps than writing a simple update statement. She's just not interested in learning the queries.

As far as new features go, coming from the Oracle side of things, these features are almost always geared towards the DBA and not the developer, so I tend not to pay too much attention.

I have found there are generally two types of developers (with respect to databases):

1. Developers who started writing applications and discovered databases were a useful place to store data. (I am this type).
2. Database admins who discovered that they could code up a better UI for their database.

Type 1 developers tend not to see database as anything other than a data store and these are the devs who tend not to be interested in new SQL developments. They are also the majority of developers

Type 2 devs tend to want all the logic in stored procedures, while Type 1 want it all in code.

The other issue is that Type 1 developers tend not to be so good at SQL.  I can string a complex SQL statement together, but it's a struggle and they tend not to be performant.  SQL takes a different kind of thinking than OOP and I'm just not there yet.

We briefly had a Type 2 developer at our company (he mistakenly thought he was going to be included in redundancies and got another job before we told him we wanted to keep him), and he did things like rewriting an old stored proc that took 3min 45 seconds to a version that took 15 seconds.  Useful guys, Type 2s.

Herbie

Dr Herbie said:

spivonious said:

*snip*

I have found there are generally two types of developers (with respect to databases):

1. Developers who started writing applications and discovered databases were a useful place to store data. (I am this type).
2. Database admins who discovered that they could code up a better UI for their database.

Type 1 developers tend not to see database as anything other than a data store and these are the devs who tend not to be interested in new SQL developments. They are also the majority of developers

Type 2 devs tend to want all the logic in stored procedures, while Type 1 want it all in code.

The other issue is that Type 1 developers tend not to be so good at SQL.  I can string a complex SQL statement together, but it's a struggle and they tend not to be performant.  SQL takes a different kind of thinking than OOP and I'm just not there yet.

We briefly had a Type 2 developer at our company (he mistakenly thought he was going to be included in redundancies and got another job before we told him we wanted to keep him), and he did things like rewriting an old stored proc that took 3min 45 seconds to a version that took 15 seconds.  Useful guys, Type 2s.

Herbie

I agree, although I'd describe myself as "Type 1.5"

If it makes sense to put in a stored procedure (e.g. some common function that lots of programs are going to use), it's going in the database. If it's something specific to my app, then it's going in code.

Maybe it's because I took a database course in college that was all T-SQL.

Type 1 = Front Office Developer?

Type 2 = Back Office Developer?

Funny as your comments make me think about what has happened to 3 tier development thinking? So the  1.5 guy still the Business Logic guy? So really three types?

Also what happened to working out where is the best place to execute code? i.e. field data validation in the UI? lots of row update is better in the database?

Geez I know about customers/business still wanting to stay on SQL Server 2000, explaining what 'out of support' means and using 'risk to the business' kind of turns that thinking around PDQ.

I know that some still don't get it even after using phrases like 'strongly advise' ... then you really are down to the '10 year old unserviced car which you business data is sitting in' analogy ... then you know you're onto a losser if they don't get it after that  ... and then it's a chat to the CEO that's needed. If you're still stuffed you know your not dealing with 'bright bunnies' that don't take IT (i.e. the tool that helps business 'do' business) seriously. So my advice would be to get the hell out of there cos it's gonna be luck or unshrinking market share that's gonna keep them in business ... and not much else.

Bass said:

I hate CRUD development. I hate "business logic", or LOB apps, or basically anything "enterpriseish". Precisely because it isn't interesting... to me at least. Anything highly mathematical, involving neural nets, hidden markov models or genetic algorithms is what I like to code. Hell, I'll work on a team that codes a RDBMS, but f**k if I ever making a living solely coding against one.

Have use used the SQL Analysis Services?  If you have some time, get the evaluation copy and try using the Excel Datamining Add-in to get started with seeing what you can put in and spit out.  When you get your head wrapped around that, you should be able to program against it or at least have a better understanding of what kind of problems can be solved with this class of tool.

Dr Herbie said:

spivonious said:

*snip*

I have found there are generally two types of developers (with respect to databases):

1. Developers who started writing applications and discovered databases were a useful place to store data. (I am this type).
2. Database admins who discovered that they could code up a better UI for their database.

Type 1 developers tend not to see database as anything other than a data store and these are the devs who tend not to be interested in new SQL developments. They are also the majority of developers

Type 2 devs tend to want all the logic in stored procedures, while Type 1 want it all in code.

The other issue is that Type 1 developers tend not to be so good at SQL.  I can string a complex SQL statement together, but it's a struggle and they tend not to be performant.  SQL takes a different kind of thinking than OOP and I'm just not there yet.

We briefly had a Type 2 developer at our company (he mistakenly thought he was going to be included in redundancies and got another job before we told him we wanted to keep him), and he did things like rewriting an old stored proc that took 3min 45 seconds to a version that took 15 seconds.  Useful guys, Type 2s.

Herbie

I guess I am type 3 or is that 4 ??

I did start with coding apps, learned about data and sql.

spent a lot of time doing DBA things and Dev things....

to me it's a ballance - a Yin / Yang thing.

I love the things I can do in C# and I love the things i can do in T-SQL each has a place in my work.

figuerres said:

Dr Herbie said:

*snip*

I guess I am type 3 or is that 4 ??

I did start with coding apps, learned about data and sql.

spent a lot of time doing DBA things and Dev things....

to me it's a ballance - a Yin / Yang thing.

I love the things I can do in C# and I love the things i can do in T-SQL each has a place in my work.

DITTO

Red5 said:

figuerres said:

*snip*

DITTO

I think experience makes a developer a 'type 3' (that's type 1 plus type 2 ).

I'd consider myself perhaps a 2.5 : I know how to architect a good solution, but I'm just not an SQL guru (yet) so the database tier is my weak point. I'm not a solo developer so there are a couple of devs who can help out there, but we do seem to be lacking an SQL superstar at the moment to balance the team out.

Herbie

spivonious said:

Dr Herbie said:

*snip*

I agree, although I'd describe myself as "Type 1.5"

If it makes sense to put in a stored procedure (e.g. some common function that lots of programs are going to use), it's going in the database. If it's something specific to my app, then it's going in code.

Maybe it's because I took a database course in college that was all T-SQL.

>I agree, although I'd describe myself as "Type 1.5"

how would you store a double in an integer? and if your thinking on doing a enum I'll give you a bool

JoshRoss said:

Bass said:

*snip*

Have use used the SQL Analysis Services?  If you have some time, get the evaluation copy and try using the Excel Datamining Add-in to get started with seeing what you can put in and spit out.  When you get your head wrapped around that, you should be able to program against it or at least have a better understanding of what kind of problems can be solved with this class of tool.

If you like the Excel link to Analysis Service you are going to LOVE Project Gemini that will come in SQL Server 2008 R2

http://blogs.msdn.com/sqlcat/archive/2008/10/06/project-gemini-building-models-and-analysing-data-from-excel.aspx

 ... and if you want to have a very brief high level overview of what coming in SQL Server 2008 R2 ....

Yes it is a Yin/Yang thing, you do have to put code into the right place and working out that balancing act does take knowledge either built up by experience or from the many good educational materials, books and webcasts (most of them free from Microsoft!)

I would have to stab myself in the head if I did UI stuff all day ... now that is boring! Programming all that validation, working out the next scenario where a user can be stupid, not interesting at all

On a serious note, I did enjoy UI coding but I don't have the temperment for it.

So you get the big no-no's in SQL Server right? Like Select * is bad?

You get why getting the right 'Collations' is very important? ... and which ones have been deprecated?

Why DBA's don't like LINQ? ... it's all about the Query Plan Baby!

Why the new MERGE command is very cool? ... well get's you into the pub early.

... and not to mention the game changers coming in SQL Server 2008 R2 !

Geeeez I could talk all day, I will pull out some of my favourite Microsoft webcasts for you to watch.

Sabot said:

The thing is if SQL Server is somewhere in your development stack you've gotta get to know it well because it's could so eaily add lead boots to your projects.

Yes it is a Yin/Yang thing, you do have to put code into the right place and working out that balancing act does take knowledge either built up by experience or from the many good educational materials, books and webcasts (most of them free from Microsoft!)

I would have to stab myself in the head if I did UI stuff all day ... now that is boring! Programming all that validation, working out the next scenario where a user can be stupid, not interesting at all

On a serious note, I did enjoy UI coding but I don't have the temperment for it.

So you get the big no-no's in SQL Server right? Like Select * is bad?

You get why getting the right 'Collations' is very important? ... and which ones have been deprecated?

Why DBA's don't like LINQ? ... it's all about the Query Plan Baby!

Why the new MERGE command is very cool? ... well get's you into the pub early.

... and not to mention the game changers coming in SQL Server 2008 R2 !

Geeeez I could talk all day, I will pull out some of my favourite Microsoft webcasts for you to watch.

Was SQL ever interesting? I think it has to be one of the dullest things in the whole wide world.

Sabot said:

The thing is if SQL Server is somewhere in your development stack you've gotta get to know it well because it's could so eaily add lead boots to your projects.

Yes it is a Yin/Yang thing, you do have to put code into the right place and working out that balancing act does take knowledge either built up by experience or from the many good educational materials, books and webcasts (most of them free from Microsoft!)

I would have to stab myself in the head if I did UI stuff all day ... now that is boring! Programming all that validation, working out the next scenario where a user can be stupid, not interesting at all

On a serious note, I did enjoy UI coding but I don't have the temperment for it.

So you get the big no-no's in SQL Server right? Like Select * is bad?

You get why getting the right 'Collations' is very important? ... and which ones have been deprecated?

Why DBA's don't like LINQ? ... it's all about the Query Plan Baby!

Why the new MERGE command is very cool? ... well get's you into the pub early.

... and not to mention the game changers coming in SQL Server 2008 R2 !

Geeeez I could talk all day, I will pull out some of my favourite Microsoft webcasts for you to watch.

MERGE is perhaps the greatest addition to SQL of all time.

Ion Todirel - I didn't know it was an integer... I guess my type got truncated to Type 1.

spivonious said:

Sabot said:

*snip*

MERGE is perhaps the greatest addition to SQL of all time.

Ion Todirel - I didn't know it was an integer... I guess my type got truncated to Type 1.

http://www.eveonline.com/devblog.asp?a=blog&bid=663

Eve Online is about to move it's SQL back-end from SQL 2005 to SQL 2008, I think 64 bit. Will have to see if it makes the game any quicker and stops any lag

littleguru said:

SQL and SQL Server are tools... they are working fine and there's not THAT much innovation going on recently. That's probably why...

Ok, so SQL Server isn't  as 'Rockstar' as Silverlight but the innovations really don't get any ....

BIGGER!

Let me give you a couple of examples, this one quoted straight from the 2008 R2 website,

• Combines native Excel 2010 functionality with an in-memory, column oriented processing engine to allow users to interactively explore and perform calculations on millions of rows of data at lightening speeds

How many CPU's?

• Increase in the number of logical processors supported from 64 up to 256.  This will provide customers with more choices for obtaining single system scalability with high performance.

Scale Your Data Warehouse from Terabytes to Petabytes (website for more info is here)

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.

See! SQL Server is sub-zero cool!

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?

ManipUni said:

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?

 

Manip I'm like your Fairy-God-Father today! So I will grant your wish for free SQL Server training !!!!

Lots of webcasts and Virtual Labs : http://www.microsoft.com/events/series/technetsqlserver2008.aspx?tab=overview

 .... or better still download the  ... THE SQL SERVER DEVELOPER TRAINING TOOLKIT

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=e9c68e1b-1e0e-4299-b498-6ab3ca72a6d7

... the toolkit takes on the road from being a Type 1 to a Type 2!

Sabot said:

ManipUni said:

*snip*

Manip I'm like your Fairy-God-Father today! So I will grant your wish for free SQL Server training !!!!

Lots of webcasts and Virtual Labs : http://www.microsoft.com/events/series/technetsqlserver2008.aspx?tab=overview

 .... or better still download the  ... THE SQL SERVER DEVELOPER TRAINING TOOLKIT

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=e9c68e1b-1e0e-4299-b498-6ab3ca72a6d7

 

... the toolkit takes on the road from being a Type 1 to a Type 2!

Indeed you are sir. Thanks <3

Sabot said:

ManipUni said:

*snip*

Manip I'm like your Fairy-God-Father today! So I will grant your wish for free SQL Server training !!!!

Lots of webcasts and Virtual Labs : http://www.microsoft.com/events/series/technetsqlserver2008.aspx?tab=overview

 .... or better still download the  ... THE SQL SERVER DEVELOPER TRAINING TOOLKIT

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=e9c68e1b-1e0e-4299-b498-6ab3ca72a6d7

 

... the toolkit takes on the road from being a Type 1 to a Type 2!

I haven't looked through the training material. However, I find most training docs rather drab.  Have you solved any of Itzik Ben-gan's puzzles? He publishes some good ones! 

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

vesuvius said:

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.

Herbie

vesuvius said:

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.

However the 'Daddy' is going to be Microsoft Project Oslo in this space .... however it won't be if it costs too much, the best thing to do is bundle it in with Visual Studio Architecture Edition or a value add to an additional product .

Sabot said:

vesuvius said:

*snip*

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.

However the 'Daddy' is going to be Microsoft Project Oslo in this space .... however it won't be if it costs too much, the best thing to do is bundle it in with Visual Studio Architecture Edition or a value add to an additional product .

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.

joechung said:

Sabot said:

*snip*

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

vesuvius said:

joechung said:

*snip*

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.

Increasing productivity and expressiveness, increasing knowledge fidelity and queryability, like expressing *everything* as structured data, even {U,I}RI addresses, that's what interests me.

http://www.linqpad.net/WhyLINQBeatsSQL.aspx

blowdart said:

vesuvius said:

*snip*

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.

Bass said:

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.

vesuvius said:

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.

(or: "what exoteric linked")

Bass said:

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?

Bass said:

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?

contextfree said:

vesuvius said:

*snip*

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

(or: "what exoteric linked")

OK, so up until now I haven't exactly got my head around LINQ but digging into it I'm actually beginning to get it.

Blog articles like this have really helped ...

http://bloggingabout.net/blogs/dennis/archive/2007/12/28/linq-to-sql-vs-dba-s.aspx

From what I'm getting is that LINQ is not just an abstraction on top of SQL but it allows logic to sit in a more appropriate place that sitting in a long piece of spaghetti in a stored procedure which makes good architectural sense.

My main concern is the loss of performance but I do get that this may not be the case with LINQ, take Fran Bouma's point of view, he lives without Stored Procedures and is love it! ...

http://weblogs.asp.net/fbouma/archive/2003/11/18/38178.aspx

Anyway there is enough here to convince me to get my head around LINQ and tryout some stuff for myself.

AndyC said:

Bass said:

*snip*

Put them under a large enough strain and the weaknesses in them compared to the big players become all to obvious. That's not to say they aren't getting better however and, personally speaking, I'd use either of them over DB2 any day.

DB2 isn't bad as long as your organisation is using a recent version.

Sabot said:

contextfree said:

*snip*

OK, so up until now I haven't exactly got my head around LINQ but digging into it I'm actually beginning to get it.

Blog articles like this have really helped ...

http://bloggingabout.net/blogs/dennis/archive/2007/12/28/linq-to-sql-vs-dba-s.aspx

From what I'm getting is that LINQ is not just an abstraction on top of SQL but it allows logic to sit in a more appropriate place that sitting in a long piece of spaghetti in a stored procedure which makes good architectural sense.

My main concern is the loss of performance but I do get that this may not be the case with LINQ, take Fran Bouma's point of view, he lives without Stored Procedures and is love it! ...

http://weblogs.asp.net/fbouma/archive/2003/11/18/38178.aspx

Anyway there is enough here to convince me to get my head around LINQ and tryout some stuff for myself.

If you're concerned about loss of performance than really any ORM is out, if you believe stored procedures are the fastest option (which isn't true in some cases). But if you really care about performance then avoid the Entity Framework as it stands right now.

Sabot said:

AndyC said:

*snip*

DB2 isn't bad as long as your organisation is using a recent version.

You should see how long it stands up when faced with our students "interesting" SQL. I've heard that it's a lot more stable if you run it on AIX, but then who wants to be running AIX?

Sabot said:

The thing is if SQL Server is somewhere in your development stack you've gotta get to know it well because it's could so eaily add lead boots to your projects.

Yes it is a Yin/Yang thing, you do have to put code into the right place and working out that balancing act does take knowledge either built up by experience or from the many good educational materials, books and webcasts (most of them free from Microsoft!)

I would have to stab myself in the head if I did UI stuff all day ... now that is boring! Programming all that validation, working out the next scenario where a user can be stupid, not interesting at all

On a serious note, I did enjoy UI coding but I don't have the temperment for it.

So you get the big no-no's in SQL Server right? Like Select * is bad?

You get why getting the right 'Collations' is very important? ... and which ones have been deprecated?

Why DBA's don't like LINQ? ... it's all about the Query Plan Baby!

Why the new MERGE command is very cool? ... well get's you into the pub early.

... and not to mention the game changers coming in SQL Server 2008 R2 !

Geeeez I could talk all day, I will pull out some of my favourite Microsoft webcasts for you to watch.

You said "up until recently", but if I were to choose MySQL today, it administration would be on par? If not, what exactly is missing?

This really is a serious question by the way. In the future I will probably have the need for a database. I want to make a good, balanced, decision.

You seem to be really exicited about SQL Server. I've done my own research on it. But I am interested to understand why I should spend thousands of dollars (or worse, force my customers to spend thousands of dollars in additional to my own fees - money I'd rather have) on a database when there are SQL-99 compliant databases which are free. What am I missing out on exactly if I support  Postgres or MySQL?

Even more difficult to justify, why should I write properitary database code such as T-SQL which will ensure my code will never work with more then one database and operating system? What should I tell customers who want to use my product on other databases? I hope it's not "I'd really love to invoice you for $500k mister, but tough sh*t, I've decided early on to write completely unportable code. How about you hand that check over to my rich competitor who supports your DB because his code is SQL-99?"

I really don't ever want to have to say "No, you can't" to a high paying customer just because his infrastructure and my code don't work together. That's why portability is important to me, in my industry there exists no monoculture where everyone uses Windows and SQL Server.

Will my productivity with T-SQL really increase that much to justify possibly losing customers? Does T-SQL like practically write itself or something?

AndyC said:

Bass said:

*snip*

Put them under a large enough strain and the weaknesses in them compared to the big players become all to obvious. That's not to say they aren't getting better however and, personally speaking, I'd use either of them over DB2 any day.

Really, what do you mean by that? The performence of MySQL is worse? That it's less stable? If so, why do large organizations with like Google, Facebook and Yahoo depend on it?

Bass said:

Sabot said:

*snip*

You said "up until recently", but if I were to choose MySQL today, it administration would be on par? If not, what exactly is missing?

This really is a serious question by the way. In the future I will probably have the need for a database. I want to make a good, balanced, decision.

You seem to be really exicited about SQL Server. I've done my own research on it. But I am interested to understand why I should spend thousands of dollars (or worse, force my customers to spend thousands of dollars in additional to my own fees - money I'd rather have) on a database when there are SQL-99 compliant databases which are free. What am I missing out on exactly if I support  Postgres or MySQL?

Even more difficult to justify, why should I write properitary database code such as T-SQL which will ensure my code will never work with more then one database and operating system? What should I tell customers who want to use my product on other databases? I hope it's not "I'd really love to invoice you for $500k mister, but tough sh*t, I've decided early on to write completely unportable code. How about you hand that check over to my rich competitor who supports your DB because his code is SQL-99?"

I really don't ever want to have to say "No, you can't" to a high paying customer just because his infrastructure and my code don't work together. That's why portability is important to me, in my industry there exists no monoculture where everyone uses Windows and SQL Server.

Will my productivity with T-SQL really increase that much to justify possibly losing customers? Does T-SQL like practically write itself or something?

You said "up until recently", but if I were to choose MySQL today, it administration would be on par? If not, what exactly is missing?

It's really just edge cases where MySQL isn't sufficient. For example, it can handle nested queries up to three levels deep while Oracle can go up to 16 levels. If I'm wrong on this then someone tell me, but this was the case last I knew.

Microsoft also does SQL Server Express which is free as well. There is not much need for you to spend thousands on a RDBMS unless you need some ultra-specific trait.

The Wikipedia feature comparison is nice and comprehensive.

Bass said:

Sabot said:

*snip*

You said "up until recently", but if I were to choose MySQL today, it administration would be on par? If not, what exactly is missing?

This really is a serious question by the way. In the future I will probably have the need for a database. I want to make a good, balanced, decision.

You seem to be really exicited about SQL Server. I've done my own research on it. But I am interested to understand why I should spend thousands of dollars (or worse, force my customers to spend thousands of dollars in additional to my own fees - money I'd rather have) on a database when there are SQL-99 compliant databases which are free. What am I missing out on exactly if I support  Postgres or MySQL?

Even more difficult to justify, why should I write properitary database code such as T-SQL which will ensure my code will never work with more then one database and operating system? What should I tell customers who want to use my product on other databases? I hope it's not "I'd really love to invoice you for $500k mister, but tough sh*t, I've decided early on to write completely unportable code. How about you hand that check over to my rich competitor who supports your DB because his code is SQL-99?"

I really don't ever want to have to say "No, you can't" to a high paying customer just because his infrastructure and my code don't work together. That's why portability is important to me, in my industry there exists no monoculture where everyone uses Windows and SQL Server.

Will my productivity with T-SQL really increase that much to justify possibly losing customers? Does T-SQL like practically write itself or something?

Bass - I'm responsible for *all* databases in a FTSE 100, I am genuninely interested in all of them and more so if a database can bring additional value to my business as I'm a share-holder in my business. So  I am *that* customer who will spend lots of money and doesn't like to.

So what if MySQL is any good?!

How is MySQL going to save me money I've *already spent* on Oracle and SQL Server? The software licensing money for Oracle and SQL Server has gone to Oracle and Microsoft.

I've also got hundreds of databases on Oracle and SQL Server, both platforms are seriously embedded. Yes, the licensing is in the £ millions but the OPEX that would get burnt to migrate even on to a no CAPEX spend product would be more so it's unviable. The version upgrade from SQL Server 2000 - 2005 and Oracle 8 to 10g proved that.

So as the money has gone my attention turns to leveraging my investment so I'm going to *want* to stick more stuff on to Oracle and SQL Server.

In all seriousness if you turn up to my company with a 'MySQL only' solution I will count that against you. If you talk Oracle and SQL Server I will be confident and I will start to tick boxes. I don't care who else is running MySQL least of all a computer company.

If you really want my money find out what I've got and then compile with it, you won't go out of business by having Oracle and SQL Server as your only choices, the are very common and to be expected. You won't be trail-blazing any decisions on databases for anyone ... unless you are selling software to start-ups.

Going down the 'MySQL only route' will not do you any favours but I always wish people luck if they make brave decision in business. Doesn't mean they are going to get any.

Bass said:

Sabot said:

*snip*

You said "up until recently", but if I were to choose MySQL today, it administration would be on par? If not, what exactly is missing?

This really is a serious question by the way. In the future I will probably have the need for a database. I want to make a good, balanced, decision.

You seem to be really exicited about SQL Server. I've done my own research on it. But I am interested to understand why I should spend thousands of dollars (or worse, force my customers to spend thousands of dollars in additional to my own fees - money I'd rather have) on a database when there are SQL-99 compliant databases which are free. What am I missing out on exactly if I support  Postgres or MySQL?

Even more difficult to justify, why should I write properitary database code such as T-SQL which will ensure my code will never work with more then one database and operating system? What should I tell customers who want to use my product on other databases? I hope it's not "I'd really love to invoice you for $500k mister, but tough sh*t, I've decided early on to write completely unportable code. How about you hand that check over to my rich competitor who supports your DB because his code is SQL-99?"

I really don't ever want to have to say "No, you can't" to a high paying customer just because his infrastructure and my code don't work together. That's why portability is important to me, in my industry there exists no monoculture where everyone uses Windows and SQL Server.

Will my productivity with T-SQL really increase that much to justify possibly losing customers? Does T-SQL like practically write itself or something?

why should I write properitary database code such as T-SQL which will ensure my code will never work with more then one database and operating system?

You don't have to, frankly 99.9% of the time you don't need the T-SQL extensions, and that's what they are, extensions. Ditto with Oracle. If you think that you can't run SQL-99 on Sql Server then your research hasn't been that deep, especially as MySQL only supports a SUBSET of Sql99 and indeed has it's own proprietary extensions and states "We are not afraid to add extensions to SQL or support for non-SQL features if this greatly increases the usability of MySQL Server for a large segment of our user base."

I really don't ever want to have to say "No, you can't" to a high paying customer just because his infrastructure and my code don't work together. That's why portability is important to me, in my industry there exists no monoculture where everyone uses Windows and SQL Server.

Saying you only support a single database is not portability. Simply because your chosen database runs across X OS's is not going to endear you to large customers who already have an investment in a database system other than your chosen one. Rather than support a single database abstract it, provider models, ORMs that support multiple backends. Far more flexible and gives you a larger market to sell into.

blowdart said:

Bass said:

*snip*

why should I write properitary database code such as T-SQL which will ensure my code will never work with more then one database and operating system?

You don't have to, frankly 99.9% of the time you don't need the T-SQL extensions, and that's what they are, extensions. Ditto with Oracle. If you think that you can't run SQL-99 on Sql Server then your research hasn't been that deep, especially as MySQL only supports a SUBSET of Sql99 and indeed has it's own proprietary extensions and states "We are not afraid to add extensions to SQL or support for non-SQL features if this greatly increases the usability of MySQL Server for a large segment of our user base."

I really don't ever want to have to say "No, you can't" to a high paying customer just because his infrastructure and my code don't work together. That's why portability is important to me, in my industry there exists no monoculture where everyone uses Windows and SQL Server.

Saying you only support a single database is not portability. Simply because your chosen database runs across X OS's is not going to endear you to large customers who already have an investment in a database system other than your chosen one. Rather than support a single database abstract it, provider models, ORMs that support multiple backends. Far more flexible and gives you a larger market to sell into.

Perhaps I was misunderstood, I (so far) want to support multiple databases, and do so, by writing simple SQL-99 that should work on all major databases. I will look into ORMs as well. I'm asking what the advantage of writing T-SQL is, is it worth losing portability over? It baffles me because there are companies who sell products that only work with one database.

Bass said:

blowdart said:

*snip*

Perhaps I was misunderstood, I (so far) want to support multiple databases, and do so, by writing simple SQL-99 that should work on all major databases. I will look into ORMs as well. I'm asking what the advantage of writing T-SQL is, is it worth losing portability over? It baffles me because there are companies who sell products that only work with one database.

You'll find at some point you'll need to do something per database in order to make it perform better, be it reordering selects, doing some weird * indexing, or leveraging an extension they provide. That's going to happen no matter what, and if you're used a provider model, well then that's easy. It's always going to be about performance and scalability, no matter what the underlying database.

Bass said:

Sabot said:

*snip*

You said "up until recently", but if I were to choose MySQL today, it administration would be on par? If not, what exactly is missing?

This really is a serious question by the way. In the future I will probably have the need for a database. I want to make a good, balanced, decision.

You seem to be really exicited about SQL Server. I've done my own research on it. But I am interested to understand why I should spend thousands of dollars (or worse, force my customers to spend thousands of dollars in additional to my own fees - money I'd rather have) on a database when there are SQL-99 compliant databases which are free. What am I missing out on exactly if I support  Postgres or MySQL?

Even more difficult to justify, why should I write properitary database code such as T-SQL which will ensure my code will never work with more then one database and operating system? What should I tell customers who want to use my product on other databases? I hope it's not "I'd really love to invoice you for $500k mister, but tough sh*t, I've decided early on to write completely unportable code. How about you hand that check over to my rich competitor who supports your DB because his code is SQL-99?"

I really don't ever want to have to say "No, you can't" to a high paying customer just because his infrastructure and my code don't work together. That's why portability is important to me, in my industry there exists no monoculture where everyone uses Windows and SQL Server.

Will my productivity with T-SQL really increase that much to justify possibly losing customers? Does T-SQL like practically write itself or something?

Will my productivity with T-SQL really increase that much to justify possibly losing customers? Does T-SQL like practically write itself or something?

T-SQL does have a lot of very cool stuff that really increases your productivity a lot. In SQL Server 2008, for example, there's the very cool MERGE-command.

Sabot said:

vesuvius said:

*snip*

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.

However the 'Daddy' is going to be Microsoft Project Oslo in this space .... however it won't be if it costs too much, the best thing to do is bundle it in with Visual Studio Architecture Edition or a value add to an additional product .

LINQ - well because it's language integrated, intellisense-supported, type-checked, highly extensible - not embedded and opaque. And because it's higher-level and because it applies to much more than just SQL for that reason. I've mostly used LINQ to XML which is not as sexy (especially with namespaces - yikes).

"Oslo" we can split into three parts; Intellipad, Quadrant, Repository- with M as the unifying constant. I expect we'll see Express versions of all these tools (well maybe Intellipad and Quadrant will be baked into VS) and of course M will be free to implement by anyone, so everyone can make their own IQR stack, which I'm sure we'll see - there's also an open specification community for it now, with experts like James Clark on board (que EM).

The million dollar question - is this going to be an integral part of Windows 8 or 9 (or further down - Midori); well, one step at a time.

JoshRoss said:

Sabot said:

*snip*

I haven't looked through the training material. However, I find most training docs rather drab.  Have you solved any of Itzik Ben-gan's puzzles? He publishes some good ones! 

-> Is SQL interesting to learn?

Probably not, since I favour the object or model driven approach:

http://odetocode.com/Blogs/scott/archive/2008/07/14/12185.aspx

BTW, I  am a networking (WCF), GUI (WPF) guy, I hate Database and Silverlight:)

Zhou Yong

footballism said:

JoshRoss said:

*snip*

-> Is SQL interesting to learn?

Probably not, since I favour the object or model driven approach:

http://odetocode.com/Blogs/scott/archive/2008/07/14/12185.aspx

BTW, I  am a networking (WCF), GUI (WPF) guy, I hate Database and Silverlight:)

Zhou Yong

JoshRoss said:

Sabot said:

*snip*

I haven't looked through the training material. However, I find most training docs rather drab.  Have you solved any of Itzik Ben-gan's puzzles? He publishes some good ones! 

Exciting?  Maybe to a DBM or something, to me SQL is just this annoying thing I have to deal with that spits data into the interesting area of the application.  In fact I am miserable whenever I write SQL, not to say its hard, writing SQL is one of the easiest things I do during a typical development day.  CSS is what really pisses me off and drives me up that damn wall!!

Sabot said:

I used to really enjoy doing UI's at the start if my carreer ... but I got bored because they aren't very challenging and wasn't making me an alround good coder.

Well... it depends. I mean if you only drag and drop in buttons you probably don't much code when doing UI. But once you start to do these user controls on your own, like drawing them, making sure they are performant etc. you might also learn stuff. Probably not that much as if you only hang around deeper in the code but still...

SQL, btw., is also getting boring after a while...

littleguru said:

Sabot said:

*snip*

Well... it depends. I mean if you only drag and drop in buttons you probably don't much code when doing UI. But once you start to do these user controls on your own, like drawing them, making sure they are performant etc. you might also learn stuff. Probably not that much as if you only hang around deeper in the code but still...

SQL, btw., is also getting boring after a while...

Fare comment.

SQL Server isn't just about SQL btw and it's the rest of it I find most interesting such as ...

Integration Services (SSIS) - http://www.microsoft.com/sqlserver/2008/en/us/integration.aspx - well thats ETL story sorted

Data Mining and Business Inteligence (BI) - http://www.microsoft.com/sqlserver/2008/en/us/data-mining.aspx - more than just reporting!

Performance and Scaling - http://www.microsoft.com/sqlserver/2008/en/us/performance-scale.aspx - Can you imagine trying to code half of this stuff ... and you don't have to!

Not to mention a very cool feature inside SQL Server 2008 called the Services Broker which is about scaling-out data services which as you can imagine is kind of handy for anyone building large websites and enterprise wide systems. Here is a link to the Programming guide.

These features aren't all available just in the Enterprise version ... you can start to get to know them all in the Developer Edition which you can pick up for between £40- £50 and is available on MSDN & Technet.

Most of these tools are aimed farely and squarely at Developers and not DBA's so go and explore ... it will saving writting lots of code!

Sabot said:

I used to really enjoy doing UI's at the start if my carreer ... but I got bored because they aren't very challenging and wasn't making me an alround good coder.

I think UI development can be challenging and creative, finding the right layout, making sure everything looks and feels right, making sure everything scales nicely on different DPIs, keeping the UI responsive even while performing heavy-duty tasks (or while waiting for data coming from a server), ...

Sabot said:

littleguru said:

*snip*

Fare comment.

SQL Server isn't just about SQL btw and it's the rest of it I find most interesting such as ...

Integration Services (SSIS) - http://www.microsoft.com/sqlserver/2008/en/us/integration.aspx - well thats ETL story sorted

Data Mining and Business Inteligence (BI) - http://www.microsoft.com/sqlserver/2008/en/us/data-mining.aspx - more than just reporting!

Performance and Scaling - http://www.microsoft.com/sqlserver/2008/en/us/performance-scale.aspx - Can you imagine trying to code half of this stuff ... and you don't have to!

Not to mention a very cool feature inside SQL Server 2008 called the Services Broker which is about scaling-out data services which as you can imagine is kind of handy for anyone building large websites and enterprise wide systems. Here is a link to the Programming guide.

These features aren't all available just in the Enterprise version ... you can start to get to know them all in the Developer Edition which you can pick up for between £40- £50 and is available on MSDN & Technet.

Most of these tools are aimed farely and squarely at Developers and not DBA's so go and explore ... it will saving writting lots of code!

I could bet with you that for certain people that gets also boring after a while...