Question

Almost all of the applications I write at work get their data from a central MSSQL database. This database has about 70 tables, and on average I’d say 25 or so columns per table. The database has developed over 5-10 years (I’m not entirely sure) and is full of idiosyncrasies and quirks. Foreign keys are irregularly implemented when it comes to naming and so on, as well as case and language mixing in table and column names.

I am not able to restructure the database itself as it would break a ton of backwards compatibility for applications needed in the daily work of most people in the office.

I’ve almost exclusively been using LINQ2SQL for interacting with the database and it works fine, but always requires a lot of manual joining of tables, either in some db repository or ‘inline’ when coding. So I’ve finally decided that I have to do something to once and for all ease the pain of working with this leviathan. This would preferably include implementing a clear naming scheme, joining relevant tables with foreign keys properly once and for all etc.

The three routes I can see are:

1. Creating a number of views, stored procedures and functions in the SQL to ease up my interaction with the DB. This obviously has the bonus of being usable in many languages, as opposed to a solution implemented in e.g. C#. The biggest drawback I can see here is that it would probably take a lot of time to do this properly, as well as being a bit harder to service a year down the road when I haven’t looked at the SQL queries for a while. I would also need to implement another DB abstraction step inside my applications as I wouldn’t want to work with just straight up DB calls (abstraction upon abstraction seems bad in this case, but maybe I’m wrong?)

2. Continuing on my LINQ2SQL road, but creating a once-and-for-all repository class that hides all the underlying tables in abstracted calls only. This idea seems more feasible in terms of development time, maintenance and single-point-abstraction.

3. Pulling off some EF4 reverse-engineering magic, using the designer to hook up relevant foreign keys and renaming table classes to fit my taste.

Any input on how this should/could be done, as well as any recommended reading you might have, would be most appreciated.

Answer 1

We have a very similar situation with our database. We went the EF route, but we used Code First. I know it sounds weird to use Code First when your database already exists, but due to the size of the tables and the number of tables, trying to do it all in the designer was not feasible.

You can use the “Reverse Engineer Code First” option in Entity Framework Power Tools to generate everything you need from your database.