Een of meerdere queries
Een van de beheerders van de door mij gebouwde site kwam met de vraag of het zinvol/nuttig zou zijn om een aantal queries samen te voegen tot één grote query.
Ik weet niet of dit verstandig danwel handig is. Wie kan mij hier over adviseren?
De query grafisch voorgesteld:
De rechthoeken stellen de tabellen voor en de lijnen hiertussen de "ON"-relatie van de join.
------------ **** Aanvulling **** ----------------------
Ik heb een eerste aanzet gemaakt voor een query die alleen niet (juist) werkt.
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
SELECT
f.husb as man,
n_man.givn as voornaam_man,
n_man.spfx as tussenvoeg_man,
n_man.surn as achternaan_man,
f.wife as vrouw,
n_vrouw.givn as voornaam_vrouw,
n_vrouw.spfx as tussenvoeg_vrouw,
n_vrouw.surn as achternaam_vrouw,
kind.iid as kind,
k_name.givn as voornaam_kind,
k_name.spfx as tussenvoeg_kind,
k_name.surn as achternaam_kind
from
ftphp__fam as f
left join
ftphp__indi_name as n_man
on
n_man.iid = f.husb
left join
ftphp__indi_name as n_vrouw
on
n_vrouw.iid = f.wife
left join
ftphp__fam_chil as kind
on
kind.fid = f.fid
left join
ftphp__indi_name as k_name
on
k_name.iid = kind.iid
where
f.husb = 'i_I65689' and f.type = '*marr*'
f.husb as man,
n_man.givn as voornaam_man,
n_man.spfx as tussenvoeg_man,
n_man.surn as achternaan_man,
f.wife as vrouw,
n_vrouw.givn as voornaam_vrouw,
n_vrouw.spfx as tussenvoeg_vrouw,
n_vrouw.surn as achternaam_vrouw,
kind.iid as kind,
k_name.givn as voornaam_kind,
k_name.spfx as tussenvoeg_kind,
k_name.surn as achternaam_kind
from
ftphp__fam as f
left join
ftphp__indi_name as n_man
on
n_man.iid = f.husb
left join
ftphp__indi_name as n_vrouw
on
n_vrouw.iid = f.wife
left join
ftphp__fam_chil as kind
on
kind.fid = f.fid
left join
ftphp__indi_name as k_name
on
k_name.iid = kind.iid
where
f.husb = 'i_I65689' and f.type = '*marr*'
De ouders worden wel getoond maar de drie aanwezige kinderen niet.
Dit nadat ik de join van ftphp__fam_chil heb toegevoegd.
Gewijzigd op 05/01/2014 14:10:15 door George van Baasbank
Staan mannen en vrouwen in twee verschillende tabellen?
multi querymulti query .
Je kan ook altijd gebruik gaan maken van eenGewijzigd op 05/01/2014 15:03:13 door Bart Smulders
In andere gevallen is het een beetje persoonlijke voorkeur, en afhankelijk van de situatie.
Bijvoorbeeld bij een order heb je de klant- en verzendgegevens, de eventuele vaste kosten per order met daarnaast welke producten in de order staan.
In dat geval doe ik het met twee query's.
Ik kan niet zien waarom de query geen kinderen kan krijgen, misschien een verkeerde joinvoorwaarde?
Wat trouwens voor gezinnen waarbij 2 vrouwen of 2 mannen getrouwd zijn. Wie is dan wife en wie husb?
Wat is er trouwens tegen om duidelijke namen te gebruiken in je database?
child is maar 1 letter meer dan chil, maar wel een stuk zekerder voor de lezer dat het om een kind gaat.
indi zou iets te maken kunnen hebben met het land India of met een religie uit die regio, maar na 1 minuut bedacht ik dat het mogelijk een afko was voor Individu?
Voor Even en Sour ben ik er nog niet achter wat je daar mee zou kunnen bedoelen. Mogelijk een Event? en een Source?
De benaming van de diverse velden is wereldwijd door de Mormonen bepaald. Dit heeft allemaal met de standaard GEDCOM te maken.
Even = Event of te wel Gebeurtenis
Sour = Source of te wel Brondocument
Indi = Individu of te wel Persoon(sgegevens)
En toch ben ik het met ivo eens dat je tabelnamen onduidelijk zijn.
Je hebt helemaal gelijk. Alleen kan ik die tabellen niet wijzigen omdat de import/export van de data wereldwijd is vastgelegd.
George van Baasbank op 06/01/2014 16:51:54:
Alleen kan ik die tabellen niet wijzigen omdat de import/export van de data wereldwijd is vastgelegd.
Import en export van persoonsgegevens? Daarover is wereldwijd ook een en ander vastgelegd…
Maar is je vraag voldoende beantwoord?
Maar los van je juridische probleem: je past zo'n datacommunicatie-standaard toe tijdens het importeren en exporteren, maar verder hoeft niemand anders de veel betere interne structuur van je database te zien. Toch?