I'm currently working on a project to replace some excel worksheets. There is a lot of industry specifics that change quite often and nobody really knows how things should be but every sure enough thinks they know how they shouldn't be.
- Maintainability - The business processes change frequently. There are like 3-5 different excel templates floating around.
- Agile - My boss wants visible changes every week (sometimes less).
- Structure - This application will work with several other systems for the entire business process.
Approach & Design:
The DB Schema we took was one where we defined some business logic in the database. EntityTypes, Properties of those types, and their values are stored in the database (each having their own table ofcourse).
Now, I originally thought about the typical approach, having an Estimate Table defining its properties, Bid Table, Joist Table, etc. (Each of these are EntityTypes by the way).
My boss wanted the DBSchema we're using now (See picture).
- Pros: (Theoretically) Adapts to the data allowing for later changes to be as simple as adding the data to the database.
- Cons: Overly complex. I have difficulty even getting my mind around this schema when trying to create the class that will handle it.
- Pros: Simplistic, Anyone without knowledge of the project will be able to pick it up in the future.
- Cons: Many Many Tables. Not what we have now.
I am currently retrieving the data using a class I made to represent an entity, then converting them into business model classes (Estimate, Bid, Joist...) to pass to the view. This obviously is extra work for the current schema, but I felt that the other way of having the view/controller parse through the model to determine how to display the data (making us only require a few views/controllers) seemed like bad design/programming (though I'm not entirely sure why). Am I correct thinking this schema/design is bad? If, so why?
My Boss wants this Schema because "it may be complex but once the programming is done no more changes should need done." Now obviously the way I'm doing this, that's not true. If I were to do it the way he wants I feel like I might fail to do so as I kept confusing myself with the complexities.
One of my boss's arguments is that you find yourself with a lot of NULL fields when you do the traditional schema (which I feel like you're doing it wrong if that's the case. Maybe in some instances but they have tables with like 30 columns where 10+ majority of the rows have a NULL value for that column).
Will doing all the programming for supporting the current Schema the way he desires be worth the theoretical simplicity to add things in the future? It's not all that much work to add a small feature to a class, and add the display to the view's template using knockout. Especially considering the project is being done in an Agile environment and doing all the work at once then having something to show for it doesn't sound very Agile to me, which is basically what would need done to code the complex classes and display them in the views, not to mention I'd have to code a bunch of HTML helpers (coupling them a bit with Knockout) in order to do this. So personally it sounds like it's just moving the work not saving any. Am I correct in this thought process?
I suggested the other day to switch to the other schema and use Entity Framework Code-First to make changes easier (as the way I'm doing it now I have the change the Business Models regardless. Code-First would theoretically allow me to not have to do the Database Changes as well).
My boss's main concern is that with a traditional schema the schema changes and then other systems will need updated as well. Whereas, he states that if we have the current schema then the other systems won't need updated if something changes in the database. Which I don't quite understand since how would it know how to deal with the data? Wouldn't it just mean it too would need complex coding/processes to back it up initially?
- Why is this schema design bad (if it is)? How can I argue this schema design is bad?
- If it is not a bad design, How can I better prepare myself for it? I do my best to Abstract classes/functionality and keep things with single responsibilities.
- If it is a bad design, How can I convince my boss to switch to my suggestion (assuming my suggestion is the best/only alternative)?
I understand the last two questions are a but subjective, so it's understandable if they are ignored.