If you code standard line of business applications or work in an IT department but not a software company...
-
Thoroughly understanding SQL is more important than any other skill. Yeah it is just my opinion and you may feel free to disagree, but all business care about the money and the math has to add up. Everything else is secondary.
I didn't get any requirements for the signature
ToddHileHoffer wrote:
Thoroughly understanding SQL is more important than any other skill.
There's an argument to be made for that, but... I fit the profile you describe (well, depending on your definition of "standard"), and SQL work makes up maybe 10% of what i do, tops. I could conceivably get away without knowing SQL at all... there are other skills far more important.
-
ToddHileHoffer wrote:
Thoroughly understanding SQL is more important than any other skill.
There's an argument to be made for that, but... I fit the profile you describe (well, depending on your definition of "standard"), and SQL work makes up maybe 10% of what i do, tops. I could conceivably get away without knowing SQL at all... there are other skills far more important.
SQL makes ups about 10% of what I do as well. But if you start with a normalized database with proper keys / constraints and indexes it makes programming easier. I guess if you never have to write interfaces, SQL is less important though.
I didn't get any requirements for the signature
-
moon_stick wrote:
the most important skill in any business is really communication
Nope...breathing.
Dinobot_Slag wrote:
Nope...breathing.
But I'm a vampire, you insensitive clod! Oh wait, this is CP, not Slashdot... Sorry, odd mood... Someone accidentally got that "Badger badger badger badger" thing stuck in my head, so all of my thoughts are coming out sideways. Anyway... Speaking as someone who writes line-of-business applications and doesn't work for a software company (Hedge fund)... SQL is definitely a necessity, but it only gets you halfway there. You still need to know a decent RAD tool/language hands-down to get things out in reasonable timeframes.
Proud to have finally moved to the A-Ark. Which one are you in? Developer, Author (Guardians of Xen)
-
SQL makes ups about 10% of what I do as well. But if you start with a normalized database with proper keys / constraints and indexes it makes programming easier. I guess if you never have to write interfaces, SQL is less important though.
I didn't get any requirements for the signature
The majority of the communication we do with other systems is via XML, flat-file, or binary structures, sent via COM, web services, or plain old files. Again, it's bad if we can't load or save to The Big Oracle Database, but that's not a huge concern day-to-day.
-
Dinobot_Slag wrote:
Nope...breathing.
But I'm a vampire, you insensitive clod! Oh wait, this is CP, not Slashdot... Sorry, odd mood... Someone accidentally got that "Badger badger badger badger" thing stuck in my head, so all of my thoughts are coming out sideways. Anyway... Speaking as someone who writes line-of-business applications and doesn't work for a software company (Hedge fund)... SQL is definitely a necessity, but it only gets you halfway there. You still need to know a decent RAD tool/language hands-down to get things out in reasonable timeframes.
Proud to have finally moved to the A-Ark. Which one are you in? Developer, Author (Guardians of Xen)
:badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger:
I hope you realise that hamsters are very creative when it comes to revenge. - Elaine
-
:badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger: :badger:
I hope you realise that hamsters are very creative when it comes to revenge. - Elaine
-
He who makes a beast out of himself gets rid of the pain of being a man
I hope you realise that hamsters are very creative when it comes to revenge. - Elaine
-
Thoroughly understanding SQL is more important than any other skill. Yeah it is just my opinion and you may feel free to disagree, but all business care about the money and the math has to add up. Everything else is secondary.
I didn't get any requirements for the signature
Yeah, that's pretty much true. Given that the SQL is at the bottom of a stack of layers, if you screw up there, nothing further up can improve things. But it is to be hoped that the SQL can be improved without changing code at the upper layers, so perhaps an SQL expert (consultant) can be brought in toward the end of the project to review the SQL. In which case the primary developer needn't be an SQL whiz.
-
Yeah, that's pretty much true. Given that the SQL is at the bottom of a stack of layers, if you screw up there, nothing further up can improve things. But it is to be hoped that the SQL can be improved without changing code at the upper layers, so perhaps an SQL expert (consultant) can be brought in toward the end of the project to review the SQL. In which case the primary developer needn't be an SQL whiz.
Well, if you are lucky enough to have DBA (or consultant) to review the SQL and help you with it then you are lucky. But it is true that if you have access to an expert to help then you don't have to be an expert yourself. My basic point was if you have a poor database even the best programmer can't fix it. And if you have a great database even the worst programmer can't do to much damage.
I didn't get any requirements for the signature
-
Thoroughly understanding SQL is more important than any other skill. Yeah it is just my opinion and you may feel free to disagree, but all business care about the money and the math has to add up. Everything else is secondary.
I didn't get any requirements for the signature
I often tell people that SQL will cure cancer. You can do anything with it. Which is why linq ticks me off so much. So many developers are pawning SQL off as deceased and irrelevant and the shouldn't.
Need custom software developed? I do C# development and consulting all over the United States. A man said to the universe: "Sir I exist!" "However," replied the universe, "The fact has not created in me A sense of obligation." --Stephen Crane
-
I often tell people that SQL will cure cancer. You can do anything with it. Which is why linq ticks me off so much. So many developers are pawning SQL off as deceased and irrelevant and the shouldn't.
Need custom software developed? I do C# development and consulting all over the United States. A man said to the universe: "Sir I exist!" "However," replied the universe, "The fact has not created in me A sense of obligation." --Stephen Crane
Ennis Ray Lynch, Jr. wrote:
I often tell people that SQL will cure cancer. You can do anything with it. Which is why linq ticks me off so much. So many developers are pawning SQL off as deceased and irrelevant and the shouldn't.
There's still demand for COBOL isn't there? :D
Todd Smith
-
Yeah, that's pretty much true. Given that the SQL is at the bottom of a stack of layers, if you screw up there, nothing further up can improve things. But it is to be hoped that the SQL can be improved without changing code at the upper layers, so perhaps an SQL expert (consultant) can be brought in toward the end of the project to review the SQL. In which case the primary developer needn't be an SQL whiz.
As a consultant who does a lot of SQL work, I have noticed that it usually isn't the SQL that sucks and needs to be fixed (90% of SQL is straight forward), but the methods of data access used, and the location. I still often see code that is wide open to SQL injection, and often see hard coded SQL directly in an asp page. Often the same SQL is hard coded in many places in the code.
-
Thoroughly understanding SQL is more important than any other skill. Yeah it is just my opinion and you may feel free to disagree, but all business care about the money and the math has to add up. Everything else is secondary.
I didn't get any requirements for the signature
That's why I don't write business applications or work in an IT department.
-
I often tell people that SQL will cure cancer. You can do anything with it. Which is why linq ticks me off so much. So many developers are pawning SQL off as deceased and irrelevant and the shouldn't.
Need custom software developed? I do C# development and consulting all over the United States. A man said to the universe: "Sir I exist!" "However," replied the universe, "The fact has not created in me A sense of obligation." --Stephen Crane
I agree 100%. I am using LINQ to SQL in a new application just to learn it. I like being able to drag a stored proc to the dbml file and get a method to execute it without having to code parameters, but using it to access tables directly is awful. The error handling in it is really bad. If the transaction fails, the stack trace leads you know where. The exceptions generated from LINQ classes are as bad as the exception generated from ado.net commands are good.
I didn't get any requirements for the signature
-
As a consultant who does a lot of SQL work, I have noticed that it usually isn't the SQL that sucks and needs to be fixed (90% of SQL is straight forward), but the methods of data access used, and the location. I still often see code that is wide open to SQL injection, and often see hard coded SQL directly in an asp page. Often the same SQL is hard coded in many places in the code.
Well you are sort of proving my point. Any developer that understands SQL would never code it directly into a web page or use a sqlcommand without a parameter.
I didn't get any requirements for the signature
-
Well, if you are lucky enough to have DBA (or consultant) to review the SQL and help you with it then you are lucky. But it is true that if you have access to an expert to help then you don't have to be an expert yourself. My basic point was if you have a poor database even the best programmer can't fix it. And if you have a great database even the worst programmer can't do to much damage.
I didn't get any requirements for the signature
Any business could hire a consultant for a day or two to look over the SQL and review the schema.
-
Well, if you are lucky enough to have DBA (or consultant) to review the SQL and help you with it then you are lucky. But it is true that if you have access to an expert to help then you don't have to be an expert yourself. My basic point was if you have a poor database even the best programmer can't fix it. And if you have a great database even the worst programmer can't do to much damage.
I didn't get any requirements for the signature
ToddHileHoffer wrote:
And if you have a great database even the worst programmer can't do to much damage.
I went along with most of your assumptions about the importance of SQL but this one I would argue with. I have seen some absolute crap apps hanging off a really professionaly built database. A crappy dev can still screw up a system. I do about 60% of my work in SQL, because I work with batch data I find it is dramatically faster to put the business logic into SQL. I flirted with doing all the processing in a C# layer but it was not as fast.
Never underestimate the power of human stupidity RAH
-
I often tell people that SQL will cure cancer. You can do anything with it. Which is why linq ticks me off so much. So many developers are pawning SQL off as deceased and irrelevant and the shouldn't.
Need custom software developed? I do C# development and consulting all over the United States. A man said to the universe: "Sir I exist!" "However," replied the universe, "The fact has not created in me A sense of obligation." --Stephen Crane
I had a look at Linq to SQL and thought I already do all of this why do I want to do it differently, and add another layer of abstraction in there. I chucked it. I then looked into Linq to Datasets as I spend a lot of time manipulating datatables in the UI support layer. A great dissapintment, try doing a left join between a datatable and a List<> and bind it to a DGV, what a pita. So it got pared down to the absolute minimum.
Never underestimate the power of human stupidity RAH
-
I often tell people that SQL will cure cancer. You can do anything with it. Which is why linq ticks me off so much. So many developers are pawning SQL off as deceased and irrelevant and the shouldn't.
Need custom software developed? I do C# development and consulting all over the United States. A man said to the universe: "Sir I exist!" "However," replied the universe, "The fact has not created in me A sense of obligation." --Stephen Crane
Ennis Ray Lynch, Jr. wrote:
Which is why Linq to SQL ticks me off so much.
Fixed that for you.
Religiously blogging on the intarwebs since the early 21st century: Kineti L'Tziyon Judah Himango