In fact, I’d argue that you need to design precisely for specific relational database management systems because, let’s face it, they don’t implement the fundamentals in the same way. If you mess up the fundamentals, you’ve just messed up your entire design.
I love this article (Seriously. Well done, Grant.). It describes in yet another way how true portability is nothing more than a myth and a wish.
I've always said that NOT using the extremely powerful proprietary extensions of either SQL Server or Oracle (to name just a couple of RDBMSs) is like not using anything but the 4 basic functions on a scientific calculator because some people won't have anything but a 4 function calculator. Then, even after making the mistake of using only those proverbial 4 functions, they find out they're moving from a scientific calculator to one that uses reverse notation and even the 4 functions don't work the same way.
Oh, wait. No... Sorry. I forgot... we can use ORMs and things like Visual Studio where even a neophyte can make everthing
portable without any hits on performance. Well, except for most batch code... and some front end code... Ok... most front end code especially when you have to trick the defaults into not using NVARCHAR for everything that's character based. Yep... gotta love things like Linq.
At least we don't have to worry about how to write parameterized stored procedures to be portable. We're lucky that everyone got together and decided how to declare variables and what the datatypes will be, huh? Orms can take care of any shortcomings there, too, I'm sure.
And lets talk about the true backbone of all companies... I'm certainly happy the we don't have a portability problem with differences in Reporting code and other BI code. We can just skip using what's built in and buy some 3rd party software that works on everything, right? Where it doesn't, an Excel spreadsheet will always do the job especially if we export all of our data as XML, right? What the heck... avoid the middle man.
Let's really standardize and store all of our data in a nice simple XML only table. Then we won't even have portability problems with ETL or other communications. After all, it was built with true portability in mind. You don't even have to know what's in the files because it automatically tells you. You and your vendors don't have to talk about what the files will contain at all. It's like that wonderful EDI formatting but simpler.
Ok... I have to go now. :-P
is pronounced ree-bar and is a Modenism for R
First step towards the paradigm shift of writing Set Based code: Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
Although they tell us that they want it real bad, our primary goal is to ensure that we dont actually give it to them that way.
Although change is inevitable, change for the better is not.
Just because you can do something in PowerShell, doesnt mean you should. Helpful Links:
How to post code problemsHow to post performance problemsForum FAQs