Coffeehouse Thread

58 posts

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

Back to Forum: Coffeehouse
  • User profile image
    Sabot

    I hoping that I'm not right but I kind of getting the impression that developers in general aren't really all that interested in SQL or SQL Server any more?

    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!

  • User profile image
    JoshRoss

    I for one do not want my database to be exciting, I just want it to work.  That said, there are all kinds of new stuff in the SQL 2008 ecosystem geared towards devs, namely the Entity Framework.

    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

  • User profile image
    spivonious

    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.

  • User profile image
    PerfectPhase

    Big issue for me is I look at the new features, FILESTREAM would be a god send for something I'm working on, but have to target 2005, so can't use all the new shinnyness.  Infact spec'ing 2005 didn't go down to well with some of our customers, but you have to draw the line somewhere.

  • User profile image
    Dr Herbie

    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.

    Smiley

    Herbie

  • User profile image
    spivonious

    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.

    Smiley

    Herbie

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

    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.

  • User profile image
    Sabot

    Interesting.

    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.

  • User profile image
    Bass

    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.

  • User profile image
    JoshRoss

    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.

  • User profile image
    figuerres

    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.

    Smiley

    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.

  • User profile image
    Red5

    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

  • User profile image
    Dr Herbie

    Red5 said:
    figuerres said:
    *snip*

    DITTO

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

    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

     

  • User profile image
    Ion Todirel

    spivonious said:
    Dr Herbie said:
    *snip*

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

    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" Smiley

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

  • User profile image
    Sabot

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

    Watch the Introduction to SQL Server 2008 R2 Video

  • User profile image
    Sabot

    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 Devil

    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.

  • User profile image
    AndyC

    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 Devil

    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. Tongue Out

  • User profile image
    littleguru

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

  • User profile image
    spivonious

    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 Devil

    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.

Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.