Best practices to maximize portability in SQL Server 2016
When it comes to developing the prototype of a solution, often the technologies has not been decided yet and might not be the same that will be used in the finished product.
In this scenarios I tend to use Microsoft SQL Server writing the queries as standard as possible to simplify the eventual migration to another server.
Is there a way or some known practice to enforce the use of standard SQL over T-SQL dialect directly in SQL Server or via SQL Server Management Studio (SSMS)?
sql-server sql-server-2016 migration sql-standard
edited 33 mins ago
jadarnel27
3,3201329
asked 3 hours ago
s.demuro
212
New contributor
s.demuro is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |
When it comes to developing the prototype of a solution, often the technologies has not been decided yet and might not be the same that will be used in the finished product.
In this scenarios I tend to use Microsoft SQL Server writing the queries as standard as possible to simplify the eventual migration to another server.
Is there a way or some known practice to enforce the use of standard SQL over T-SQL dialect directly in SQL Server or via SQL Server Management Studio (SSMS)?
sql-server sql-server-2016 migration sql-standard
edited 33 mins ago
jadarnel27
3,3201329
asked 3 hours ago
s.demuro
212
New contributor
s.demuro is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
1
Portability is a nice textbook goal, but it rarely happens in practice. When you have a choice between standard syntax (<>) and non-standard (!=), where there is no compromise on performance or maintainability, I always choose standard. But when it comes at other costs, or there is no standard equivalent I tap out and go proprietary. The things you give up just for the ability to later completely switch platforms wholesale just aren’t worth it imho.
– Aaron Bertrand♦
2 hours ago
2
The only time portability is a realistic goal is when you’re writing an app that needs to integrate with multiple platforms simultaneously because your customers use different platforms. Even then, unless you want functionality to be limited and performance to be terrible on all platforms, I would ship packages meant to take advantage of features of individual platforms.
– Aaron Bertrand♦
2 hours ago
add a comment |
When it comes to developing the prototype of a solution, often the technologies has not been decided yet and might not be the same that will be used in the finished product.
In this scenarios I tend to use Microsoft SQL Server writing the queries as standard as possible to simplify the eventual migration to another server.
Is there a way or some known practice to enforce the use of standard SQL over T-SQL dialect directly in SQL Server or via SQL Server Management Studio (SSMS)?
sql-server sql-server-2016 migration sql-standard
edited 33 mins ago
jadarnel27
3,3201329
asked 3 hours ago
s.demuro
212
New contributor
s.demuro is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
When it comes to developing the prototype of a solution, often the technologies has not been decided yet and might not be the same that will be used in the finished product.
In this scenarios I tend to use Microsoft SQL Server writing the queries as standard as possible to simplify the eventual migration to another server.
Is there a way or some known practice to enforce the use of standard SQL over T-SQL dialect directly in SQL Server or via SQL Server Management Studio (SSMS)?
sql-server sql-server-2016 migration sql-standard
sql-server sql-server-2016 migration sql-standard
edited 33 mins ago
jadarnel27
3,3201329
asked 3 hours ago
s.demuro
212
New contributor
s.demuro is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
edited 33 mins ago
jadarnel27
3,3201329
asked 3 hours ago
s.demuro
212
New contributor
s.demuro is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
edited 33 mins ago
jadarnel27
3,3201329
edited 33 mins ago
jadarnel27
3,3201329
edited 33 mins ago
jadarnel27
3,3201329
3,3201329
asked 3 hours ago
s.demuro
212
New contributor
s.demuro is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 3 hours ago
s.demuro
212
asked 3 hours ago
s.demuro
212
212
New contributor
s.demuro is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
s.demuro is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
s.demuro is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
1
Portability is a nice textbook goal, but it rarely happens in practice. When you have a choice between standard syntax (<>) and non-standard (!=), where there is no compromise on performance or maintainability, I always choose standard. But when it comes at other costs, or there is no standard equivalent I tap out and go proprietary. The things you give up just for the ability to later completely switch platforms wholesale just aren’t worth it imho.
– Aaron Bertrand♦
2 hours ago
2
The only time portability is a realistic goal is when you’re writing an app that needs to integrate with multiple platforms simultaneously because your customers use different platforms. Even then, unless you want functionality to be limited and performance to be terrible on all platforms, I would ship packages meant to take advantage of features of individual platforms.
– Aaron Bertrand♦
2 hours ago
add a comment |
1
Portability is a nice textbook goal, but it rarely happens in practice. When you have a choice between standard syntax (<>) and non-standard (!=), where there is no compromise on performance or maintainability, I always choose standard. But when it comes at other costs, or there is no standard equivalent I tap out and go proprietary. The things you give up just for the ability to later completely switch platforms wholesale just aren’t worth it imho.
– Aaron Bertrand♦
2 hours ago
2
The only time portability is a realistic goal is when you’re writing an app that needs to integrate with multiple platforms simultaneously because your customers use different platforms. Even then, unless you want functionality to be limited and performance to be terrible on all platforms, I would ship packages meant to take advantage of features of individual platforms.
– Aaron Bertrand♦
2 hours ago
1
1
Portability is a nice textbook goal, but it rarely happens in practice. When you have a choice between standard syntax (
<>) and non-standard (!=), where there is no compromise on performance or maintainability, I always choose standard. But when it comes at other costs, or there is no standard equivalent I tap out and go proprietary. The things you give up just for the ability to later completely switch platforms wholesale just aren’t worth it imho.– Aaron Bertrand♦
2 hours ago
Portability is a nice textbook goal, but it rarely happens in practice. When you have a choice between standard syntax (
<>) and non-standard (!=), where there is no compromise on performance or maintainability, I always choose standard. But when it comes at other costs, or there is no standard equivalent I tap out and go proprietary. The things you give up just for the ability to later completely switch platforms wholesale just aren’t worth it imho.– Aaron Bertrand♦
2 hours ago
2
2
The only time portability is a realistic goal is when you’re writing an app that needs to integrate with multiple platforms simultaneously because your customers use different platforms. Even then, unless you want functionality to be limited and performance to be terrible on all platforms, I would ship packages meant to take advantage of features of individual platforms.
– Aaron Bertrand♦
2 hours ago
The only time portability is a realistic goal is when you’re writing an app that needs to integrate with multiple platforms simultaneously because your customers use different platforms. Even then, unless you want functionality to be limited and performance to be terrible on all platforms, I would ship packages meant to take advantage of features of individual platforms.
– Aaron Bertrand♦
2 hours ago
add a comment |
3 Answers
3
active
oldest
votes
Not really.
There is SET FIPS_FLAGGER 'FULL'.
This prints out a warning for non standard SQL - but some caveats are
- I am unsure what specific standard this uses (and suspect it may be SQL 92)
- From a quick test this doesn't complain about use of the
+operator for string concatenation or proprietary functions such asGETDATE()so it doesn't seem very comprehensive.
answered 3 hours ago
Martin Smith
61.4k10166245
add a comment |
Do not enforce STD SQL.
Decide first which DBMS you will use according to the needs of your project, and take advantage of it.
answered 3 hours ago
McNets
14.7k41857
add a comment |
User Aaron Bertrand made some comments that align well with my thoughts on your question. This is more of a frame challenge than an answer to your specific question, but I think it's valuable to consider in this context.
Portability is a nice textbook goal, but it rarely happens in practice.
If you have to change platforms at some point, there will be changes needed to the application, the database, and probably many other things. If you can be somewhat "platform agnostic" without too much effort, that's fine. But it's really a bad business decision to use that as a design goal.
There are many places online where people discuss the downsides or programming this way, here's one of them that I find pretty compelling:
Database Abstraction Layers Must Die!
The Portability Fallacy
The author uses an argument I hear all the time: If you use a good abstraction layer, it'll be easy to move from $this_database to $other_database down the road.
That's bullshit. It's never easy.
In any non-trivial database backed application, nobody thinks of switching databases as an easy matter. Thinking that "the conversion will be painless" is a fantasy.
Good engineers try to select the best tools for the job and then do everything they can to take advantage of their tool's unique and most powerful features. In the database world, that means specific hints, indexing, data types, and even table structure decisions. If you truly limit yourself to the subset of features that is common across all major RDBMSes, you're doing yourself and your clients a huge disservice.
That's no different from saying "I'm doing to limit myself to the subset of PHP that's the same in Perl and C, because I might want to switch languages one day and 'painlessly' port my code."
That just doesn't happen.
The cost of switching databases after an application is developed and deployed is quite high. You have possible schema and index changes, syntax changes, optimization and tuning work to re-do, hints to adjust or remove, and so on. Changing mysql_foo() to oracle_foo() is really the least of your problems. You're gonna touch most, if not all, of your SQL--or you'll at least need to verify it.
That doesn't sound "painless" to me.
answered 24 mins ago
jadarnel27
3,3201329
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "182"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
s.demuro is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f225918%2fbest-practices-to-maximize-portability-in-sql-server-2016%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
Not really.
There is SET FIPS_FLAGGER 'FULL'.
This prints out a warning for non standard SQL - but some caveats are
- I am unsure what specific standard this uses (and suspect it may be SQL 92)
- From a quick test this doesn't complain about use of the
+operator for string concatenation or proprietary functions such asGETDATE()so it doesn't seem very comprehensive.
answered 3 hours ago
Martin Smith
61.4k10166245
add a comment |
Not really.
There is SET FIPS_FLAGGER 'FULL'.
This prints out a warning for non standard SQL - but some caveats are
- I am unsure what specific standard this uses (and suspect it may be SQL 92)
- From a quick test this doesn't complain about use of the
+operator for string concatenation or proprietary functions such asGETDATE()so it doesn't seem very comprehensive.
answered 3 hours ago
Martin Smith
61.4k10166245
add a comment |
Not really.
There is SET FIPS_FLAGGER 'FULL'.
This prints out a warning for non standard SQL - but some caveats are
- I am unsure what specific standard this uses (and suspect it may be SQL 92)
- From a quick test this doesn't complain about use of the
+operator for string concatenation or proprietary functions such asGETDATE()so it doesn't seem very comprehensive.
answered 3 hours ago
Martin Smith
61.4k10166245
Not really.
There is SET FIPS_FLAGGER 'FULL'.
This prints out a warning for non standard SQL - but some caveats are
- I am unsure what specific standard this uses (and suspect it may be SQL 92)
- From a quick test this doesn't complain about use of the
+operator for string concatenation or proprietary functions such asGETDATE()so it doesn't seem very comprehensive.
answered 3 hours ago
Martin Smith
61.4k10166245
edited 3 hours ago
answered 3 hours ago
Martin Smith
61.4k10166245
answered 3 hours ago
Martin Smith
61.4k10166245
answered 3 hours ago
Martin Smith
61.4k10166245
61.4k10166245
add a comment |
add a comment |
Do not enforce STD SQL.
Decide first which DBMS you will use according to the needs of your project, and take advantage of it.
answered 3 hours ago
McNets
14.7k41857
add a comment |
Do not enforce STD SQL.
Decide first which DBMS you will use according to the needs of your project, and take advantage of it.
answered 3 hours ago
McNets
14.7k41857
add a comment |
Do not enforce STD SQL.
Decide first which DBMS you will use according to the needs of your project, and take advantage of it.
answered 3 hours ago
McNets
14.7k41857
Do not enforce STD SQL.
Decide first which DBMS you will use according to the needs of your project, and take advantage of it.
answered 3 hours ago
McNets
14.7k41857
edited 2 hours ago
answered 3 hours ago
McNets
14.7k41857
answered 3 hours ago
McNets
14.7k41857
answered 3 hours ago
McNets
14.7k41857
14.7k41857
add a comment |
add a comment |
User Aaron Bertrand made some comments that align well with my thoughts on your question. This is more of a frame challenge than an answer to your specific question, but I think it's valuable to consider in this context.
Portability is a nice textbook goal, but it rarely happens in practice.
If you have to change platforms at some point, there will be changes needed to the application, the database, and probably many other things. If you can be somewhat "platform agnostic" without too much effort, that's fine. But it's really a bad business decision to use that as a design goal.
There are many places online where people discuss the downsides or programming this way, here's one of them that I find pretty compelling:
Database Abstraction Layers Must Die!
The Portability Fallacy
The author uses an argument I hear all the time: If you use a good abstraction layer, it'll be easy to move from $this_database to $other_database down the road.
That's bullshit. It's never easy.
In any non-trivial database backed application, nobody thinks of switching databases as an easy matter. Thinking that "the conversion will be painless" is a fantasy.
Good engineers try to select the best tools for the job and then do everything they can to take advantage of their tool's unique and most powerful features. In the database world, that means specific hints, indexing, data types, and even table structure decisions. If you truly limit yourself to the subset of features that is common across all major RDBMSes, you're doing yourself and your clients a huge disservice.
That's no different from saying "I'm doing to limit myself to the subset of PHP that's the same in Perl and C, because I might want to switch languages one day and 'painlessly' port my code."
That just doesn't happen.
The cost of switching databases after an application is developed and deployed is quite high. You have possible schema and index changes, syntax changes, optimization and tuning work to re-do, hints to adjust or remove, and so on. Changing mysql_foo() to oracle_foo() is really the least of your problems. You're gonna touch most, if not all, of your SQL--or you'll at least need to verify it.
That doesn't sound "painless" to me.
answered 24 mins ago
jadarnel27
3,3201329
add a comment |
User Aaron Bertrand made some comments that align well with my thoughts on your question. This is more of a frame challenge than an answer to your specific question, but I think it's valuable to consider in this context.
Portability is a nice textbook goal, but it rarely happens in practice.
If you have to change platforms at some point, there will be changes needed to the application, the database, and probably many other things. If you can be somewhat "platform agnostic" without too much effort, that's fine. But it's really a bad business decision to use that as a design goal.
There are many places online where people discuss the downsides or programming this way, here's one of them that I find pretty compelling:
Database Abstraction Layers Must Die!
The Portability Fallacy
The author uses an argument I hear all the time: If you use a good abstraction layer, it'll be easy to move from $this_database to $other_database down the road.
That's bullshit. It's never easy.
In any non-trivial database backed application, nobody thinks of switching databases as an easy matter. Thinking that "the conversion will be painless" is a fantasy.
Good engineers try to select the best tools for the job and then do everything they can to take advantage of their tool's unique and most powerful features. In the database world, that means specific hints, indexing, data types, and even table structure decisions. If you truly limit yourself to the subset of features that is common across all major RDBMSes, you're doing yourself and your clients a huge disservice.
That's no different from saying "I'm doing to limit myself to the subset of PHP that's the same in Perl and C, because I might want to switch languages one day and 'painlessly' port my code."
That just doesn't happen.
The cost of switching databases after an application is developed and deployed is quite high. You have possible schema and index changes, syntax changes, optimization and tuning work to re-do, hints to adjust or remove, and so on. Changing mysql_foo() to oracle_foo() is really the least of your problems. You're gonna touch most, if not all, of your SQL--or you'll at least need to verify it.
That doesn't sound "painless" to me.
answered 24 mins ago
jadarnel27
3,3201329
add a comment |
User Aaron Bertrand made some comments that align well with my thoughts on your question. This is more of a frame challenge than an answer to your specific question, but I think it's valuable to consider in this context.
Portability is a nice textbook goal, but it rarely happens in practice.
If you have to change platforms at some point, there will be changes needed to the application, the database, and probably many other things. If you can be somewhat "platform agnostic" without too much effort, that's fine. But it's really a bad business decision to use that as a design goal.
There are many places online where people discuss the downsides or programming this way, here's one of them that I find pretty compelling:
Database Abstraction Layers Must Die!
The Portability Fallacy
The author uses an argument I hear all the time: If you use a good abstraction layer, it'll be easy to move from $this_database to $other_database down the road.
That's bullshit. It's never easy.
In any non-trivial database backed application, nobody thinks of switching databases as an easy matter. Thinking that "the conversion will be painless" is a fantasy.
Good engineers try to select the best tools for the job and then do everything they can to take advantage of their tool's unique and most powerful features. In the database world, that means specific hints, indexing, data types, and even table structure decisions. If you truly limit yourself to the subset of features that is common across all major RDBMSes, you're doing yourself and your clients a huge disservice.
That's no different from saying "I'm doing to limit myself to the subset of PHP that's the same in Perl and C, because I might want to switch languages one day and 'painlessly' port my code."
That just doesn't happen.
The cost of switching databases after an application is developed and deployed is quite high. You have possible schema and index changes, syntax changes, optimization and tuning work to re-do, hints to adjust or remove, and so on. Changing mysql_foo() to oracle_foo() is really the least of your problems. You're gonna touch most, if not all, of your SQL--or you'll at least need to verify it.
That doesn't sound "painless" to me.
answered 24 mins ago
jadarnel27
3,3201329
User Aaron Bertrand made some comments that align well with my thoughts on your question. This is more of a frame challenge than an answer to your specific question, but I think it's valuable to consider in this context.
Portability is a nice textbook goal, but it rarely happens in practice.
If you have to change platforms at some point, there will be changes needed to the application, the database, and probably many other things. If you can be somewhat "platform agnostic" without too much effort, that's fine. But it's really a bad business decision to use that as a design goal.
There are many places online where people discuss the downsides or programming this way, here's one of them that I find pretty compelling:
Database Abstraction Layers Must Die!
The Portability Fallacy
The author uses an argument I hear all the time: If you use a good abstraction layer, it'll be easy to move from $this_database to $other_database down the road.
That's bullshit. It's never easy.
In any non-trivial database backed application, nobody thinks of switching databases as an easy matter. Thinking that "the conversion will be painless" is a fantasy.
Good engineers try to select the best tools for the job and then do everything they can to take advantage of their tool's unique and most powerful features. In the database world, that means specific hints, indexing, data types, and even table structure decisions. If you truly limit yourself to the subset of features that is common across all major RDBMSes, you're doing yourself and your clients a huge disservice.
That's no different from saying "I'm doing to limit myself to the subset of PHP that's the same in Perl and C, because I might want to switch languages one day and 'painlessly' port my code."
That just doesn't happen.
The cost of switching databases after an application is developed and deployed is quite high. You have possible schema and index changes, syntax changes, optimization and tuning work to re-do, hints to adjust or remove, and so on. Changing mysql_foo() to oracle_foo() is really the least of your problems. You're gonna touch most, if not all, of your SQL--or you'll at least need to verify it.
That doesn't sound "painless" to me.
answered 24 mins ago
jadarnel27
3,3201329
answered 24 mins ago
jadarnel27
3,3201329
answered 24 mins ago
jadarnel27
3,3201329
answered 24 mins ago
jadarnel27
3,3201329
3,3201329
add a comment |
add a comment |
s.demuro is a new contributor. Be nice, and check out our Code of Conduct.
s.demuro is a new contributor. Be nice, and check out our Code of Conduct.
s.demuro is a new contributor. Be nice, and check out our Code of Conduct.
s.demuro is a new contributor. Be nice, and check out our Code of Conduct.
Thanks for contributing an answer to Database Administrators Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f225918%2fbest-practices-to-maximize-portability-in-sql-server-2016%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
Portability is a nice textbook goal, but it rarely happens in practice. When you have a choice between standard syntax (
<>) and non-standard (!=), where there is no compromise on performance or maintainability, I always choose standard. But when it comes at other costs, or there is no standard equivalent I tap out and go proprietary. The things you give up just for the ability to later completely switch platforms wholesale just aren’t worth it imho.– Aaron Bertrand♦
2 hours ago
2
The only time portability is a realistic goal is when you’re writing an app that needs to integrate with multiple platforms simultaneously because your customers use different platforms. Even then, unless you want functionality to be limited and performance to be terrible on all platforms, I would ship packages meant to take advantage of features of individual platforms.
– Aaron Bertrand♦
2 hours ago