Home/ Questions/Q 785075
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-14T20:49:00+00:00

Consider a database(MSSQL 2005) that consists of 100+ tables which have primary keys defined

  • 0

Consider a database(MSSQL 2005) that consists of 100+ tables which have primary keys defined to a certain degree. There are ‘relationships’ between tables, however these are not enforced with foreign key constraints.

Consider the following simplified example of typical types of tables I am dealing with. The are clear relations between the User and City and Province tables. However, they key issues is the inconsistent data types in the tables and naming conventions. 

User:
    UserRowId [int] PK
    Name [varchar(50)]
    CityId [smallint]
    ProvinceRowId [bigint]

City:
    CityRowId [bigint] PK
    CityDescription [varchar(100)]

Province:
    ProvinceId [int] PK
    ProvinceDesc [varchar(50)]

I am considering a rewrite of the application (in ASP.net MVC) that uses this data source as is similar in design to MVC storefront. However I am going through a proof of concept phase and this is one of the stumbling blocks I have come across.

  1. What are my options in terms of ORM choice that can be easily used and why?

  2. Should I even be considering an ORM? (The reason I ask this is that most explanations and tutorials all work with relatively cleanly designed existing databases, or newly created ones when compared to mine. I am thus having a very hard time trying to find a way forward with this problem)

  3. There is a huge amount of existing SQL queries, would a datamappper(eg IBatis.net) be more suitable since we could easily modify them to work and reuse the investment already made?

I have found this question on SO which indicates to me that an ORM can be used – however I get the impression that this a question of mapping?

Note: at the moment, the object model is not clearly defined as it was non-existent. The existing system pretty much did almost everything in SQL or consisted of overly complicated, and numerous queries to complete functionality. I am pretty much a noob and have zero experience around ORMs and MVC – so this an awesome learning curve I am on.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I agree with Ben.

    I was in this situation with a LAMP stack. An old dirty, bady coded website needed bringing up to scratch. It was literally the worst database I have seen, coupled with line after line of blind SQL execution.

    Job? Get rid of all that SQL very quickly and replace it with an abstraction. Which ORM? I found that using an existing ORM to fit over a bad database (most databases really) retrospectively is bad news. I think this is a problem with ORMs, they move database/storage concerns closer to the application … not further away.

    My Solution: A reflective ORM that used only the existing database state to work out what was going on. All selects, inserts, updates and what-not used views/stored proceedures to mask the cruddy database. It is powered by a linq-esque API just rewrite the grim SQL with. Boiled around 100klocs SQL statements down to less than 2klocs.

    pros: I can gradually port the database to a better structure behind the views and proceedures. IMHO this is how all databases should be organised, taking full advantage of the abstraction that SPs and views provide. I never want to see a single SQL statement (or an ORM masquerading as SQL) directly against a table.

    That’s my story. An overengineered way to slot a nice abstraction above an existing and crap database, without rewriting the database first, and without crowbaring an ORM into the mix making things much more complex.

    a hack, no doubt, but it works so well I am using it in projects where I can design the database from scratch anyway 😉

    • 0