Varchar ist hier absolut zu vernachlässigen, insbesonders da neuere Anwendungen grundsätzlich den Unicode-Varchar (nvarchar) verwenden.

Das Hauptproblem der meisten M$-Programmierer ist, das SQL's in den Programmen zusammengestrickt werden an Stelle vernünftige Command-Objekte mit Parametern zu verwenden.
Die gestrickten SQL's lassen sich in 99,9% in statische SQL's umbauen.

Aber hier ist teilweise die Historie Schuld, da ADO.NET mit 2.0 erst gute Designer zur Verfügung stellt, die diese Objekte generieren.

Ich war ja gerade erst bei einem Kunden, der genau diese Probleme auch hatte.
Ein paar wenige Änderungen von ständig gestrickten SQL's zu parametrierten Abfragen änderte die Antwortzeit von ca. 2 Sekunden auf quasi sofort!
Mehrere zusammengebaute Inserts mit einem InsertCommand ersetzt kann bis zu 1000 Inserts pro Sekunde an statt 10 schaffen!

Ausserdem geht beim zusammenbauen von SQL's auch nicht unwesentlich Zeit bereits auf dem Client verloren, da hier sehr extensives Stringhandling (Speicherverwaltung) betrieben wird.

Beispiel verdoppeln Hochkomma, ersetzen Dezimalkomma:

myStr = "select blabla from ... where key='" + string.replace(KeyChar, "'","''") + "' and KeyNum = " + string.replace(format(NumValue, "#.##"), ",", ".") ....
Anschließend muss ein Commandobjekt erstellt, ausgeführt und wieder verworfen werden, auch das dauert.

Und noch schlimmer wirds beim Zusammenbau von Update/Inserts.

Es kommt hier insbesoners auf die Methodik an. Aber die meisten kümmern sich ja eher um die schöne Gui als das, was dahinter steckt.
Auch einen SQL-Server kann ich da locker in die Knie zwingen.