[DB] Vraagjes database-opzet en -aanpak in C# MVC4 + EF

[F.West98]

Hallo,

Ik zit met ene klein probleempje hoe ik een db ga aanpakken. Ik heb wel een idee, maar ik vraag me af hoe ik dat codetechnisch ga aanpakken.
Situatie
Ik heb een tabel met producten. Elk product heeft z'n eigen licentie-systeem, dus daar heb je aparte tabellen voor nodig. Elke licentie wordt gekoppeld aan een user.
Nu had ik dit bedacht:
Producttabel, en dan de koppeling naar de licentietabel is adhv de productnaam (in de vorm Licentie_[productnaam]). Maar dat kan ik niet met indexes en FK's oplossen voor zover ik weet, en dus (toch?) ook niet in Entity Framework, terwijl ik erg fan ben van Lazy Loading. Ik zou graag willen dat als ik een product heb, ik automatisch de juiste licentietabel eraan gekoppeld heb....

Iemand eerste adviesen/tips hoe ik moet denken en wat een oplossing zou kunnen zijn?

[ThomasG]

Wat is er precies verschillend aan de licentie tabellen? Je kunt ze wellicht samenvoegen tot één tabel. Je krijgt dan waarschijnlijk een overhead, maar dat is de enigste manier. Er zijn helaas - of helaas, er is een goede reden voor - geen conditional foreign keys.

[F.West98]

ThomasG schreef op donderdag 30 mei 2013 @ 22:51:
Wat is er precies verschillend aan de licentie tabellen? Je kunt ze wellicht samenvoegen tot één tabel. Je krijgt dan waarschijnlijk een overhead, maar dat is de enigste manier. Er zijn helaas - of helaas, er is een goede reden voor - geen conditional foreign keys.

De ene licentie is bijvoorbeeld enkel een licentiecode, andere licenties kunnen weblinkjes naar CMS zijn met user/pass. Andere is weer een regfile voor installatie. Andere is weer een .exe voor installatie.
Er zijn veel soorten mogelijk en die kunnen later uitgebreid worden.

Je zou het kunnen zien als een extended koppeltabel tussen users en producten.
Users kunnen meerdere producten (hetzelfde) kopen, maar een product kan ook door meerdere mensen worden gekocht. n-n relatie dus, maar dan met variabele koppeltabel (gebaseerd op value in een veld)

Edit:
Het kan natuurlijk altijd handmatig (door gewoon handmatig de juiste tabel op te halen), maar dat vereist steeds extra code

[ Voor 23% gewijzigd door F.West98 op 30-05-2013 22:57 ]

[sig69]

Misschien dat je iets kan met Table per type inheritance?

[ThomasG]

F.West98 schreef op donderdag 30 mei 2013 @ 22:54:
[...]

De ene licentie is bijvoorbeeld enkel een licentiecode, andere licenties kunnen weblinkjes naar CMS zijn met user/pass. Andere is weer een regfile voor installatie. Andere is weer een .exe voor installatie.
Er zijn veel soorten mogelijk en die kunnen later uitgebreid worden

Dat kan dus worden samengevoegd naar één tabel. Je zult een soort compromis moeten doen. Ik weet niet wat je precies van plan was, maar de bestanden kun je beter niet in de tabel zelf opslaan. Je hebt in de tabel een veld die verwijst naar een pad (website, bestand, ed.). Je kunt dit met C# afhandelen. Wellicht dat je de licentiecode in het zelfde veld kwijt kunt, maar is niet helemaal netjes. Username en password kun je als het HTTP-auth is ook al in de url opslaan, anders een apart veld. Je zult dan misschien nog een ENUM veld kunnen gebruiken, om aan te geven wat voor type het is (website, bestand, licentie, ed.).

[F.West98]

sig69 schreef op donderdag 30 mei 2013 @ 22:59:
Misschien dat je iets kan met Table per type inheritance?

Heel handig!
Enige nadeel is:
- Bij proberen van maken van een ADO.NET model ging alles mis in m'n project. Models verdwenen, enz. enz.
- Je hebt dan voor elke licentie een nieuw product-item nodig. Helaas.

[sig69]

Hmm dat is jammer. Misschien is je datamodel er niet helemaal voor geschikt. Anyway, je hebt wel weer iets geleerd, wellicht dat het in de toekomst van pas komt.

[F.West98]

sig69 schreef op vrijdag 31 mei 2013 @ 10:49:
Hmm dat is jammer. Misschien is je datamodel er niet helemaal voor geschikt. Anyway, je hebt wel weer iets geleerd, wellicht dat het in de toekomst van pas komt.

Ik denk dat ik t wel in een model kan oplossen, maar niet direct met mappings, maar meer handmatig.
Ik kan de licentiekoppeling ook een handmatige get set meegeven. Ik zal er vanmiddag nog eens naar kijken

[Megamind]

Je kan een property maken op je model object welke een select statement doet. Ik neem dat je Code First gebruikt, dan kan je het simpel aanpassen. Als je EDMX gebruikt dan zal je even moeten graven.

[F.West98]

