3 ms·

There definitely is some tooling available to help - Redgate, many ORMs - but I agree that it's somewhat lacking. I think the bigger problem is cultural - many

by rossng 10y ago

There definitely is some tooling available to help - Redgate, many ORMs - but I agree that it's somewhat lacking. I think the bigger problem is cultural - many programmers either don't really understand databases/data modelling or they don't care about it. After all, you don't really have to worry about it when you're just starting out - almost any schema will work. That is, right up until you have to modify it. By the time it becomes an issue, the culture has crystallised and changing the database is too risky. For some reason, a lot of companies are largely unwilling to spend money on good database management/migration tools - even if they're paying a stack of cash for SQL Server.

cmdkeen 10y ago
Oh to be using SQL Server. Big old Oracle databases with lots of big packages and inter-related tables equals an impact analysis fun zone. If your release script doesn't measure in the tens of thousands of lines then you're living far too comfortably.
Maarten88 10y ago
> For some reason, a lot of companies are largely unwilling to spend money on good database management/migration tools - even if they're paying a stack of cash for SQL Server. If you use SQL Server, you can do database migrations using DACPAC files. DACPAC migrations are idempotent, so you can deploy to an existing database; it will add missing columns without deleting data etc. Personally I like manual migration scripts better, for my last projects I have been successful embedding these migration scripts in the source code of the application itself, so it integrates with source control , makes it very nice to use in test and development, and avoids many of the possible mistakes with separate code and database deployments. There are many open source tools for this in .NET: I've used FluentMigrator, SqlFu and Insight Database Schema, and they all worked well.

by rossng 10y ago

cmdkeen 10y ago

Oh to be using SQL Server. Big old Oracle databases with lots of big packages and inter-related tables equals an impact analysis fun zone. If your release script doesn't measure in the tens of thousands of lines then you're living far too comfortably.

Maarten88 10y ago

> For some reason, a lot of companies are largely unwilling to spend money on good database management/migration tools - even if they're paying a stack of cash for SQL Server. If you use SQL Server, you can do database migrations using DACPAC files. DACPAC migrations are idempotent, so you can deploy to an existing database; it will add missing columns without deleting data etc. Personally I like manual migration scripts better, for my last projects I have been successful embedding these migration scripts in the source code of the application itself, so it integrates with source control , makes it very nice to use in test and development, and avoids many of the possible mistakes with separate code and database deployments. There are many open source tools for this in .NET: I've used FluentMigrator, SqlFu and Insight Database Schema, and they all worked well.