Wenn Sie beispielsweise einen Datetime-Datentyp für eine Spalte in MSSQLServer2008 festgelegt haben, die Ihnen das erzeugte Datum liefert, ist es besser, wenn die .NET-Schicht das aktuelle Datum übergibt oder den Standardwert oder die Bindung der Spalte festlegt (getdate()).)Standardwert oder Bindung in MSSQL2008 empfehlenswerte Vorgehensweise?
Ich denke, es ist besser, SQL Server das Datum für solche Elemente behandeln zu lassen. Wenn der Client das Datum übergibt, können Probleme auftreten, wenn sich die Clients in unterschiedlichen Zeitzonen befinden oder wenn ein Client das falsche Datum auf seinem Computer festgelegt hat. Plus, es ist ein weniger Artikel, den Sie in den Befehl senden müssen.
Meine Sicht ist es macht nicht viel Unterschied, wo Sie es tun, solange die Methode konsistent ist.
Ich bezweifle, dass es überhaupt viel Unterschied in Bezug auf die Leistung oder Wartbarkeit macht.
Meine Präferenz ist es in der Datenbank mit getdate() zu erstellen, jedoch hat dies Probleme in der Vergangenheit verursacht, wenn ein ORM verwendet wird.
Ich würde diese Spalte mit einem Standardwert von GETDATE() erstellen, aber ich hätte die gespeicherte Prozedur den tatsächlichen Wert festgelegt. Ich denke, es ist eine schlechte Praxis, INSERT-Anweisungen zu haben, die nicht alle Spalten enthalten.
Bei Bedarf setze ich zu Beginn der Transaktion gerne eine Variable @RunDate auf GETDATE() und markiere alle CreateDate und LastChgDate Spalten mit @RunDate. Ich verwende niemals Daten in Primärschlüsseln, wenn sie also ein wenig oder gleich sind, spielt es keine Rolle. Ich denke, es ist besser, alles zu sehen, was der Benutzer zur selben Zeit erstellt/verändert hat.
Sie sollten in Betracht ziehen, die Zeiten in UTC anstelle der Server-Ortszeit zu schreiben. Auf diese Weise haben Sie keine Probleme, wenn Sie den Server von einer Zeitzone in eine andere verschieben müssen.
Als Beispiel bewegen wir unsere Server von Texas nach Kalifornien. Die Hauptproduktionsanwendung verwendet die UTC-Zeit für alle Datetime-Werte. Das Ticketing-System verwendet jedoch Serverzeit, und die Ticketing-App ändert die Werte in die lokale Zeit des Benutzers, vorausgesetzt, der Server befindet sich in Texas. Alles wird sehr verwirrend, wenn wir den Server nach Kalifornien bewegen und die Werte alle 2 Stunden frei sind.