[ASP.NET C#] Data van andere tabel halen bij query

[Verwijderd]

Ik zit met volgende vraag: ik heb twee tabellen, één hoofdtabel met alle data en één tabel die wat gegevens bevat. De hoofdtabel noemt 'Archive', de andere tabel noemt 'Rubriek'. Nu is het zo dat één kolom van archive onder de vorm van een int gegevens bevat die voorkomen in die tweede tabel (met twee kolommen, nl id en omschrijving).

Een voorbeeld:
In 'Archive' hebben we voor nummer 3 voor kolom rubriek. Dit moet overeenstemmen met 'productie', dit is de kolom 'omschrijving' uit de tabel 'Rubriek', wat in die tabel overeenstemt met nummer 3.



De vraag:
Hoe krijg ik in mijn gridview 'productie' te zien en niet het getal 3? Reden waarom de tabel zo opgebouwd is, omdat dit by design was (is oude tabel) en tweede is ruimtebesparing en derde is uitbreidbaarheid (moet uitgebreid kunnen worden, gebruikers moeten kunnen kiezen uit een selectie van de tabel 'Rubriek').


Hoe zouden jullie dit oplossen?

• Is er een oplossing zoals ik die beschrijf?
• Anders oplossen? Zoals database aanpassen? Wat betekend dat ik alle ints verander naar hun respectievelijke waarde. Ik moet dan een andere oplossing zien te vinden om gebruikers een beperkte restrictie te geven.
• Ander idee?

Ik heb al iets gevonden met Foreign Key Relationship, en dat levert min of meer wat ik wil (restrictie van mogelijke waarden. Om de tekst op mijn gridview te krijgen lukt dat nog niet...

[Arethusa]

Hoe ziet je sql query eruit en maak je gebruik van JOINS ?

[ Voor 41% gewijzigd door Arethusa op 20-07-2008 22:45 ]

[bastv]

binnen visual studio kan je een query designer starten en daar meerdere tabellen toevoegen.
tussen die 2 tabellen kan je relaties leggen.
zo krijg je automatisch joins.

--edit

het is ook beter om andere kolom namen te gebruiken (id voor alles gebruiken is niet echt netjes)
Probeer ook 1 taal aan te houden, je hebt nu Nederlands en Engels door elkaar.

tabel archive:
archive_id
rubriek_id

tabel rubriek:
rubriek_id
omschrijving

[ Voor 44% gewijzigd door bastv op 21-07-2008 10:23 ]

[ProGo]

Query:

SQL:

SELECT      Archive.id, rubriek.omschrijving
FROM        Archive

LEFT JOIN   rubriek
ON          Archive.rubriek = rubriek.id

Resultaat:

code:

id          omschrijving
----------- --------------------------------------------------
1           anders
2           administratie
3           diverse

Dit soort zaken kun je makkelijk oplossen met joins (left, right, inner, etc.)
Lees dit eens, gaat een wereld voor je open

[Verwijderd]

Super bedankt voor alle antwoorden en suggesties! Ik neem alles in overweging en zal dit toepassen. Ik kom hier terug bij succes of meerdere problemen
Thx!

[RobIII]

ProGo schreef op maandag 21 juli 2008 @ 11:48:

Dit soort zaken kun je makkelijk oplossen met joins (left, right, inner, etc.)
Lees dit eens, gaat een wereld voor je open

Misschien je eigen tip eens volgen dan
Waarom een LEFT join en geen INNER join?

[ Voor 5% gewijzigd door RobIII op 21-07-2008 18:23 ]

[Verwijderd]

RobIII schreef op maandag 21 juli 2008 @ 18:23:
Misschien je eigen tip eens volgen dan
Waarom een LEFT join en geen INNER join?

Valt wel wat voor te zeggen hoor: bij een LEFT join is in dit geval de archive tabel leidend, en verdwijnen er geen archive records wanneer het bijbehorende rubriek record niet meer of nog niet bestaat, het enige wat je dan mist is rubriek.omschrijving.
OK, niet het allermooiste database ontwerp wanneer dat kan, maar soms ben je afhankelijk van 't ontwerp van anderen (3rd party), of van een database engine die niet overweg kan met FK's, cascading deletes/updates, etc.

[Verwijderd]

Het is gelukt dankzij de tips van drie eerste replies! Hartelijk dank!

Verwijderd schreef op maandag 21 juli 2008 @ 19:16:
[...]
Valt wel wat voor te zeggen hoor: bij een LEFT join is in dit geval de archive tabel leidend, en verdwijnen er geen archive records wanneer het bijbehorende rubriek record niet meer of nog niet bestaat, het enige wat je dan mist is rubriek.omschrijving.
OK, niet het allermooiste database ontwerp wanneer dat kan, maar soms ben je afhankelijk van 't ontwerp van anderen (3rd party), of van een database engine die niet overweg kan met FK's, cascading deletes/updates, etc.

Is mijn database ontwerp niet zo goed? Heb je suggesties voor een beter ontwerp?

Hieronder heb ik een screenshot geplaatst van de query builder waarop het database ontwerp goed op af te lezen valt. De databases aan de rechterzijde (gebruikt door de inner joins) zijn erg klein (lees: maximum 15 rijen, met 3 kolommen).

[Cousin Boneless]

De namen rubriek en subrubriek doen vermoeden dat ze aan elkaar gerelateerd zijn. In dat geval zou je dit verband terug willen zien in de database structuur.
Maar een archief relationeel definieren kan problemen met zich meebrengen. Zie het argument bij de LEFT JOIN. Het is dus net hoe je het gaat gebruiken en wat er aan informatie verloren kan gaan, of in de loop der tijd kan wijzigen. Je wil bijvoorbeeld niet dat je archief met kassabonnen opeens andere prijzen weergeeft als het BTW tarief is gewijzigd.

[RobIII]

Verwijderd schreef op maandag 21 juli 2008 @ 19:16:
[...]
Valt wel wat voor te zeggen hoor: bij een LEFT join is in dit geval de archive tabel leidend, en verdwijnen er geen archive records wanneer het bijbehorende rubriek record niet meer of nog niet bestaat, het enige wat je dan mist is rubriek.omschrijving.

Persoonlijk zet ik dan liever een 'deleted' bit ergens in de rubriek. Op die manier heb je ook geen last van missende 'rubriek.omschrijving'-problematiek Daarbij is een LEFT join doorgaans duurder dan een INNER join.

Maar, true, soms kan het niet anders of ben je afhankelijk van derden.

[ Voor 5% gewijzigd door RobIII op 21-07-2008 23:13 ]

[Verwijderd]

Verwijderd schreef op maandag 21 juli 2008 @ 21:09:
Is mijn database ontwerp niet zo goed? Heb je suggesties voor een beter ontwerp?

Mijn opmerking ging niet over jouw datamodel (al valt jouw rubriek/subrubriek idee nog wel wat uit te normaliseren, maar of dat de moeite waard is?).
Ik reageerde op RobIII's vraag over LEFT join i.p.v. INNER join, en gaf daar wat in de praktijk voorkomende voordelen voor.

Maar jij hebt zo te zien voor INNER joins gekozen, en als 't daarmee werkt zou ik daar absoluut niet van afwijken!

[bastv]

paar kleine dingetjes

-ik zou voor rubriek 1 tabel gebruiken en een extra kolom rubriek_parent maken
-de tabelnaam "wie" is een beetje raar
-de kolommen waar een id in staat ook aangeven met een id zoals : eigenaar_id en rubriek_id

verder ziet het er wel netjes uit voor een beginner