1. Set up the repo before touching a database
Before any hands-on SQL Server work started, I set up the local and remote repository structure — the same foundation every later phase's scripts, docs, and screenshots would live in. This mirrors how I started Project 1 (the PostgreSQL → SQL Server migration), keeping the same conventions across both projects.
- Created the local folder structure
- Initialized git, added a
.gitignore, made the first commit - Created the GitHub repository, connected the remote, and pushed
2. Folder structure
I kept the structure deliberately simple and predictable — one folder per concern, so anyone browsing the repo (including me, months later) can find what they're looking for without guessing:
sqlserver-enterprise-dba/
├── sql/ # T-SQL scripts, organized per phase
├── docs/ # Phase write-ups + the project blueprint
├── diagrams/ # Architecture / ERD diagrams
├── screenshots/ # Milestone screenshots, numbered sequentially
├── assets/ # Portfolio branding assets (logos, hero images)
└── backups/ # Local backup files (gitignored, not tracked)Each phase gets one markdown doc in docs/ and one T-SQL script in sql/phase-N-<name>/, with screenshots numbered continuously across the whole project rather than restarting per phase — that numbering is what ties a specific image back to the exact step it was taken at.
3. Git conventions
A few conventions I held to for the entire project, not just this phase: committing specific files rather than git add ., one commit per logical unit of work with a clear message, and keeping backups/ and raw data files out of version control entirely via .gitignore — a public repo is not the place for multi-gigabyte data dumps or, more importantly, any real credentials.
Redaction: since this repo is public, every committed SQL script uses placeholder values (like <STRONG_PASSWORD_HERE>) in place of real passwords, with a note that real values were used locally but never committed.
What's Next
With the repo skeleton pushed to GitHub and conventions established, Phase 1 moves into the actual database work: sourcing a real dataset, designing a deliberately unoptimized schema, and capturing a genuine baseline to improve against in later phases.