SQL style guide

Re:SQL style guide by wvenable on Sunday October 09, 2016 @07:56PM (#12674231)

I completely agree with this. One should never plan to change database engines -- it just happens so rarely and it's such a big deal that planning for it is a waste of time.

It would be like coding in Java in such a way to make porting to C# easier in the future (or vice-versa).

[ Parent | on HN ]

Re:SQL style guide by berntb on Monday October 10, 2016 @05:23AM (#12676010)

So it isn't true anymore that quickly growing companies often need to go from one of the open source DBs to Oracle, after a decade or so?

(OK OK, that is a good problem to have.)

Right now I miss Oracle. (Never thought I'd say that. :-) )

[ Parent | on HN ]

Re:SQL style guide by wvenable on Monday October 10, 2016 @02:53PM (#12679065)

It's highly unlikely you could ever use generic enough SQL to go from open source DB or Oracle. Best case you wouldn't be getting the best performance out of your open source database and then you wouldn't be getting the best performance out of Oracle.

It's better to build for the platform you have than build for a mythical common platform that contains the minimum features of syntax of all of other DBMS (which probably doesn't exist). If you change DB platforms, you're just going to have to rebuild.

[ Parent | on HN ]

Re:SQL style guide by berntb on Monday October 10, 2016 @07:42PM (#12680702)

OK, your point is not that DB changes won't happen -- but that there is no use to prepare and think about it beforehand. Sounds reasonable to me.

[ Parent | on HN ]

Re:SQL style guide by Can_Not on Sunday October 16, 2016 @01:29PM (#12719731)

Kind of like premature optimization, "premature compatibility" can be a performance/labour-hours killer.

[ Parent | on HN ]