April 3, 2009 at 5:30 pm
Jeff Moden (4/3/2009)
dphillips (4/3/2009)
I am a Legos guy. I know what each piece does. I know how to make and/or mod the parts if needed. But in the end, when it is time to build something, I don't want to spend 3 or 4 compile runs to find all my fat-fingered typos or other problems, especially in very lengthy code.Heh... I don't have those problems even on a fresh build... click'n'drag from the object works just fine for me, I know how to type, and I test as I go which has kept me from ever needing to use an (ugh!) debugger. Intellisense actually slows me down because it get's in the way. It's one of the things I hated about TOAD.
2 things: First, you're just plain lucky. And second, my brain knows what to type, but the fingers do not always follow orders.:-)
April 3, 2009 at 5:40 pm
dphillips (4/3/2009)
First, you're just plain lucky.
I think you'll find that there's just a little bit more to it than that. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
April 3, 2009 at 5:44 pm
Jeff Moden (4/3/2009)
I think you'll find that there's just a little bit more to it than that. 😉
Indeed. 😀
April 3, 2009 at 7:10 pm
Attempts have been made to make it easier for developers to code against databases, the latest failure being LINQ to SQL, so lets just accept that trying to make set-based querying fit the OO or procedural model, whilst it can be implemented, never really works.
Software engineering thinks it is Anders Hejlsberg most brilliant work and I agree, LINQ to SQL problems are pedestrian algebraic problems which is currently fixed in various blog postings. Microsoft is holding secret meetings around the country to get feedback on VS2010 so one day I will create LINQ SETs and call T-SQL SETs and deploy in one month.
http://www.elasticvapor.com/2009/03/inside-access-to-microsoft-vsts.html
Also, I hope that LINQ dies the quick death it deserves.
There is very limited problem with LINQ the actual problems are with LINQ to SQL which I think SQL Server slowed because mathematically it may work equally or better with Oracle. There are native associative arrays in Oracle.
:Whistling: :hehe:
Kind regards,
Gift Peddie
April 3, 2009 at 8:01 pm
dphillips (4/3/2009)
Jeff Moden (4/3/2009)
dphillips (4/3/2009)
I am a Legos guy. I know what each piece does. I know how to make and/or mod the parts if needed. But in the end, when it is time to build something, I don't want to spend 3 or 4 compile runs to find all my fat-fingered typos or other problems, especially in very lengthy code.Heh... I don't have those problems even on a fresh build... click'n'drag from the object works just fine for me, I know how to type, and I test as I go which has kept me from ever needing to use an (ugh!) debugger. Intellisense actually slows me down because it get's in the way. It's one of the things I hated about TOAD.
2 things: First, you're just plain lucky. And second, my brain knows what to type, but the fingers do not always follow orders.:-)
Getting back to the original post... SQL is a rather flat programming language, which was designed by a committee, that vendors have "bulked up" into their own XSQL flavor programming language (T-SQL, PL/SQL). I really like the power and flexibility I have with T-SQL especially compared to most of the PL/SQL syntax. However, there are some nifty features in PL/SQL and Oracle that would be nice to have in T-SQL.
* TRUNC - function that removes the time portion from a date. Yeah, I've heard of CONVERT and use it all the time but seriously... three parameters. I could write my own but version... why not add it to the language. Jeff also pointed out that the user defined version don't perform as well as the built-ins.
* DECODE - function that behaves like a case statement (i.e. decode(PriorityId, null, 'missing', 1, 'High', 2, 'Medium', 3, 'Low', 'not defined')). Very handy and flexible. A functionally equivalent case statement would be:
case
when PriorityId is null then 'missing'
when PriorityId 1 then 'High'
when PriorityId 2 then 'Medium'
when PriorityId 3 then 'Low'
else 'not defined' end
* PACKAGES - programming construct that behaved like a class. You write stored procedures and functions that are "contained" within the package. I believe you can also assign permissions at the package level.
Finally, I disagree with the writer that wants to be able to use any T-SQL expression any where he wants. A question back for him would be does he code for that behavior in his own code? If he writes a function that accepts a string as an input should I be able to pass in a string to reads a value from a table and just expect that to work?
--Paul Hunter
April 3, 2009 at 8:52 pm
Paul Hunter (4/3/2009)
Finally, I disagree with the writer that wants to be able to use any T-SQL expression any where he wants. A question back for him would be does he code for that behavior in his own code? If he writes a function that accepts a string as an input should I be able to pass in a string to reads a value from a table and just expect that to work?
What that guy mentioned, and I agree with, is pretty standard behavior in most languages. Basically passing the return of a function as the input to another. E.g. ltrim(rtrim(col1))
The specific example he raised was about the inputs to the raiserror function. I can't actually test this right now, but I assume his complaint concerned it being able to accept, say, a string but not an expression that returns a string. A bit like the ltrim function only accepting a constant string and not a variable / column. So I guess in this case the issue with the raiserror function is its argument is defined to be a constant.
April 3, 2009 at 8:53 pm
steve dassin (4/3/2009)
Michael Valentine Jones (4/2/2009)
I think that SQL as a language is not really the problem. There are a lot of developers out there that really don’t do well in any language, but the quality of their work is more exposed in SQL where performance and accuracy is more of an issue.The number one problem that most developers have when working with SQL Server is not using the language, but developing a schema that models the data accurately and completely. Deficiencies in the design of the data are much harder to fix once they make it into a production environment, and they make it hard for developers to write fast, efficient queries to get the data they need. At the same time, many developers seem unaware of the long term implications of bad logical and physical designs, so the most important aspect of database development gets the least amount of attention. Bad design leads to developers spending a lot of time trying to stand SQL on its head to do things it shouldn’t have to do with a well designed schema.
I remember a conversation with a developer where I questioned the fact that he used inappropriate data types and that none of his tables had a primary key. He dismissed this saying that he was designing for the “real world”, and couldn’t be bothered with things were of only “theoretical interest”.
This sounds like the (St.) Valentine's (day) massacre of developers. There's nothing wrong with sql. The problem is the dumb and stupid developers using it! The trash the user defense. I could just as easily employ the same sophistry to sql users avoidance of dataphor. Their just to stupid and hard headed to understand the difference. But do you see me doing such childish things? 🙂
best,
steve
Other than completely misunderstanding and\or ignoring what I was talking about, nice point. I know you are here mainly to spam the world about your new religion, but at least do us the favor of occasionally trying to add something to the discussion. In this case, perhaps you could jump in and explain how your favorite tool actually overcomes a bad underlying database design.
OK, now getting back to the real world:
What I am saying is that most of the problems with SQL development originate in the poor design of the database. Once you fail to properly model the real world entities into a database that accurately reflects them, you have built bugs into the application that everyone will have to work around. And after that, it doesn’t matter if you are using TSQL, PL/SQL, or the latest “next big thing, OO, TRDBMS, blah blah blah vaporware”, you are still dealing with a flawed data model that will cause problems at every turn.
Since most developers have no desire to do the really hard work that it takes to first gain a detailed understanding of the real world entities, and then do the really hard work that it takes to design an actual physical database model that most accurately reflects the true structure of the data, most “bugs” are hard coded in at this point. Very few people, including most experienced database professionals, are really up to this sort of work or have any talent for it. Very few people developing applications are aware of the actual cost of doing a poor job of modeling the data. Most just want to jump in and start coding.
Most of the costs show up downstream when it is a massive job and too late to fix. When development managers start wondering why it takes 1,000 developer hours per month just to do break fixes and routine enhancements on systems that have been in production for years they gain an understanding of the cost of poor design work. However, most will still make the same mistake on the next project.
April 4, 2009 at 4:49 am
A reply from another old Developer....
Over the years SQL has expanded greatly, in the days of SQL 7 / 2000, the developers bible "Inside SQL" by Kalen Delaney was one sizeable hard back book, with SQL 2005 this became three chunky paperbacks.
I started playing with v4.2 of SQL and I'm still discovering new ways of writing efficient code, and more obviously finding poor code! Which brings me to the point I would like to make.
No matter how good the tools are for a particular language [C#, C++, SQL etc] poor code is still too easy to write, and the problem with poorly constructed SQL is that it normally impacts on other users, and ultimately it can bring a server down.
April 4, 2009 at 5:27 am
bob.willsie (4/3/2009)
I think its important to have a good foundational understanding of programming and when/why to use an SQL query instead of writing code.I learned SQL by looking at the resulting queries from MS Access applications I created. Hush, I can hear the groans already...
Hey - don't knock a RDBMs that doesn't even implement cursors!
I'm a DBA.
I'm not paid to solve problems. I'm paid to prevent them.
April 4, 2009 at 7:52 am
Paul Hunter (4/3/2009)
Hmmm... It seems the harder Jeff works the luckier he gets... could there be a connection?
Heh.... You're not qualified to make such a statement because you don't know if I work hard or not. 😉 And, like I said... luck rarely has anything to do with doing it right.
--Jeff Moden
Change is inevitable... Change for the better is not.
April 4, 2009 at 7:58 am
And, you're absolutely correct... some simple additions such as TRUNC(Date) would make life a bit easier. On the other hand, I hope to never see DECODE in T-SQL...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 5, 2009 at 9:44 pm
Jeff Moden (4/3/2009)
dphillips (4/3/2009)
I am a Legos guy. I know what each piece does. I know how to make and/or mod the parts if needed. But in the end, when it is time to build something, I don't want to spend 3 or 4 compile runs to find all my fat-fingered typos or other problems, especially in very lengthy code.Heh... I don't have those problems even on a fresh build... click'n'drag from the object browser works just fine for me, I know how to type, and I test as I go which has kept me from ever needing to use an (ugh!) debugger. Intellisense actually slows me down because it get's in the way. It's one of the things I hated about TOAD.
Ditto, I had SQL Prompt turned off for the longest time just because I had got so used to using the tab key to format my code and it would cause autocomplete to trigger on me. Working in 2008 for months now, I left intellisense on, but I still trip over it when I get coding fast. Part of it may be my 60 wpm typing, where I am typing ahead of what is displayed (and that much farther ahead from when the display message is perceived by my brain), so I have to back up two or three words by the time I realize that my OR was transformed into a @@ Function (WHY!?) or I've responded to some other prompt that I didn't anticipate.
I definitely don't denigrate those who've learned to use the tool faster than me! I do appreciate its catalog-awareness and when I remember to use it, I do have to type a lot less, which is handy on arthritis days. But I don't think lacking a contextual dictionary is a legitimate reason why other languages have 'passed on'! Otherwise we'd all be using WebFocus or some other 4GL with a buttery smooth interface, not the mess that is Visual Studio. Rather, the aged-out technology failed to make use of the capacity and speed of available hardware. You can't say that about SQL.
😎 Kate The Great :w00t:
If you don't have time to do it right the first time, where will you find time to do it again?
April 5, 2009 at 9:51 pm
Michael Valentine Jones (4/3/2009)
What I am saying is that most of the problems with SQL development originate in the poor design of the database. Once you fail to properly model the real world entities into a database that accurately reflects them, you have built bugs into the application that everyone will have to work around. And after that, it doesn’t matter if you are using TSQL, PL/SQL, or the latest “next big thing, OO, TRDBMS, blah blah blah vaporware”, you are still dealing with a flawed data model that will cause problems at every turn.
Since most developers have no desire to do the really hard work that it takes to first gain a detailed understanding of the real world entities, and then do the really hard work that it takes to design an actual physical database model that most accurately reflects the true structure of the data, most “bugs” are hard coded in at this point. Very few people, including most experienced database professionals, are really up to this sort of work or have any talent for it. Very few people developing applications are aware of the actual cost of doing a poor job of modeling the data. Most just want to jump in and start coding.
Most of the costs show up downstream when it is a massive job and too late to fix. When development managers start wondering why it takes 1,000 developer hours per month just to do break fixes and routine enhancements on systems that have been in production for years they gain an understanding of the cost of poor design work. However, most will still make the same mistake on the next project.
A big AMEN from the Data Architect
😎 Kate The Great :w00t:
If you don't have time to do it right the first time, where will you find time to do it again?
April 6, 2009 at 5:19 am
Quick survey: Nine pages later, has anyone change their mind about anything?
April 6, 2009 at 5:29 am
I agree with Michael, it's not that SQL is difficult, in fact I think T-SQL is quite easy, it's making it perform that can be seen as difficult, and that boils down to underlying design and an ability to think in sets.
To get SQL to perform is what might make it look difficult. It's easy to write a query but to get the optimal performance out of that query is what is making it difficult. I have never programmed in any other query language than SQL and when I learned to program (I started with SQL 7) no-one said anything about performance. So, I am sure there still a lot of my queries running out there that is performing badly. I just love MSSQL but I have never used anything else so can't really say.;-);-);-);-)
:-PManie Verster
Developer
Johannesburg
South Africa
I can do all things through Christ who strengthens me. - Holy Bible
I am a man of fixed and unbending principles, the first of which is to be flexible at all times. - Everett Mckinley Dirkson (Well, I am trying. - Manie Verster)
Viewing 15 posts - 76 through 90 (of 266 total)
You must be logged in to reply to this topic. Login to reply