Wer regelmäßig mit Claude oder einem anderen Sprachmodell Code schreibt, kennt das Problem: Die KI liefert technisch korrekten Code, aber er sieht aus, als hätte ihn jemand anderes geschrieben. Andere Einrückung, andere Namenskonvention, kein SET NOCOUNT ON, Datumsliterale im falschen Format, MONEY statt DECIMAL(19,4). Funktioniert – passt aber nicht zum Bestand.
Bisher habe ich das gelöst, indem ich zu Beginn jeder Konversation meine Konventionen reingeprompted habe. Ein paar Sätze über Spaltennamen, ein Hinweis zur Fehlerbehandlung, ein Beispiel für meinen Header-Kommentar. Das funktioniert, kostet aber jedes Mal Zeit und ist fehleranfällig: Vergisst man eine Regel, schreibt Claude wieder Code, den man hinterher umformatieren muss.
Seit einigen Monaten gibt es dafür eine bessere Lösung: Skills.
Was ist ein Skill?
Ein Skill ist im Kern ein Ordner mit einer Markdown-Datei namens SKILL.md. Darin steht zweierlei: oben eine Beschreibung, wann der Skill greifen soll, und darunter die eigentlichen Anweisungen, wie Claude in dem Kontext arbeiten soll. Optional kommen Hilfsskripte, Referenzdateien oder Vorlagen dazu.
Der entscheidende Mechanismus: Skills werden nicht manuell aktiviert. Claude entscheidet anhand der Beschreibung selbst, ob ein Skill zur aktuellen Anfrage passt, und lädt ihn dann automatisch. Wer also einen Skill sesoft-tsql installiert hat und Claude bittet, eine Stored Procedure zu schreiben, bekommt Code nach den hinterlegten Regeln – ohne dass er die Regeln noch einmal nennen muss.
Aufbau einer minimalen SKILL.md:
---
name: sesoft-tsql
description: Verwende diesen Skill, wenn T-SQL-Code für
Microsoft SQL Server geschrieben oder geprüft werden soll.
---
# T-SQL-Konventionen
- Schlüsselwörter großgeschrieben
- Führende Kommas in der SELECT-Liste
- Datumsliterale immer im Format YYYYMMDD
- ...
Mehr ist es nicht. Die Eleganz liegt darin, dass das eine reine Textdatei ist – versionierbar, lesbar, ohne Abhängigkeiten. Kein Plugin-System, kein Code, keine Installation im klassischen Sinn.
Was bringt das konkret?
Drei Dinge, die für Entwickler den Unterschied machen.
Erstens: Reproduzierbarkeit. Was einmal im Skill steht, gilt in jeder Konversation. Wer drei Wochen lang nicht an einem Projekt war und dann zurückkommt, muss seine eigenen Konventionen nicht neu erklären. Der Skill ist das Gedächtnis.
Zweitens: Sauberer Übergang von altem zu neuem Code. Wer Bestandscode pflegt, weiß, wie wichtig Konsistenz ist. Eine Stored Procedure, die nach anderen Regeln formatiert ist als ihre Nachbarn, ist später schwerer zu lesen und zu warten. Ein Skill sorgt dafür, dass neuer KI-generierter Code zum bestehenden passt – nicht andersherum.
Drittens: Ein Skill ist editierbar. Wenn man merkt, dass Claude an einer bestimmten Stelle immer wieder vom Stil abweicht, ergänzt man die Regel im Skill. Das ist kein Modelltraining, kein Fine-Tuning, kein Vendor-Lock. Es ist eine Markdown-Datei, die mitwächst.
Wo wirken Skills überhaupt?
Hier wird es interessant – und wer sich nicht klarmacht, wo welcher Skill greift, ärgert sich später. Es gibt vier Orte, an denen Claude läuft, und sie verhalten sich unterschiedlich.
claude.ai im Browser und die Claude Desktop App teilen sich die Skills. Wer einen Skill als ZIP unter Customize → Skills im Web hochlädt, findet ihn nach kurzer Wartezeit auch in der Desktop-App – sofern man mit demselben Konto angemeldet ist. Synchronisation läuft über die Cloud, nicht über das Dateisystem. Das ist die einfachste Variante und für die meisten Anwendungsfälle ausreichend.
Claude Code, das Kommandozeilenwerkzeug für agentisches Programmieren im Terminal, ist eine andere Welt. Skills liegen dort lokal als Datei unter ~/.claude/skills/<skill-name>/SKILL.md. Sie werden nicht aus dem Web synchronisiert. Wer also denselben Skill in der Desktop-App und in Claude Code nutzen will, muss ihn an beiden Stellen ablegen. Das ist ein bekannter Schwachpunkt, an dem Anthropic vermutlich noch arbeiten wird – im Moment ist es manuelle Arbeit.
Die Claude API ist nochmal ein eigenes Kapitel. Wer eigene Anwendungen gegen die API baut, muss Skills programmatisch übergeben oder als ZIP über einen separaten API-Aufruf hochladen. Für Entwickler, die mit dem Anthropic-SDK arbeiten, ist das machbar, aber es hat mit dem Browser-Upload nichts zu tun.
In den Mobile Apps sind Skills aktuell nicht verfügbar. Wer unterwegs auf dem Handy mit Claude arbeitet, fällt auf das Standardverhalten zurück.
Kurz gesagt: Web und Desktop sind ein Paar, alles andere ist getrennt.
Was Skills nicht ersetzen
Skills sind kein MCP. Wer Claude mit einer SQL-Server-Instanz, einem Postfach oder einer WordPress-Seite verbinden will, braucht weiterhin einen Connector oder einen MCP-Server. Skills sind reines Wissen – Regeln, Konventionen, Vorlagen –, keine Verbindung zu lebenden Systemen. Beides ergänzt sich, aber es ist nicht dasselbe.
Auch ersetzen Skills kein Nachdenken. Wer eine grobe Konvention im Skill hinterlegt und dann Code generiert, ohne ihn zu lesen, bekommt grobe Ergebnisse. Skills heben das Grundniveau, sie ersetzen nicht das Code-Review.
Und jetzt zum konkreten Beispiel
Ich habe für mich zwei Skills gebaut: einen für Blog-Inhalte (an dem dieser Text gerade entsteht) und einen für T-SQL gegen SQL Server. Letzteren nenne ich sesoft-tsql. Drin steht alles, was bei mir seit Jahren Standard ist: führende Kommas, usp_-Präfix für Stored Procedures, Datumsliterale im YYYYMMDD-Format, DECIMAL(19,4) statt MONEY, DATETIME2 statt DATETIME, SET NOCOUNT ON und SET XACT_ABORT ON in jeder Prozedur, TRY/CATCH mit sauberem ROLLBACK, Header-Kommentar mit History-Tabelle. Dazu DMV-Snippets für die typischen Performance-Fragen und ein Linked-Server-Pattern für Joins gegen Dynamics NAV.
Der Skill ist ein erster Wurf. Ich werde ihn die nächsten Tage selbst durcharbeiten, an meinen Bestandsdatenbanken abgleichen und an den Stellen schärfen, wo ich merke, dass meine reale Praxis von dem abweicht, was ich aufgeschrieben habe. Erst danach binde ich ihn produktiv ein.
---
name: sesoft-tsql
description: Verwende diesen Skill, wenn T-SQL-Code für Microsoft SQL Server geschrieben, geprüft, optimiert oder erklärt werden soll. Trigger sind Anfragen nach Stored Procedures, Views, Functions, Triggern, Indizes, DMV-Abfragen, Performance-Analysen, ETL-Skripten, Linked-Server-Queries, Datenbank-Wartungsskripten oder T-SQL-Refactoring. Auch zu verwenden, wenn SQL Server im Kontext von Access-Migration, Dynamics NAV, JTL WaWi oder anderen typischen Datenschäfer-Projekten relevant wird. NICHT verwenden für reine MySQL-, PostgreSQL- oder SQLite-Anfragen ohne SQL-Server-Bezug.
---
# T-SQL und SQL Server Konventionen (Datenschäfer)
## Zielumgebung
- Microsoft SQL Server, primär Versionen 2016 bis 2022, gelegentlich Express Edition.
- Typische Einsatzkontexte: SQL-Server-Backend für migrierte Access-Anwendungen, ETL gegen Microsoft Dynamics NAV und andere ERPs (Linked Server), eigenständige Fachdatenbanken für KMU.
- Collation in der Regel `Latin1_General_CI_AS` oder `SQL_Latin1_General_CP1_CI_AS`. Bei Joins über Datenbanken hinweg auf Collation-Konflikte achten.
- Sprache der Daten und Bezeichner: Deutsch ist erlaubt und üblich, Umlaute in Bezeichnern werden vermieden.
## Formatierung
- Schlüsselwörter **GROSSGESCHRIEBEN**: `SELECT`, `FROM`, `WHERE`, `INNER JOIN`, `GROUP BY`, `ORDER BY`.
- Ein Attribut pro Zeile in der `SELECT`-Liste, eingerückt mit vier Leerzeichen.
- Komma am Zeilenanfang (führendes Komma), nicht am Ende. Erleichtert Auskommentieren einzelner Spalten.
- Joins immer explizit (`INNER JOIN`, `LEFT JOIN`), niemals impliziter Join über `WHERE`.
- Aliase kurz und sprechend, immer mit `AS` für Spalten, ohne `AS` für Tabellen.
- Tabellenaliase in Kleinbuchstaben, 1–4 Zeichen.
Beispielformat:
```sql
SELECT
k.intKdNummer AS KundeNr
,k.strKdName AS KundeName
,SUM(p.curPosBetrag) AS UmsatzGesamt
FROM dbo.tblKunde AS k
INNER JOIN dbo.tblPosition AS p
ON p.fiPosKunde = k.idKunde
WHERE k.bitKdAktiv = 1
AND p.dtmPosBelegdatum >= '20250101'
GROUP BY
k.intKdNummer
,k.strKdName
ORDER BY UmsatzGesamt DESC;
```
## Namenskonventionen
- Tabellen: Präfix `tbl`, PascalCase, Singular: `tblKunde`, `tblRechnung`, `tblPosition`.
- Primärschlüssel: `id<Tabelle>`, z. B. `idKunde`, `idRechnung`. Konsistent innerhalb einer Datenbank bleiben.
- Andere Tabellenspalten: `<DatentypAbk><Präfix><Tabelle>`. `<Präfix>` ist eine naheliegende Abkürzung der Tabelle (`Pos` aus Position, `Kd` aus Kunde), damit jede Spalte in der Datenbank einen eindeutigen Namen erhält. Datentyp-Abkürzungen:
- `str` = `VARCHAR(<=255)`
- `mem` = `VARCHAR(MAX)`
- `dtm` = `DATE` / `DATETIME2` (niemals `DATETIME` in Neuanlagen)
- `dbl` = `FLOAT`
- `int` = `INT`
- `bit` = `BIT`
- `ts` = `ROWVERSION` (für optimistisches Locking, nicht für Uhrzeiten – Uhrzeiten sind immer `dtm`)
- `cur` = `DECIMAL(19,4)` oder `DECIMAL(18,2)` (für Währungsbeträge)
- Kein `BIGINT` als Reflex. Nur einsetzen, wenn fachlich wirklich mehr als 2 Mrd. Datensätze zu erwarten sind.
- Fremdschlüssel: `fi<Präfix><andereTabelle>`, z. B. `fiPosKunde` in `tblPosition` verweist auf `idKunde` in `tblKunde`.
- Stored Procedures: `proc<Bereich><Aktion>`, z. B. `procRechnungErstellen`. Niemals Präfix `sp_` (Konflikt mit System-Procs).
- Views:
- `view<Bereich><Inhalt>` für operative Daten (z. B. für Formulare oder andere Prozeduren), Beispiel: `viewKundeAktiv`.
- `stat<Bereich><Inhalt>` für aggregierte Auswertungen, typischerweise Richtung Excel-Export, Beispiel: `statKundeUmsatzJahr`.
- Functions: `func<Zweck>`, z. B. `funcKalenderWoche`.
- Trigger: `trg<Tabelle><Ereignis>`, z. B. `trgRechnungUpd`. `<Ereignis>` ist `Ins`, `Upd`, `Del` oder eine Kombination wie `InsUpd`.
- Indizes: `idx<Tabelle><Spalten>`, eindeutige Indizes `ua<Tabelle><Spalten>`, gefilterte Indizes mit Suffix `_F`.
- Schemas: `dbo` ist Standard. Fachliche Trennung über zusätzliche Schemas (`stg` für Staging, `etl`, `report`) ist erwünscht, wenn das Projekt es hergibt.
## Datentypen
- **Geld:** `DECIMAL(19,4)` oder `DECIMAL(18,2)` je nach Genauigkeit, niemals `MONEY` (Rundungsprobleme, schlechtes Verhalten bei Berechnungen). `FLOAT` für Geldbeträge nur in Bestandscode tolerieren, Neuanlagen immer `DECIMAL`.
- **Datum/Zeit:** `DATE` für reine Datumsangaben, `DATETIME2(0)` oder `DATETIME2(3)` für Zeitstempel, niemals `DATETIME` in Neuentwicklungen.
- **Boolesche Werte:** `BIT`, mit Standardwert `0` oder `1` und `NOT NULL`, sofern fachlich nicht eine Drei-Wertigkeit nötig ist.
- **Texte:** `VARCHAR` statt `NVARCHAR`, meistens nur normale deutsche Umlaute notwendig. Längen begründet wählen, nicht reflexartig `VARCHAR(MAX)`.
- **Schlüssel:** `INT IDENTITY(1,1)` als Default. `UNIQUEIDENTIFIER` nur, wenn fachlich oder verteilungstechnisch nötig.
- **Strings vermeiden, wo Typen passen:** kein `VARCHAR(10)` für ein Datum, kein `VARCHAR(1)` für ein BIT.
## Datumsliterale und Vergleiche
- Datumsliterale immer im Format `'YYYYMMDD'` (z. B. `'20250114'`), niemals `'14.01.2025'` oder `'2025-01-14'`. Das `YYYYMMDD`-Format ist sprach- und collation-unabhängig.
- Datumsbereiche mit halboffenen Intervallen: `WHERE Belegdatum >= '20250101' AND Belegdatum < '20260101'`. Niemals `BETWEEN` für Datumsbereiche, das führt zu Fehlern bei `DATETIME`-Endpunkten.
- Keine Funktionen auf indizierten Spalten in der `WHERE`-Klausel. Statt `WHERE YEAR(Belegdatum) = 2025` immer das halboffene Intervall verwenden – sonst SARGability futsch.
## Stored-Procedure-Vorlagen
Es gibt zwei Grundvorlagen. Welche zum Einsatz kommt, hängt vom Szenario ab:
- **Transaktional (Alles-oder-nichts).** Für produktive Prozeduren im laufenden Betrieb ("tagsüber"), die von Formularen oder anderen Prozeduren aufgerufen werden. Fehler führen zu `ROLLBACK` und werden an den Aufrufer durchgereicht.
- **Block-resilient (ETL/Wartung).** Für datenverarbeitende Prozeduren im Batch ("nachts"), bei denen ein Fehler in einem DML-Block die restlichen Blöcke nicht abbrechen darf. Jeder Block hat sein eigenes `TRY/CATCH`, Fehler werden geloggt, die Prozedur läuft weiter.
### Vorlage 1: Transaktional (Alles-oder-nichts)
```sql
CREATE OR ALTER PROCEDURE dbo.procBereichAktion
@Parameter1 INT,
@Parameter2 VARCHAR(50) = NULL,
@strBenutzer VARCHAR(50) = NULL
AS
BEGIN
SET NOCOUNT ON;
-- XACT_ABORT: bei Laufzeitfehlern Transaktion deterministisch zurückrollen
-- und Fehler an Aufrufer (Prozedur/VBA) weiterreichen statt im Halbzustand laufen lassen.
SET XACT_ABORT ON;
DECLARE
@strFunktion VARCHAR(128) = 'procBereichAktion',
@strSchritt VARCHAR(255),
@memSQL VARCHAR(MAX) = NULL,
@dtmStart DATETIME,
@intDauerInSekunden INT,
@bitPrint BIT = 0;
SET @strBenutzer = ISNULL(@strBenutzer, ORIGINAL_LOGIN());
SET @strSchritt = 'Start procBereichAktion';
SET @dtmStart = GETDATE();
BEGIN TRY
BEGIN TRANSACTION;
-- Fachliche Logik hier.
-- @strSchritt vor jedem relevanten DML-Block aktualisieren,
-- damit der Logger im CATCH weiss, wo's geknallt hat.
COMMIT TRANSACTION;
END TRY
BEGIN CATCH
IF XACT_STATE() <> 0
ROLLBACK TRANSACTION;
-- Logging ist jetzt ausserhalb der abgebrochenen Transaktion
-- und ueberlebt den Rollback.
SET @intDauerInSekunden = DATEDIFF(SECOND, @dtmStart, GETDATE());
EXEC dbo.procFehlerProtokoll @strFunktion, @strBenutzer, @strSchritt, @memSQL, @intDauerInSekunden, NULL, @bitPrint;
THROW; -- Fehler an Aufrufer weiterreichen
END CATCH;
END;
GO
```
### Vorlage 2: Block-resilient (ETL/Wartung)
```sql
CREATE OR ALTER PROCEDURE dbo.procBereichAktion
@Parameter1 INT,
@Parameter2 VARCHAR(50) = NULL,
@strBenutzer VARCHAR(50) = NULL
AS
BEGIN
SET NOCOUNT ON;
-- XACT_ABORT: bei Laufzeitfehlern aktuellen Block deterministisch zurueckrollen.
-- Kombiniert mit TRY/CATCH pro DML laeuft die Prozedur trotzdem weiter.
SET XACT_ABORT ON;
DECLARE
@strFunktion VARCHAR(128) = 'procBereichAktion',
@strSchritt VARCHAR(255),
@memSQL VARCHAR(MAX) = NULL,
@dtmStart DATETIME,
@intDauerInSekunden INT,
@bitPrint BIT = 1;
SET @strBenutzer = ISNULL(@strBenutzer, ORIGINAL_LOGIN());
-- Pro DML-Block:
SET @strSchritt = 'Op tblXyz.spalten: Quelle/Zweck';
IF @bitPrint = 1 PRINT CONVERT(VARCHAR(19), SYSDATETIME(), 121) + ' ' + @strSchritt;
SET @dtmStart = GETDATE();
BEGIN TRY
-- Fachliche Logik hier (INSERT/UPDATE/DELETE)
END TRY
BEGIN CATCH
SET @intDauerInSekunden = DATEDIFF(SECOND, @dtmStart, GETDATE());
EXEC dbo.procFehlerProtokoll @strFunktion, @strBenutzer, @strSchritt, @memSQL, @intDauerInSekunden, NULL, @bitPrint;
-- kein THROW: Prozedur laeuft mit naechstem Block weiter
END CATCH;
-- weitere DML-Bloecke nach gleichem Muster
END;
GO
```
### Infrastruktur-Prozedur `dbo.procFehlerProtokoll`
Wird in beiden Vorlagen verwendet und ist in jeder Datenbank vorhanden. Schreibt in eine zentrale Fehlertabelle. Signatur:
```
@strFunktion VARCHAR(128),
@strBenutzer VARCHAR(50),
@strSchritt VARCHAR(255),
@memSQL VARCHAR(MAX),
@intDauerInSekunden INT,
@intRowCount INT,
@bitPrint BIT
```
### Grundregeln für jede Prozedur
- `SET NOCOUNT ON` immer.
- `SET XACT_ABORT ON` bei allem, was Transaktionen anfasst.
- Fehlerbehandlung mit `TRY/CATCH` und sauberem `ROLLBACK`.
- `CREATE OR ALTER` statt `CREATE` plus separatem `ALTER` – seit SQL Server 2016 Standard.
## Header-Kommentar
Vor jeder Stored Procedure, Function, View und jedem Trigger ein Header-Kommentar:
```sql
/*-----------------------------------------------------------------------------
Objekt : dbo.procRechnungErstellen
Zweck : Erzeugt eine Rechnung inkl. Positionen aus einem Auftrag.
Autor : Sönke Schäfer / Der Datenschäfer
Erstellt : 2025-01-14
Aufrufer : procAuftragAbschliessen, externer ETL-Job
Hinweise : Erwartet, dass alle Positionen eines Auftrags freigegeben sind.
History : 2025-01-14 SeS Erstanlage
-----------------------------------------------------------------------------*/
```
## Performance und Diagnose
Für Performance-Analysen und Wartung sind die Standard-DMVs gesetzt. Wenn der Anwender nach langsamen Queries, Indizes oder Wartung fragt, auf diese Patterns zurückgreifen statt frei zu improvisieren:
- **Fehlende Indizes:** `sys.dm_db_missing_index_group_stats`, `sys.dm_db_missing_index_groups`, `sys.dm_db_missing_index_details` – mit `improvement_measure = avg_total_user_cost * avg_user_impact * (user_seeks + user_scans)` als Sortierkriterium.
- **Index-Fragmentierung:** `sys.dm_db_index_physical_stats(...)` mit Modus `LIMITED`, ab 5 % `REORGANIZE`, ab 30 % `REBUILD`.
- **Ungenutzte Indizes:** `sys.dm_db_index_usage_stats`, gefiltert auf `user_seeks = 0 AND user_scans = 0 AND user_lookups = 0 AND user_updates > 0`. Vorsicht: nach Server-Restart sind die Werte zurückgesetzt – Aussage erst nach mehreren Tagen Laufzeit belastbar.
- **Teure Queries:** `sys.dm_exec_query_stats` joinen auf `sys.dm_exec_sql_text` und `sys.dm_exec_query_plan`, sortieren nach `total_worker_time` oder `total_logical_reads`.
- **Aktuell laufende Sessions:** `sys.dm_exec_requests` plus `sys.dm_exec_sessions`.
DMV-Ergebnisse immer mit Vorsicht interpretieren: Nicht jede „fehlende" Empfehlung ist eine gute Idee, und nicht jede Fragmentierung ist relevant.
## Linked Server (insbesondere Dynamics NAV)
- Joins über Linked Server vermeiden, wenn möglich. Stattdessen Daten erst mit `OPENQUERY` oder einer eigenen Stored Procedure auf der Remote-Seite einsammeln und lokal verarbeiten.
- `OPENQUERY` bevorzugen, weil der Filter remote ausgeführt wird:
```sql
SELECT *
FROM OPENQUERY(NAV_LINKED, '
SELECT No_, Name
FROM [dbo].[Customer]
WHERE Blocked = 0
');
```
- Vier-Teile-Notation (`SERVER.DATENBANK.SCHEMA.TABELLE`) nur für kleine, einfache Lookups.
- Bei NAV-typischen Spaltennamen mit Sonderzeichen (`No_`, `Document Type`) immer eckige Klammern.
## ETL-Patterns
- Staging-Schema (`stg`) für Rohdaten, fachliches Schema für aufbereitete Daten.
- Idempotenz: ETL-Jobs müssen wiederholbar sein, ohne Duplikate zu erzeugen. `MERGE` mit Vorsicht (es gibt bekannte Bugs in älteren Versionen) oder klassisches `DELETE`/`INSERT` im selben Transaktionsblock.
- Batch-Größen bei großen Datenmengen begrenzen (z. B. 10.000 Zeilen pro Schleife), um das Transaktionslog nicht zu sprengen.
- Logging in eine Job-Log-Tabelle: Startzeit, Endzeit, gelesene Zeilen, geschriebene Zeilen, Fehler.
## Anti-Patterns – diese Dinge nicht tun oder explizit warnen
- `SELECT *` in Produktionscode (außer in `EXISTS`-Subqueries).
- `NOLOCK` als reflexartige Performance-Lösung. Nur einsetzen, wenn der Anwender weiß, dass er Dirty Reads in Kauf nimmt – und dann lieber `READ COMMITTED SNAPSHOT` auf Datenbankebene erwägen.
- Cursor, wenn ein mengenorientierter Ansatz möglich ist. Cursor sind nicht generell verboten, aber begründungspflichtig.
- Skalare Funktionen in `WHERE`-Klauseln oder `SELECT`-Listen großer Resultsets – sie verhindern Parallelisierung und sind oft eine versteckte Performance-Bremse. Inline Table-Valued Functions sind die bessere Alternative.
- Implizite Typkonvertierungen, vor allem `NVARCHAR` gegen `VARCHAR` in Joins. Killt Indizes.
- Kommentarlose Magic Numbers im Code. Statuswerte (`Status = 3`) gehören dokumentiert oder besser als Lookup-Tabelle.
## Vor der Auslieferung prüfen
Bevor T-SQL-Code als fertig gilt:
1. Hat jede Stored Procedure den Header-Kommentar?
2. Ist `SET NOCOUNT ON` gesetzt?
3. Werden Datumsliterale im `YYYYMMDD`-Format verwendet?
4. Sind die `WHERE`-Klauseln SARGable (keine Funktionen auf Spalten)?
5. Wurde geprüft, ob ein Index unterstützt – oder eine Empfehlung zum Index mitgegeben?
6. Sind die Bezeichner konsistent zur bestehenden Datenbankkonvention?
7. Ist der Code idempotent, wo er es sein muss (ETL, Wartungsjobs)?
8. Wurden Anti-Patterns (`SELECT *`, `NOLOCK`, skalare Funktionen) bewusst vermieden oder begründet?Wer selbst seit Jahren mit Access, VBA und SQL Server arbeitet, hat genau dieses Wissen längst im Kopf. Es einmal sauber aufzuschreiben – nicht als Schulungsunterlage, sondern als Anleitung für eine KI – ist eine erstaunlich nützliche Übung. Man merkt dabei, an welchen Stellen die eigenen Konventionen lückenhaft sind oder mit den Jahren stillschweigend nebeneinander existieren. Der Skill ist also nicht nur Werkzeug, sondern auch Spiegel.
Wer in Ostholstein oder anderswo im norddeutschen Mittelstand mit ähnlichen Stacks arbeitet und Lust hat, über solche Themen zu sprechen, findet mich auf sesoft.de.
