daher hier die eher nicht fachliche Frage.
Ich denke, das ist eine wichtige, administrative Fachfrage.
Man kann sie nur nicht einfach beantworten.
Es gibt einfache Erweiterungen und Erweiterungen mit weitreichenden Folgen. Es gibt einfach Datenmodelle, die nur aus Tabellenobjekten bestehen und die -aus Gründen- kaum oder wenig Constraints, Trigger usw. nutzen. Im Endeffekt haben einfache Datenmodelle nur wenig Abhängigkeiten der Datenbankobjekte untereinander. Solche Modelle kann man wahrscheinlich relativ unproblematisch erweitern, besonders, wenn es kompatible Änderungen sind, also im einfachsten Fall neue Spalten, die einfach mehr und unabhängige Informationen halten.
Ändert man Tabellen oder Spalten, zu denen es Abhängigkeiten gibt, kann das sehr problematisch werden. Bspw. die Typänderung einer Spalte, auf der ein Primär - oder Foreign Key definiert ist. Dies kann sofort zu Fehlern führen. Oder es kann im Verlauf zu Fehlern führen, wenn die Änderung ein Exclusiv Lock erfordert, das -sobald vergeben- andere Operationen an Updates hindert. Problematisch vor allem, je größer eine Tabelle ist, einfach weil die Dauer der Operationen zu einem Problem wird.
Ein Stickwort wäre "Breaking Change" oder "Non Braking Change", was aber eigentlich eher schon eine inkompatible Änderung beschreibt (Typänderung, Spaltenlöschung, ...)
Ich habe mit MS SQL da keine relevante praktische Erfahrung. In Oracle ist es bspw. so, das abhängige Objekte (automatisch!) neu kompiliert werden. Das ist jedoch nur dann erfolgreich, wenn die Änderung kompatibel zu dem bestehenden Modell ist. Das kann sogar die Änderung eines Spaltentyps sein, wenn der neue Typ mächtiger (kompatibel) zum alten ist (int auf bigint oder sowas). Das gilt aber nicht mehr, wenn die betroffenene Tabelle in einer Procedure verwendet wird, die mit statischen Variablen über die geänderten Spalten arbeitet. Hat man guten Code geschrieben, so sind diese Variablentypen so deklarieren, dass ihr Typ über den Typ der zugrundeliegenden Spalte definiert wird. Ansonsten gibt es Fehler. Das automatische Rekompilieren schlägt dann fehl. Die Prozedur wird unbrauchbar. Wird die Prozedur von weiteren Prozeduren verwendet -das macht man ja gerne so-, werden auch alle abhängigen Prozeduren unbrauchbar.
Bei anderen Herstellern muss man abhängige Objekte u.U. manuell(oder gescriptet) neu anlegen/refreshen (aus einem Script neu einspielen).
Wie es sich in MS SQL genau verhält, weiß ich nicht. Man sollte diese Änderungen auf jeden Fall testen, wie
@Dukel schon schrieb. Man kann auch gute Annahmen treffen, welche Änderungen problematisch sein können, indem man sich bei betroffenen Tabellen die abhängigen Objekte ausgeben lässt.
