Design adeguato per i modelli

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: Beh, la maggior parte dei progetti di DB scatta per non ripetere i dati (colonne) w / in una tabella o tra tabelle correlate. Scegli questo tipo di normalizzazione a meno che le prestazioni successive non siano un problema. Una volta, un caso estremo, avevamo uno schermo popolato da ben 40 tavoli. Abbiamo de-normalizzato molto qui per ridurre i join dei tavoli.

Efficient: probabilmente un rigetto assumendo che la colonna type sia indicizzata.

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?

Vedo che ReplaceRule viene utilizzato sia in document che in section ; due istanze della stessa classe con il "tipo" come proprietà. E questo felicemente coincide con l'idea del tavolo in alto.

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

Mi raccomando calorosamente di prendersi del tempo per progettare un risparmio di tempo cool. Voglio che il mio design esprima il più possibile realtà / dominio. Questo può essere in conflitto con la struttura di classi necessaria per dettagli e dati in profondità. Questo è spesso il caso che mi aspetto.

Cerco di progettare classi fondamentali che rendano la manipolazione dei dati espressiva e facile. Le classi tendono ad essere piccole, composte e stratificate. Da qualche parte questo incontra altre classi che iniziano con il linguaggio e le funzioni del dominio. Quindi, se gli utenti vogliono pensare a diversi tipi di regole, lasciali fare. Ma può essere implementato con una sola classe, forse.

Qual è il significato formale di "ricerca più specifica" che fai sulle sezioni? Se sono concettualmente uguali non sono più specifici. È un errore di progettazione separare concettualmente due cose identiche, di solito significa che la tua analisi non ha catturato bene la funzionalità o lo scopo di quella cosa. È corretto cercare di ottenere la perfetta separazione delle preoccupazioni, ma se la preoccupazione è la stessa per entrambe le classi, non è necessario separarle. Secondo me (ma ho una piccola conoscenza del tuo dominio / progetto) dovresti usare solo una classe e una tabella con una colonna per mantenere il design semplice e facile da usare. Ad esempio, che senso ha costringere un programmatore a scegliere tra due diverse regole separate se sono intercambiabili? È solo una piccola complicazione che aggiungi senza motivo.

Dato che questa situazione ti sta confondendo e stai affrontando strani problemi, proverei con un approccio diverso: un documento potrebbe essere una composizione della sezione, in questo modo avrai due classi diverse che porteranno a due diverse tabelle sul tuo database ciascuna memorizzando informazioni diverse (presumo che tu stia utilizzando un pattern ORM) e che la ReplaceRule possa essere usata solo con una classe.