I still feel it's good to have as at least it keeps a little common ground between the engines. It's good to know that I can, and do, write queries against a number of different engines. I have to use different techniques for all of them, but I can do it.
Currently I have to help people write SQL against a Nucleus data warehouse. I've never even logged on to one. The reason I can provide some level of help is that both Oracle and Nucleus have some adherence to the SQL standard.
Just a thought :)
Cheers
Tim...
Robert Vollman
· 4 years ago
Good argument Eddie.
However, all things being equal, I believe it is better to choose an approach that fits the standard than not. (Remember: all things being equal).
It isn't unusual to have to develop something against a particular standard, and to document any exceptions. So at the very least using the standard approach will be less documentation work.
If you're like me and have to work with several databases, it is far easier to deal with implementations that are as close to the ANSI standard as possible.
Rob
Joe Celko
· 4 years ago
This is totally wrong and usually an excuse for "Cowboy Coding" by someone who got a certificate for only one product and has no education in RDMBS.
Us old farts remember when we had no standard database language or even a standard data model. It was a nightmare. Not only was the code locked into a single product, skills in one product did not move to another. The cost of having 1 or 2 programmers per product was one storng reason we moved to Standard SQL.
Code has to be maintained and ported. The only way I have seen to avoid this is to write code so bad, so proprietrary that either nobody wants it or it is cheaper to re-write it from scratch. This was called "job secure programming" in the old days
Remember that each new release of a product is a port. Is your vendor going to drop or change the standard parts of the product? No, not likely. But look at how many of the proprietary elements change from release to release.
Standards mean that programmers have a common language, so they agree on basic things like joins, data types. transaction control, etc. Consider how bad the outer joins were in Oracle and the Sybase family. Not only were both syntaxes weak, they did not have the same definition!
Donald
· 1 year ago
Totaler Schwachsinn!
Mit Leuten wie Ihnen hätte es sowas wie Java wohl nie gegeben.
I write in German to disrespect you! Try to translate it without dictonary.
By the way, you can think of a dictonary as a standard. In fact, every code is a standard. A clear agreement between to Zeichensätzen ;-).
Try coding without clear agreements.
Eddie Awad
· 1 year ago
Thank you all for commenting. You all have very good arguments.
All Comments
I still feel it's good to have as at least it keeps a little common ground between the engines. It's good to know that I can, and do, write queries against a number of different engines. I have to use different techniques for all of them, but I can do it.
Currently I have to help people write SQL against a Nucleus data warehouse. I've never even logged on to one. The reason I can provide some level of help is that both Oracle and Nucleus have some adherence to the SQL standard.
Just a thought :)
Cheers
Tim...
Good argument Eddie.
However, all things being equal, I believe it is better to choose an approach that fits the standard than not. (Remember: all things being equal).
It isn't unusual to have to develop something against a particular standard, and to document any exceptions. So at the very least using the standard approach will be less documentation work.
If you're like me and have to work with several databases, it is far easier to deal with implementations that are as close to the ANSI standard as possible.
Rob
This is totally wrong and usually an excuse for "Cowboy Coding" by someone who got a certificate for only one product and has no education in RDMBS.
Us old farts remember when we had no standard database language or even a standard data model. It was a nightmare. Not only was the code locked into a single product, skills in one product did not move to another. The cost of having 1 or 2 programmers per product was one storng reason we moved to Standard SQL.
Code has to be maintained and ported. The only way I have seen to avoid this is to write code so bad, so proprietrary that either nobody wants it or it is cheaper to re-write it from scratch. This was called "job secure programming" in the old days
Remember that each new release of a product is a port. Is your vendor going to drop or change the standard parts of the product? No, not likely. But look at how many of the proprietary elements change from release to release.
Standards mean that programmers have a common language, so they agree on basic things like joins, data types. transaction control, etc. Consider how bad the outer joins were in Oracle and the Sybase family. Not only were both syntaxes weak, they did not have the same definition!
Mit Leuten wie Ihnen hätte es sowas wie Java wohl nie gegeben.
I write in German to disrespect you! Try to translate it without dictonary.
By the way, you can think of a dictonary as a standard. In fact, every code is a standard. A clear agreement between to Zeichensätzen ;-).
Try coding without clear agreements.
Now, I'm off learning some German...