Perhaps SQL isn't interesting? But it sure is !

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?

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.

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:

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.

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:

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!!

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.