Megamind schreef op vrijdag 31 mei 2013 @ 18:10:
Je kan een property maken op je model object welke een select statement doet. Ik neem dat je Code First gebruikt, dan kan je het simpel aanpassen. Als je EDMX gebruikt dan zal je even moeten graven.

Ik gebruik idd CF...
Ik had idd al zoiets in gedachten, maar ik moet nog even kijken hoe ik de set ga implementeren
Wait. Kan dat niet gewoon een CREATE TABLE zijn?

[Megamind]

Je hebt aan 1 tabel genoeg, maak daar een FK op de ProductID en dan heb je het toch?

En kijk ook eens naar Code-Migrations dan hoef je je geen zorgen te maken over CREATE TABLE statements of andere SQL meuk.

[ Voor 42% gewijzigd door Megamind op 31-05-2013 21:16 ]

[F.West98]

Megamind schreef op vrijdag 31 mei 2013 @ 21:16:
Je hebt aan 1 tabel genoeg, maak daar een FK op de ProductID en dan heb je het toch?

En kijk ook eens naar Code-Migrations dan hoef je je geen zorgen te maken over CREATE TABLE statements of andere SQL meuk.

Ik weet niet zeker of het moet, maar valt dat dynamisch te doen dmv een CMS-achtige oplossing? Dus gewoon code die een tabel aanmaakt. Als het niet moet is dit idd een oplossing.

edit:
Ik kan een ook een inherited oplossing maken. Een algemene licenties tabel die dan standaarddingen bevat en dan models die 't inheriten...

[ Voor 13% gewijzigd door F.West98 op 31-05-2013 22:47 ]

[Megamind]

Dat kan ook maar ik weet niet echt wat je daar mee opschiet, als je een aparte tabel maakt met een direct property naar je license-info tabel krijg je zoiets

Product Tabel
- Product Id
- Naam
- Etc
- FK naar License
- - License naam
- - License ID

Ik vind dat eerlijk gezegd duidelijker omdat je dan duidelijk bezig bent met license info, anders krijg je velden die niets met producten te maken hebben gemixt in je productentabel.

[F.West98]

Ik heb het nu werkend opgelost als volgt (bedankt voor alle hulp!):

C#:

public class Licentie {
    /* Random shit */
    public virtual Product product { get; set; } /* Product waarbij de licentie hoort */
    public virtual User user { get; set; } /* Koper */
}

public class Licentie_type1 : Licentie {
    public string type1_specific { get; set; }
    public string type1_specific2 { get; set; }
}

public class Licentie_type2 : Licentie {
    public string type2_specific { get; set; }
    public string type2_specific2 { get; set;}
}

Waarmee je, als het type niet bekend is ('aparte behandeling heeft'), alsvolgt alle properties en waardes krijgen:

C#:

string toreturn = "";
foreach ( Licentie licentie in licentie_list) {
    var props = licentie.GetType().GetProperties();
    toreturn += "<br><br>";
    foreach(var prop in props) {
        toreturn += prop.Name + " - " + prop.GetValue(licentie, null).ToString() + "<br>";
    }
}
return toreturn;

Uitbreidbaar dus. Of was er een nog betere oplossing?

[Megamind]

Als deze oplossing voor jou werkt is dat de "beste" oplossing Maar er zijn ook andere manieren op het probleem aan te pakken.

Je kon ook gewoon een enum maken met LicentieType, of als je dieper wilt normalizeren in je database. Nu met overerven zal het lastiger worden om dit in je database te krijgen natuurlijk.

[F.West98]

Megamind schreef op zaterdag 01 juni 2013 @ 16:47:
Als deze oplossing voor jou werkt is dat de "beste" oplossing Maar er zijn ook andere manieren op het probleem aan te pakken.

Je kon ook gewoon een enum maken met LicentieType, of als je dieper wilt normalizeren in je database. Nu met overerven zal het lastiger worden om dit in je database te krijgen natuurlijk.

Dat is waar, en waarschijnlijk is het minder compatibel als je in PHP dezelfde DB wil gebruiken, maar het werkt

[Verwijderd]

zou ook een enum pakken. 2 licentie classes die gelijk zijn qua properties maar toch anders.(niet echt fout maar zou het zelf niet doen)

normaliseer eens het hele model uit.

[ThomasG]

Ik denk dat het probleem is dat hij probeert te over-normaliseren. Dan krijg je problemen als dit, wat er vaak op wijst dat er iets fout is gegaan in je (normalisatie-)proces. Ik ben er vooralsnog niet van overtuigd waarom dit niet gewoon in één tabel zou kunnen, je slaat alleen paden naar websites/bestanden of een licentienummer op.

[F.West98]

ThomasG schreef op zaterdag 01 juni 2013 @ 17:31:
Ik denk dat het probleem is dat hij probeert te over-normaliseren. Dan krijg je problemen als dit, wat er vaak op wijst dat er iets fout is gegaan in je (normalisatie-)proces. Ik ben er vooralsnog niet van overtuigd waarom dit niet gewoon in één tabel zou kunnen, je slaat alleen paden naar websites/bestanden of een licentienummer op.

Op de achtegrond (daadwerkelijke DB) gaat het ook zo, maar het was enkel om het voor mij beheer- en ontwikkeltechnisch makkelijker (uiteindelijk) te maken.