(This answer has to do with the SQL statements themselves, and not with how they're deployed.)
I don't think I'd call it standard, but the most common approach I've seen is to use the "lowest common denominator" subset of SQL features that all your target platforms support. For example, if one of your target platforms doesn't support common table expressions, then you never use common table expressions.
That approach trades off some SQL flexibility and some performance for deployment flexibility.
Some SQL variations can be masked by macro substitution at build time. A macro might expand to a
DATE_ADD() function on one platform, and to a datetime value + an interval value on another. This can get you closer to optimal performance on all your target platforms for a slightly larger subset of SQL language features, but it can be a real pain to maintain.
The brute-force approach is to maintain a set of platform-specific differences for all your SQL statements. Simple statements like
SELECT * FROM TABLENAME can be shared on all platforms; more complex statements that leverage platform-specific features or syntax have different versions for each platform. In my experience, this approach requires a lot of automated testing to make sure all platforms behave the same.
I haven't thought much about it, but I think that the more platform-agnostic you want to be, the more likely you are to end up near the brute-force approach. How hard is that? Well, the most likely candidates are database CASE tools and database schema utilities, and there aren't very many of them that target more than a handful of current platforms. I reckon it's pretty danged hard.