Vorhandene Skills werden oft als Argument bei solchen Fragen angeführt. Wenn Unternehmen in den USA sich gezwungen sehen, auf "exotische" Programmiersprachen umzustellen, weil Großunternehmen den "Entwicklermarkt" lehr saugen, dann sind das die extremsten Blüten dieses Themas.
Aber bei
SQL? Egal welches System
SQL ist
SQL. Ein korreltiertes Update wird hier ein wenig anders als da formuliert, ein Upsert auch, aber der größte Teil ist identisch. Die Theorie zur Modellierung ist sowieso identisch. Man stellt in System A nicht alles auf den Kopf, was in System B gut und richtig war.
Irgendwann kommen natürlich die Feinheiten, das kann die Frage Sequence oder Autoinc betreffen, Lockverhalten und geht natürlich bis zur Programmierung (sofern die
DB das bietet). Und klar, da reicht es nicht, wenn ich zwischen jede Zeile PL/
SQL Code ein GO schreibe, damit ich TSQL habe. Trotzdem geht es auch in der
DB Programmierung immer wieder um die gleichen Techniken.
Am Ende muss es natürlich jemand geben, der eine
DB administriert. Das fordert m.E. am ehesten spezifische Skills. Aber ein Unternehmen mit 10 Entwicklern hat nicht gleichzeitig auch 10
DB Admins oder?
Den Datenbankanbieter zu wechseln, ist für den Entwickler m.E. kein Paradigmenwechsel, wie es vielleicht der Umstieg von einer Programmiersprache zur anderen sein kann. Im Gegenteil, viele
IDE treten an, mit beliebigen
DB zu arbeiten zu können, siehe Delphi.