Come progettare un modello imprevedibile?

Il modello che stai cercando si chiama EAV o Valore attributo dell'entità .

In questo schema si imposta una tabella con una riga per ogni attributo e un'altra tabella con valori per ciascuna combinazione di entità x attributo.

I valori vengono memorizzati come stringhe, ma puoi definire metadati nella tabella degli attributi per dire al sistema come analizzare la stringa, ad es. come una data o un intero. Se non disponi di metadati, rende difficile la convalida e l'ordinamento risulta errato.

EAV non è sempre il migliore in termini di prestazioni, ma funzionerà molto meglio di una gigantesca stringa JSON, soprattutto se devi ordinare o filtrare in base a questi attributi.

Non ho idea del perché ospedali, prigioni, case di cura, ecc. abbiano bisogno delle loro classi. Niente qui mi fa pensare che lo facciano. Perché non sono queste semplici istanze di InternshipProvider ?

Non tutto con un nome deve essere una classe. Hai bisogno di polimorfismo se un ospedale ha bisogno dello stesso metodo per avere un'implementazione diversa da una prigione. Altrimenti, queste classi sono inutili.

L'unica cosa "imprevedibile" che posso vedere qui è ciò che verrà chiamato il prossimo InternshipProvider . Mostrami un comportamento che deve essere diverso in base a quale InternshipProvider e lo ripenserò.

Vorrei andare per un dizionario di "Campi personalizzati"

public class InternshipProvider 
{
    public string Id {get;set;}
    public Dictionary<string,string> CustomFields {get;set;}
}

mappato alla seguente struttura di tabella

TABLE InternshipProvider
    varchar Id ('myguid')

TABLE CustomFields 
    varchar Id
    varchar ParentId ('myguid')
    varchar ParentType ('InternshipProvider')
    varchar Value
    varchar TypeToCastTo?

Puoi espandere questo ad altri tipi che richiedono campi personalizzati.

Quindi per le query puoi fare qualcosa sulla falsariga di ...

InternshipProviderList.Where(i=>i.CustomFields[keytosearch] == valuetosearchfor)

o qualche divertente sql dinamico

Ora ovviamente più complessa è la tua logica di query accettabile, più diventa complicato scrivere la query.

Puoi vedere come potresti inserire diverse funzioni per diversi comparatori e quindi magari ricorrere a loop su più clausole, magari capire come gestire AND vs OR, parentesi, occuparsi di null ecc. Ad un certo punto (abbastanza presto) hai bisogno di programmatori per scrivere la query.

Ho scoperto che di solito è più semplice assumere un programmatore per aggiungere la nuova logica richiesta in quel momento piuttosto che provare a scrivere un sistema generico in grado di gestire tutto E farlo in modo sufficientemente semplice da consentire agli utenti non è necessario essere formati nel linguaggio di meta-programmazione del sistema.

Non sono sicuro che direi al cliente che, forse, menziona il rischio, ma dai loro quello che vogliono.

Non c'è motivo per soluzioni contorte come il salvataggio di JSON. Hai un tavolo dove ogni riga è un fornitore di stage. Quindi disponi di una tabella con le proprietà del fornitore di stage, in cui ogni riga descrive una proprietà associata a un fornitore di stage tramite chiave esterna.

E se una proprietà a sua volta ha opzioni associate a uno specifico fornitore di stage, è sufficiente creare una tabella con le opzioni, con una chiave esterna per la proprietà del fornitore di stage.

È facile creare un modulo che aggiunge una riga a una tabella.