Proper design for models

Question

I have a class called ReplaceRule this is used by 2 classes DocumentRuleViewModel and SectionRuleViewModel as a List<ReplaceRule> in both

Question 1: In my database implementation I have 2 distinct tables for each of the representations. Would it be more standard or efficient to have just 1 with a type column or is 2 perfectly acceptable despite similar structure?

Question 2: Should I go about making ReplaceRule an abstract class and making a DocumentRule and SectionRule model that inherits the ReplaceRule despite them being 100% identical and no perceived changes for the future?

I know in the time I took to write this question could have probably done all of this 3 times over but I'm curious on the decision making process of a more professional approach concerning Time vs implementing full Separation of Concerns

Edit- The basis for these 2 objects is that we have a document which you can do a regex search and replace on. Then we have individual sections which you may do more specific search and replaces on. All of this is automated to run when the document is imported. So the functionality should always mirror each other.

Edit Edit - To extend on the summary: Each document has their own tables Each Section has their own tables that link to a document with a unique ID for each section in the table

The Replace tables stores the ID of the target it wants to look at.

Currently there are 2 tables as to maintain foreign key integrity and 2 classes to query each individually.

The change I would be looking to make would be to have a document ID and Section ID column in 1 table with a type column that says which to use.

For the model it would be set with a type param that would be required in the constructor in order to query the correct setting

Hope this clarifies things

Answer 1

Question 1: In my database implementation I have 2 distinct tables for each of the representations. Would it be more standard or efficient to have just 1 with a type column or is 2 perfectly acceptable despite similar structure?

Standard: Well, most DB design shoots for not repeating data (columns) w/in a table nor across related tables. Go for this kind of normalization unless subsequent performance is an issue. One time, an extreme case, we had one screen populated by as many as 40 tables. We de-normalized a lot here to cut down on table joins.

Efficient: probably a toss up assuming the type column is indexed.

---

Question 2: Should I go about making ReplaceRule an abstract class and making a DocumentRule and SectionRule model that inherits the ReplaceRule despite them being 100% identical and no perceived changes for the future?

I'm seeing a ReplaceRule being used in both a document and a section; two instances of the same class with the "type" as a property. And this happily coincides with the one table idea above.

---

I'm curious on the decision making process of a more professional approach concerning Time vs implementing full Separation of Concerns

I quaff heartily of the taking time to design saves time coolaide. I want my design to express reality/domain as much as practicable. This can be in conflict with needed class structure for deep-down details and data. This is often the case I expect.

I try to design foundational classes making data manipulation expressive and easy. Classes tend to be small, composited, and layered. Somewhere this meets other classes that begin with domain language and functions. So if the users want to think of different kinds of rules, let them. But it can be implemented with a single class perhaps.

Answer 2

What's the formal meaning of "more specific search" that you do on sections? If they are conceptually the same they are not more specific. It's a design error to conceptually separate two identical things, usually it means that your analysis didn't capture well the functionality or the purpose of that thing. It's correct to try to achieve the perfect separation of concern but if the concern is the same for both classes you don't have to separate. In my opinion (but i have a little knowledge of your domain/project) you should use only one class and one table with a column to keep the design simple and easy to use. For example what's the point about forcing a programmer to pick from two different separate rules if they are interchangeable? It's just a little complication that you add for no reason.

Since this situation is getting you confused and you are facing strange problems I would try with a different approach: a document could be a composition of section, in this way you will have two different classes that will lead to two different tables on you database each storing different information(i'm assuming you are using a ORM pattern) and the ReplaceRule can be used only with one class.