March 24, 2016 at 10:39 am
Steve Jones - SSC Editor (3/24/2016)
GoofyGuy (3/24/2016)
Greater adherence to the ANSI standard by the vendors might reduce some of the problems Mr Jones notes.
ANSI evolves slowly, and doesn't always meet business needs. Going past ANSI gets us better products.
I know that's hard if you want to support multiple products, but if you're selling on multiple platforms, I never understood why you didn't have a team optimizing for each platform? We know how to build a data access layer. Use it and separate platform from functional call.
ANSI evolves slowly in part because it doesn't get support from vendors. Supporting ANSI would give us better, cheaper products which don't require the time and expense of multiple teams of developers trying to support multiple platforms.
March 24, 2016 at 10:43 am
The last place I worked had some ETL they wrote to import records from a vendor using a ruby script(the original developer was an outside web developer who thought ruby was just the greatest thing every, sigh...). Well it always ran slow but as we started getting to the point where the vendor increased the record count we were getting weekly, nothing drastic 10's of thousands of rows to 100's of thousands of rows, the process got to the point where it would crash routinely because ruby isn't designed to handle ETL like that(or it just sucks) and the original file would have to be manually edited to remove the rows already processed which took days to run.
The problem that you have to watch out for using Ruby, Python or even C# is that if you don't know the language and the libraries, it's easy to create an enormous numbers of objects on the heap and destroy your performance once the data set gets to a non-trivial size. It's possible to create ordure in any language if you are a novice.
March 24, 2016 at 11:05 am
roger.plowman (3/24/2016)
Preaching to the choir here. 😀My first programming was done on a 1962 vintage IBM 1130. In Fortran. On punch cards. (laughing)
Yeah, you learn minimalism really fast when you have a whopping 8K of core memory (NOT RAM!) and no virtual memory...
As for different paradigms, well, that's usually because the language in question sucks at doing the old one. The reason RBAR is such a nightmare in SQL Server is because T/SQL's interpreter is abyssmal when it comes to performance outside SELECT and company.
Oh well, keeps things interesting I suppose. 😎
I think T/SQL interpreter is even abysmal doing selects but you can at least amortize that time over many records retrieved, that's my theory anyways!
March 24, 2016 at 11:09 am
Steve Jones - SSC Editor (3/24/2016)
Andy Warren (3/24/2016)
Gary, I wonder what percentage are really "graduates" (vs independent learners) and of those graduates, of what kind of courses they took? I think a part of the problem is where to start teaching/learning. I think it makes a lot of sense to start out with a higher level language and see if they get at all IF/THEN and let them feel the success of building something, but if/when does it go to a lower level? I learned in pre-GUI days when I had to capture the keystrokes and decide what to do, quite the revelation to realize that pressing backspace doesn't "do" anything unless you move the cursor and change the display appropriately. I learned about sorting the hard way - I made it work, then had to figure out how to make it work in a reasonable amount of time (on something like 5000 records!). I don't know that we need to teach everyone how to optimize at the compiler level, but one class on debugging and optimization would not be time wasted.I think that once someone has some basic aptitude, they decide they like working with SQL, or C#, or Python, that they need some grounding in basic programming exercises. It's still on my list to do some of these for SQL, but having some kind of set of exercises, like the Advent of Code, to practice and improve your skills on, is good.
With discussions that facilitate the reasons why you make certain choices.
Going cross platforms, like C# or VB.NET to SQL, that's harder. However we need exercises there as lots of sample code isn't well written.
Regarding the ' and why you make certain choices.'... I remember watching an interview years ago with John Carmack when he decided to open up the source code for his Quake game to the public. When asked why he was doing such a crazy thing; one of the reasons I remember him giving was that the real value of the software was in the countless decisions that went into actually coding it. It was very enlightening observation for me.
March 24, 2016 at 11:30 am
Not only does a language like T-SQL abstract us from internals (although we can view at the sequences of high level operations performed by the execution plan), but the execution plan is also context sensitive. The same SQL will generate a different execution based on the number of rows in the table, the addition of a new index, or even things like environmental SET options or available memory. SQL Server caches multiple and significantly different execution plans for the same SQL statement.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
March 24, 2016 at 11:34 am
Steve Jones - SSC Editor (3/24/2016)
...if you're selling on multiple platforms, I never understood why you didn't have a team optimizing for each platform? We know how to build a data access layer. Use it and separate platform from functional call.
Simply done. Often done. Well understood. There is the impedance mismatch anyway. Using SOLID principles, particularly Dependence Injection makes for a simple and effective solution.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
March 24, 2016 at 11:39 am
Gary Varga (3/24/2016)
I am often shocked about how many IT graduates have not been taught the fundamentals of different programming paradigms. Or even that there are different ones. I am not just talking of recent graduates but those of all ages (or more importantly those graduates' study covers the last 60 years).
Yes, it's pretty horrifying that people will use algorithms with appallingly poor performance because those are what they were taught to use. I reckon the trouble is that a lot of Universities think that learning some trivial programming tricks in a rotten programming language is enough to warrant a degree. It's amazing that people gain degrees in computing without ever having heard of the concepts of arithmetic complexity, space complexity, bit complexity, and computational complexity in general. People doing maths degrees or physics degrees seem to get taught more about this stuff that people doing computing degrees.
I am also surprised by those who will not change even in the face of evidence that what they are doing is inherently wrong and not only more painful for their employer but also themselves.
To some extent, that is to be expected. These people have their degrees and some of them think that that means they know the subject, so they dismiss all evidence to teh contrary unless it's rammed down their throats by management. while others just display the norml bias towards believing what one has already accepted unless the evidence is very compelling indeed.
To top it off, many companies that are aware of the issue will not back it up by training and corporate standards.
That's part of the general jump towards short-termism in corporate policy and management, generally encouraged by lunatic goverment activity in most of the world.
Of course it's made much worse by the crzy "entitlement" attitude that so many people display - the ones who think "I'm entitled to a big salary, at least six figures, but I don't need to spend any effort on contnuing to increase my knowledge and my skills and haven't done any of that in the last 30 years"; there are far too many of them about.
All this leads me to believe that maybe some places and people deserve what they get. Unfortunately, other places and people also suffer from the fallout.
I think I would put "many" where you have "maybe some" 🙁
Tom
March 24, 2016 at 11:44 am
Gary Varga (3/24/2016)
Steve Jones - SSC Editor (3/24/2016)
...if you're selling on multiple platforms, I never understood why you didn't have a team optimizing for each platform? We know how to build a data access layer. Use it and separate platform from functional call.Simply done. Often done. Well understood. There is the impedance mismatch anyway. Using SOLID principles, particularly Dependence Injection makes for a simple and effective solution.
Often done, poorly. :/
March 24, 2016 at 11:47 am
GoofyGuy (3/24/2016)
Gary Varga (3/24/2016)
Steve Jones - SSC Editor (3/24/2016)
...if you're selling on multiple platforms, I never understood why you didn't have a team optimizing for each platform? We know how to build a data access layer. Use it and separate platform from functional call.Simply done. Often done. Well understood. There is the impedance mismatch anyway. Using SOLID principles, particularly Dependence Injection makes for a simple and effective solution.
Often done, poorly. :/
I'd love to disagree but...
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
March 24, 2016 at 11:49 am
GoofyGuy (3/24/2016)
ANSI evolves slowly in part because it doesn't get support from vendors. Supporting ANSI would give us better, cheaper products which don't require the time and expense of multiple teams of developers trying to support multiple platforms.
Except vendors compete.
They don't want other vendors having all the same advantages they have if they support xx feature and others don't
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
March 24, 2016 at 11:50 am
GoofyGuy (3/24/2016)
Gary Varga (3/24/2016)
Steve Jones - SSC Editor (3/24/2016)
...if you're selling on multiple platforms, I never understood why you didn't have a team optimizing for each platform? We know how to build a data access layer. Use it and separate platform from functional call.Simply done. Often done. Well understood. There is the impedance mismatch anyway. Using SOLID principles, particularly Dependence Injection makes for a simple and effective solution.
Often done, poorly. :/
You misspelled A-L-W-A-Y-S
At JD Edwards, we had Oracle, SQL Server, DB2 DBAs. For some reason, they wouldn't let them optimize code in a DAL. Let developers write platform independent, embedded SQL themselves.
Poor performance everywhere and, I'd argue, not faster development times.
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
March 24, 2016 at 11:57 am
Steve Jones - SSC Editor (3/24/2016)
...You misspelled A-L-W-A-Y-S...
I take umbrage at that!!! (Funny dig though ??)
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
March 24, 2016 at 12:05 pm
Steve Jones - SSC Editor (3/24/2016)
GoofyGuy (3/24/2016)
Gary Varga (3/24/2016)
Steve Jones - SSC Editor (3/24/2016)
...if you're selling on multiple platforms, I never understood why you didn't have a team optimizing for each platform? We know how to build a data access layer. Use it and separate platform from functional call.Simply done. Often done. Well understood. There is the impedance mismatch anyway. Using SOLID principles, particularly Dependence Injection makes for a simple and effective solution.
Often done, poorly. :/
You misspelled A-L-W-A-Y-S
At JD Edwards, we had Oracle, SQL Server, DB2 DBAs. For some reason, they wouldn't let them optimize code in a DAL. Let developers write platform independent, embedded SQL themselves.
Poor performance everywhere and, I'd argue, not faster development times.
I can understand it from the perspective of a company designing applications to run on multiple platforms that rely on generic meta data to build their SQL statements, in that case it makes sense to have the SQL be as generic as possible. But not for building applications you know will only run on one platform.
March 24, 2016 at 1:04 pm
Steve Jones - SSC Editor (3/24/2016)
GoofyGuy (3/24/2016)
ANSI evolves slowly in part because it doesn't get support from vendors. Supporting ANSI would give us better, cheaper products which don't require the time and expense of multiple teams of developers trying to support multiple platforms.
Except vendors compete.
They don't want other vendors having all the same advantages they have if they support xx feature and others don't
True, they compete, but there are other areas in which they may do so - more intuitive/powerful UIs, better tool sets - rather than in muddling SQL and making it a nightmare forest of dialects.
As a developer, I don't need a half-dozen competing variants of SQL any more than I do a half-dozen variants of JavaScript. Standards exist because they bring value to the software engineer.
March 24, 2016 at 1:17 pm
Very true, but I think the database is slightly different as it's a platform as well as a tool.
I'm not saying this is the right way for better software, but it has been what has helped lots of businesses.
I also think most of them support the basic SQL as an ANSI standard, but as each evolves ahead of the standard, which will always be the case, they move in new directions that others don't agree with, and thus we get platforms that diverge. You can write ANSI standard code, in a limited sense of what each platform does, and it will work.
This happened in wireless, with many early devices working slightly different than others. Vendors extended standards. They still do at times, but there is more competition and more diversity, so each needs to support a set of standards so that consumers can use their devices.
Consumers rarely use databases, so there is less market pressure for compliance. It's likely more to this, but off the top of my head, this is what I see.
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
Viewing 15 posts - 16 through 30 (of 32 total)
You must be logged in to reply to this topic. Login to reply