-
Notifications
You must be signed in to change notification settings - Fork 18
Design Goals
This section attempts to explain the design philosophy behind the Insight.Database.Schema library.
Don't try to make C# generate your SQL.
You can write a pretty good translator from C# to SQL for simple tables (see EF, Simple.Data, and previous incarnations of Insight.Database), but it won't work for complex projects. Eventually your code or your library will just start re-implementing all of SQL. Why? SQL is fine. If you aren't a SQL expert but you are a C# expert, don't reach for EF4, open SQL Management Studio, drag and drop your tables, and use the SQL it generates!
Don't write upgrades during development.
In your development process you will change your database hundreds of times. If you have multiple developers changing different parts of the schema at the same time, it gets really complicated. Upgrade scripts and code migrations have to be run in the proper order, and many times you refactor your database to remove functionality.
Insight.Database.Schema let's you just write the SQL that you want to be in your database, and it will automatically figure out what changes to make each time your run setup.
No, it can't handle every possible type of upgrade.
If we tried to, it would be impossible for developers to use easily. So there are cases when you have to write a manual upgrade. But you can probably wait to do that until the end of your project when the database changes are stable. And then it is just a minor SQL script and a little tweaking of the Insight Schema Registry.
Unfortunately, this code is a little bit older than Insight.Database, and has a lot more dependencies on SQL Server, so the internal code is not as clean. But it has been effectively running upgrades since 2003, so it's pretty reliable.