[Mysql] meerdere JOIN's in één, JOIN met WHERE argument

[Gerwin]

Ok, ik zal uit proberen te leggen wat ik van plan ben te maken door gebruik te maken van een Mysql database. Mijn voornemen is om een mysql systeem te ontwikkelen die misschien wat wel heeft van 'organische' trekjes.

Laat ik beginnen met de hoofstructuur van het alles. Het geheel is wat complexer, dus ik zou het eenfoudig houden. Neem aan dat ik vier verschillende soorten gegevens heb in vier verschillende tabellen. De tabellen noem ik A, B, C en D. Elke tabel bestaat uit een identificatienummer en de tekst van de gegevens. Ik heb dus vier tabellen (A t/m D) met velden (A-ID t/m D-ID) en tekst (A-TEXT t/m D-TEXT).

SQL:

CREATE TABLE IF NOT EXISTS `A` (
  `AID` int(11) unsigned NOT NULL,
  `A` char(11) NOT NULL,
  PRIMARY KEY  (`AID`),
  UNIQUE KEY `A` (`A`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

CREATE TABLE IF NOT EXISTS `B` (
  `BID` int(11) NOT NULL,
  `B` char(11) NOT NULL,
  PRIMARY KEY  (`BID`),
  UNIQUE KEY `B` (`B`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

CREATE TABLE IF NOT EXISTS `C` (
  `CID` int(11) NOT NULL,
  `C` char(11) NOT NULL,
  PRIMARY KEY  (`CID`),
  UNIQUE KEY `C` (`C`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

CREATE TABLE IF NOT EXISTS `D` (
  `DID` int(11) NOT NULL,
  `D` char(11) NOT NULL,
  PRIMARY KEY  (`DID`),
  UNIQUE KEY `D` (`D`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

Het idee is nu dat deze tabellen dynamisch aan elkaar gelinkt kunnen worden. Hiervoor heb ik tussen elke tabel een nieuwe tabel staan die de geldige combinaties aangeeft tussen deze twee tabellen. De 'geldige combinaties tabellen' zijn: AB, AC, AD, BA, BC, BD, CA, CB, CD, DA, DB EN DC.

SQL:

CREATE TABLE IF NOT EXISTS `AB` (
  `AID` int(11) NOT NULL,
  `BID` int(11) NOT NULL,
  UNIQUE KEY `AID` (`AID`,`BID`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

CREATE TABLE IF NOT EXISTS `AC` (
  `AID` int(11) NOT NULL,
  `CID` int(11) NOT NULL,
  UNIQUE KEY `AID` (`AID`,`CID`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

CREATE TABLE IF NOT EXISTS `AD` (
  `AID` int(11) NOT NULL,
  `DID` int(11) NOT NULL,
  UNIQUE KEY `AID` (`AID`,`DID`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

CREATE TABLE IF NOT EXISTS `BA` (
  `BID` int(11) NOT NULL,
  `AID` int(11) NOT NULL,
  UNIQUE KEY `BID` (`BID`,`AID`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

CREATE TABLE IF NOT EXISTS `BC` (
  `BID` int(11) NOT NULL,
  `CID` int(11) NOT NULL,
  UNIQUE KEY `BID` (`BID`,`CID`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

CREATE TABLE IF NOT EXISTS `BD` (
  `BID` int(11) NOT NULL,
  `DID` int(11) NOT NULL,
  UNIQUE KEY `BID` (`BID`,`DID`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

CREATE TABLE IF NOT EXISTS `CA` (
  `CID` int(11) NOT NULL,
  `AID` int(11) NOT NULL,
  UNIQUE KEY `CID` (`CID`,`AID`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

CREATE TABLE IF NOT EXISTS `CB` (
  `CID` int(11) NOT NULL,
  `BID` int(11) NOT NULL,
  UNIQUE KEY `CID` (`CID`,`BID`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

CREATE TABLE IF NOT EXISTS `CD` (
  `CID` int(11) NOT NULL,
  `DID` int(11) NOT NULL,
  UNIQUE KEY `CID` (`CID`,`DID`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

CREATE TABLE IF NOT EXISTS `DA` (
  `DID` int(11) NOT NULL,
  `AID` int(11) NOT NULL,
  UNIQUE KEY `DID` (`DID`,`AID`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

CREATE TABLE IF NOT EXISTS `DB` (
  `DID` int(11) NOT NULL,
  `BID` int(11) NOT NULL,
  UNIQUE KEY `DID` (`DID`,`BID`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

CREATE TABLE IF NOT EXISTS `DC` (
  `DID` int(11) NOT NULL,
  `CID` int(11) NOT NULL,
  UNIQUE KEY `DID` (`DID`,`CID`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

In tabel A t/m D voeg ik allemaal twee een records toe:

SQL:

INSERT INTO `A` (`A-ID`,`A-TEXT`) VALUES (1,'eerste in A');
INSERT INTO `A` (`A-ID`,`A-TEXT`) VALUES (2,'tweede in A');
INSERT INTO `B` (`B-ID`,`B-TEXT`) VALUES (1,'eerste in B');
INSERT INTO `B` (`B-ID`,`B-TEXT`) VALUES (2,'tweede in B');
INSERT INTO `C` (`C-ID`,`C-TEXT`) VALUES (1,'eerste in C');
INSERT INTO `C` (`C-ID`,`C-TEXT`) VALUES (2,'tweede in C');
INSERT INTO `D` (`D-ID`,`D-TEXT`) VALUES (1,'eerste in D');
INSERT INTO `D` (`D-ID`,`D-TEXT`) VALUES (2,'tweede in D');

Neem aan dat ik de volgende 'geldige combinaties' toevoeg:

SQL:

INSERT INTO `AB` (`A-ID`,`B-ID`) VALUES (1,1);
INSERT INTO `BC` (`B-ID`,`C-ID`) VALUES (1,1);
INSERT INTO `CA` (`C-ID`,`A-ID`) VALUES (1,2);
INSERT INTO `DB` (`D-ID`,`B-ID`) VALUES (1,1);
INSERT INTO `DC` (`D-ID`,`C-ID`) VALUES (1,2);

Vervolgens moeten de zaken aan elkaar 'gekoppeld' worden. Begin ik met een selectie op tabel A.

SQL:

SELECT * FROM A

Vervolgens moet ik de zaken gekoppeld worden maar wel met een check of de join mag zegmaar. Hier kom ik niet uit, dit omdat ik in een join WHERE condities moet toevoegen van tabellen die nog helemaal niet bestaan. Dus ik denk dat ik moet werken met een groot aantal subquery's in een JOIN, maar gaat dat wel.

Het moet er zoiets uit gaan zien, maar dit kan op deze manier niet, hopelijk wordt middels deze query wel duidelijk wat ik wil bereiken:

SQL:

LEFT JOIN `B` WHERE 
(`B`.`B-ID` = `AB`.`B-ID` AND `AB`.`A-ID` = `A`.`A-ID`) OR
(`B`.`B-ID` = `BA`.`B-ID` AND `BA`.`A-ID` = `A`.`A-ID`) OR
(`B`.`B-ID` = `BC`.`B-ID` AND `BC`.`C-ID` = `C`.`C-ID`) OR
(`B`.`B-ID` = `CB`.`B-ID` AND `CB`.`C-ID` = `C`.`C-ID`) OR
(`B`.`B-ID` = `BD`.`B-ID` AND `BD`.`D-ID` = `D`.`D-ID`) OR
(`B`.`B-ID` = `DB`.`B-ID` AND `DB`.`D-ID` = `D`.`D-ID`)

en dan ook op de C, D tabellen.

Samengevat moet het zoiets worden:

SQL:

SELECT * FROM [???]

LEFT JOIN `A` WHERE 
(`A`.`A-ID` = `AB`.`A-ID` AND `AB`.`B-ID` = `B`.`B-ID`) OR
(`A`.`A-ID` = `AC`.`A-ID` AND `AC`.`C-ID` = `C`.`C-ID`) OR
(`A`.`A-ID` = `AD`.`A-ID` AND `AD`.`D-ID` = `D`.`D-ID`) OR
(`A`.`A-ID` = `BA`.`A-ID` AND `BA`.`B-ID` = `B`.`B-ID`) OR
(`A`.`A-ID` = `CA`.`A-ID` AND `CA`.`C-ID` = `C`.`C-ID`) OR
(`A`.`A-ID` = `DA`.`A-ID` AND `DA`.`D-ID` = `D`.`D-ID`)

LEFT JOIN `B` WHERE 
(`B`.`B-ID` = `BA`.`B-ID` AND `BA`.`A-ID` = `A`.`A-ID`) OR
(`B`.`B-ID` = `BC`.`B-ID` AND `BC`.`C-ID` = `C`.`C-ID`) OR
(`B`.`B-ID` = `BD`.`B-ID` AND `BD`.`D-ID` = `D`.`D-ID`) OR
(`B`.`B-ID` = `AB`.`B-ID` AND `AB`.`A-ID` = `A`.`A-ID`) OR
(`B`.`B-ID` = `CB`.`B-ID` AND `CB`.`C-ID` = `C`.`C-ID`) OR
(`B`.`B-ID` = `DB`.`B-ID` AND `DB`.`D-ID` = `D`.`D-ID`)

LEFT JOIN `C` WHERE 
(`C`.`C-ID` = `CA`.`C-ID` AND `BA`.`A-ID` = `A`.`A-ID`) OR
(`C`.`C-ID` = `CB`.`C-ID` AND `CB`.`B-ID` = `B`.`B-ID`) OR
(`C`.`C-ID` = `CD`.`C-ID` AND `BD`.`D-ID` = `D`.`D-ID`) OR
(`C`.`C-ID` = `AC`.`C-ID` AND `AB`.`A-ID` = `A`.`A-ID`) OR
(`C`.`C-ID` = `BC`.`C-ID` AND `BC`.`B-ID` = `B`.`B-ID`) OR
(`C`.`C-ID` = `DC`.`C-ID` AND `DB`.`D-ID` = `D`.`D-ID`)

LEFT JOIN `D` WHERE 
(`C`.`D-ID` = `DA`.`D-ID` AND `BA`.`A-ID` = `A`.`A-ID`) OR
(`C`.`D-ID` = `DB`.`D-ID` AND `CB`.`B-ID` = `B`.`B-ID`) OR
(`C`.`D-ID` = `CD`.`D-ID` AND `CD`.`C-ID` = `C`.`C-ID`) OR
(`C`.`D-ID` = `AD`.`D-ID` AND `AB`.`A-ID` = `A`.`A-ID`) OR
(`C`.`D-ID` = `BD`.`D-ID` AND `BC`.`B-ID` = `B`.`B-ID`) OR
(`C`.`D-ID` = `DC`.`D-ID` AND `DC`.`C-ID` = `C`.`C-ID`)

ORDER BY RAND()
LIMIT 10

Zoals je ziet word de tabel gekoppeld middels de 'geldige combinatie'-tabellen. Alleen kom ik er niet uit hoe dit het beste aan te pakken. Ik heb verschillende manieren geprobeerd middels subquery's in de JOIN, maar ik kom telkens terug dat ik geen relatie kan krijgen met de bestaande data, of met dubbele tabellen of niet bestaande tabellen. Kortgezegd weet ik niet waar ik moet beginnen en vanuit welke invalshoek ik dit moet benaderen

[OnTracK]

Dit doet me opvallend veel hieraan denken: [Mysql] Complexe query (meer-op-meer relatie) 5 tabellen (ook van jou)

Wat wil je opslaan en wat wil je nou eigenlijk selecteren? Tabellen met anonieme namen en dezelfde velden zijn bijna altijd een verkeerd ontwerp.

[Gerwin]

Het idee is wel hetzelfde, dat vorige plan heb ik helemaal geschrapt en ben helemaal opnieuw begonnen met een ander project. Feit blijft wel dat beide ideeën organische trekjes hebben. Wat ik wil bereiken is dat ik de database het werk laat doen en zelf opgeef welke combinaties mogen bestaan.

Heel simpel gezegd sla ik gegevens op in vier tabellen A,B,C,D en selecteer gegevens uit A,B,C,D, maar JOIN ik ze achtereenvolgens op de geldige waarden uit de andere tabellen, dit geef ik aan in die 'tussentabellen'. Op zich kan dit volgende wel:

SQL:

SELECT *
FROM A
LEFT JOIN B ON (A.A-ID = AB.A-ID AND AB.B-ID = B.B-ID)
LEFT JOIN C ON (A.A-ID = AC.A-ID AND AC.C-ID = C.C-ID)
LEFT JOIN D ON (A.A-ID = AD.A-ID AND AD.D-ID = D.D-ID)

Maar B is niet alleen afhandelijk van de AB tabel (geldige waardes tussen A en B ), maar natuurlijk ook tussen de BA, BC/CB, BD/DB tabellen. Eigenlijk krijg je dan zoiets:

SQL:

SELECT *
FROM A
LEFT JOIN B ON (
A.A-ID = AB.A-ID AND AB.B-ID = B.B-ID OR
A.A-ID = BA.A-ID AND BA.B-ID = B.B-ID OR
C.C-ID = BC.C-ID AND BC.B-ID = B.B-ID OR
C.C-ID = CB.C-ID AND CB.B-ID = B.B-ID OR
D.D-ID = BD.D-ID AND BD.B-ID = B.B-ID OR
D.D-ID = DB.D-ID AND DB.B-ID = B.B-ID OR
)
LEFT JOIN C ON (A.A-ID = AC.A-ID AND AC.C-ID = C.C-ID)
LEFT JOIN D ON (A.A-ID = AD.A-ID AND AD.D-ID = D.D-ID)
...

Echter loop ik nu tegen het probleem aan dat in die JOIN B al problemen ontstaan omdat de tabellen AB, BA, BC, CB, BD, DB natuurlijk nog niet gejoind zijn en niet bestaan. Ik moet ze dus joinen voor dat ik B join.

SQL:

SELECT *
FROM A

LEFT JOIN AB ON A.A-ID = B.B-ID
LEFT JOIN BA ON A.A-ID = B.B-ID
LEFT JOIN BC ON C.C-ID = B.B-ID
LEFT JOIN CB ON C.C-ID = B.B-ID
LEFT JOIN BD ON D.D-ID = B.B-ID
LEFT JOIN DB ON D.D-ID = B.B-ID

LEFT JOIN B ON (
A.A-ID = AB.A-ID AND AB.B-ID = B.B-ID OR
A.A-ID = BA.A-ID AND BA.B-ID = B.B-ID OR
C.C-ID = BC.C-ID AND BC.B-ID = B.B-ID OR
C.C-ID = CB.C-ID AND CB.B-ID = B.B-ID OR
D.D-ID = BD.D-ID AND BD.B-ID = B.B-ID OR
D.D-ID = DB.D-ID AND DB.B-ID = B.B-ID OR
)
LEFT JOIN C ON (A.A-ID = AC.A-ID AND AC.C-ID = C.C-ID)
LEFT JOIN D ON (A.A-ID = AD.A-ID AND AD.D-ID = D.D-ID)
...

Ok de geldige tabellen heb ik voor de B gejoind ze bestaan dus op dat moment. Echter nu loopt die eerste join AB al vast. Immers, B is nog niet gejoind op dat moment, juist om de reden dat AB voor de join van de B tabel moet komen.

Ik hoop dat ik middels deze post inzichtelijker hebt gemaakt waar ik tegenop loop. Iets zegt me dat dus middels een subquery wel te fixen is zoals het probleem dat joins 'telkens voor elkaar' moeten komen (wat een oneindige lus veroorzaakt, want je blijft JOINS voor elkaar zetten) direct in de JOIN zelf gejoined word. Een subquery of subjoin ofzo.

[rogierslag]

de relaties in de DB en de BD tabellen zijn sowieso al hetzelfde, als koppeltabellen zou je dus "alleen" hebben:

AB, AC, AD, BA, BC, BD, CA, CB, CD, DA, DB, DC

Immers de enige geldige tabelrelaties zijn:

code:

   A
 / | \
B -|- D
 \ | /
   C

Dit kort je queries al met de helft in ongeveer. Verder moet je echt je tabellen betere namen geven, dat scheelt nu al werk en straks helemaal. Wat voor invoer komt er trouwens ook in te staan en wat wil je selecteren, want een query als deze construeren is dusdanig belachelijk dat er een betere oplossing voor moet zijn

[Gerwin]

Rogierslag, je hebt helemaal gelijk BA en AB is natuurlijk de gelijke combinatie, in feite kunnen die tabellen weg, maar ik probeer op deze manier duidelijker te maken wat het probleem is waat ik tegenaanloop.

Met betrekking op een subquery in een join had ik zoiets in gedachten:

SQL:

LEFT JOIN B ON (
SELECT * FROM BA,A WHERE BA.A-ID = A.A-ID
SELECT * FROM BC,C WHERE BC.C-ID = C.C-ID
SELECT * FROM BD,D WHERE BD.D-ID = D.D-ID
)

Maar ik voel hier hetzelfde probleem opduiken die ik eerder had toen ik aangaf dat je blijft joins voor elkaar te zetten omdat tabellen nog niet bestaan. Ook met een subquery bestaat de BA, BC en BD natuurlijk nog niet, hoe dan al vast wel een koppeling te leggen met een tabel dat nog niet bestaat?

Ik weet niet goed hoe ik dit aan moet pakken om maar niet te spreken op welke termen ik bijvoorbeeld met een zoekmachine zou moeten zoeken. Ik heb reeds lange zoektochter gedaan op termen met 'join' 'multiple join', 'cross join' etc. maar geen resultaat. Hoe noem je zoiets wat ik wil doen? Of zijn er ergens al oplossingen te vinden op het web voor hetgene dat ik opnieuw probeer 'uit te vinden'?

[dusty]

Tip voor je oplossing: Union.

[Bolukan]

Waarom gooi je het niet in 1 basis-tabel met type-aanduiding A, B, C, D: (ID, Text, Type) en met 1 koppeltabel (ID1, ID2)?
Zoiets:

SQL:

SELECT
  B1.ID AS ID_VAN,
  B2.ID AS ID_NAAR
FROM BASIS AS B1
LEFT JOIN KOPPEL ON B1.ID = KOPPEL.ID1
LEFT JOIN BASIS AS B2 ON KOPPEL.ID2 = B2.ID

[Gerwin]

Dusty ik heb je tip ter hande genomen en ben bezig geweest met UNION. Maar is een UNION in beginsel niet voor tabellen die allemaal dezelfde velden hebben?

SQL:

-- data
INSERT INTO `A` VALUES(1, 'eerste in A');
INSERT INTO `A` VALUES(2, 'tweede in A');
INSERT INTO `B` VALUES(1, 'eerste in B');
INSERT INTO `B` VALUES(2, 'tweede in B');
INSERT INTO `C` VALUES(1, 'eerste in C');
INSERT INTO `C` VALUES(2, 'tweede in C');
INSERT INTO `D` VALUES(1, 'eerste in D');
INSERT INTO `D` VALUES(2, 'tweede in D');

-- geldige combi
INSERT INTO `AB` VALUES(1, 1);
INSERT INTO `AD` VALUES(2, 1);
INSERT INTO `BC` VALUES(1, 1);
INSERT INTO `CA` VALUES(1, 2);
INSERT INTO `DB` VALUES(1, 1);

-- query
SELECT 
tmp.AID AS tmpA,tmp.BID AS tmpB,tmp.CID AS tmpC,tmp.DID AS tmpD
FROM (
 SELECT A.AID AS AID, AB.BID AS BID, AC.CID AS CID, AD.DID AS DID  
 FROM A
 LEFT JOIN AB ON AB.AID = A.AID
 LEFT JOIN AC ON AC.AID = A.AID
 LEFT JOIN AD ON AD.AID = A.AID 
 UNION 
 SELECT BA.AID AS AID, B.BID AS BID, BC.CID AS CID, BD.DID AS DID 
 FROM B
 LEFT JOIN BA ON BA.BID = B.BID
 LEFT JOIN BC ON BC.BID = B.BID
 LEFT JOIN BD ON BD.BID = B.BID
 UNION
 SELECT CA.AID AS AID, CB.BID AS BID, C.CID AS CID, CD.DID AS DID 
 FROM C
 LEFT JOIN CA ON CA.CID = C.CID
 LEFT JOIN CB ON CB.CID = C.CID
 LEFT JOIN CD ON CD.CID = C.CID
 UNION
 SELECT DA.AID AS AID, DB.BID AS BID, DC.CID AS CID, D.DID AS DID 
 FROM D
 LEFT JOIN DA ON DA.DID = D.DID
 LEFT JOIN DB ON DB.DID = D.DID
 LEFT JOIN DC ON DC.DID = D.DID
) AS tmp

-- result

tmpA    tmpB    tmpC    tmpD
1       1       NULL    NULL
2       NULL    NULL    1
NULL    1       1       NULL
NULL    2       NULL    NULL
2       NULL    1       NULL
NULL    NULL    2       NULL
NULL    1       NULL    1
NULL    NULL    NULL    2

-- maar ik wil daarnaast ook

tmpA    tmpB    tmpC    tmpD
1       1       1       NULL -- ivm `BC` VALUES(1, 1);
2       NULL    1       NULL -- ivm `CA` VALUES(1, 2);
2       1       1       NULL -- ivm `CA` VALUES(1, 2);
1       1       1       1    -- ivm `DB` VALUES(1, 1);
2       1       1       1    -- ivm `DB` VALUES(1, 1);

Hoe kan een union hier dan een oplossing bieden?

Bolukan schreef op maandag 04 februari 2008 @ 08:25:
Waarom gooi je het niet in 1 basis-tabel met type-aanduiding A, B, C, D: (ID, Text, Type) en met 1 koppeltabel (ID1, ID2)?
Zoiets:

SQL:

SELECT
  B1.ID AS ID_VAN,
  B2.ID AS ID_NAAR
FROM BASIS AS B1
LEFT JOIN KOPPEL ON B1.ID = KOPPEL.ID1
LEFT JOIN BASIS AS B2 ON KOPPEL.ID2 = B2.ID

Ik sta open voor alles, maar helemaal begrijpen doe ik je voorstel niet. Nu heb ik tabellen die geldige combinaties aangeeft zoals in mijn eerste post aangegeven. Hoe lost alles in één tabel gooien het probleem met het joinen dan op? Als je voorstel is om de BA/AB tabellen samen te voegen ben ik helemaal voor. Maar ik merk ook iets op dat er een koppeling bestaat in (zoals in je voorbeeld tabel B ), dit is niet het geval.

De waarde van de kolom B wordt bepaald door de velden A, C, en D. Als die velden een waarde bevatten in bijvoorbeeld BA, BC, en BD dan bepaald dat de waarde (en hoeveelheid rows) voor kolom B.

Echter de waarde van kolom C wordt bepaald door de velden in A, C, D. Als die velden een waarde bevatten in bijvoorbeled CA, CB en CD dan bepaald dat de waarde (en hoeveelheid rows) voor kolom C.

Dit geldt ook voor tabellen/kolommen A en D. Zoals je ziet komt er een soort oneindige loop uit, vandaar dat ik die tussentabellen gebruik en alles op dat niveau wil joinen en 'OR/AND-ten'. Alleen ben ik een geldige join te kunnen doen ben ik de data van de andere 3 nodig en voor die andere drie de data van de overige drie. Ze hangen dus toch weer aan elkaar vast.

[Toolskyn]

Hij bedoelt dat A, B, C en D precies dezelfde kolommen hebben, waarom zou je ze dan niet in een tabel zetten met een typeaanduiding als extra kolom erbij (id, gegevens, type). Dan maak je 1 tabel die een combinatie (id, type) koppelt aan een ander (id, type). Dan kun je die 12 tabellen al verminderen naar 1 tabel.

Sowieso zeg je dat A, B, C en D verschillende typen gegevens zijn, dan zou het vast ook wel mogelijk zijn dat er ooit een type E bijkomt, waarom zou je dan zo statisch willen doen met die tabellen.

[ Voor 6% gewijzigd door Toolskyn op 04-02-2008 12:27 ]

[Olaf van der Spek]

Gerwin schreef op maandag 04 februari 2008 @ 01:03:
Het idee is nu dat deze tabellen dynamisch aan elkaar gelinkt kunnen worden.

Dit klinkt zo vaag. Misschien is het handig als je eerst eens exact uitlegt welk resultaat je nou wilt hebben met je query.
En wat is het verschil tussen de vier tabellen?

[curry684]

Kerel de vorige keer heeft het zowat honderd replies gekost voordat je doorhad dat je model nergens op sloeg, waarom probeer je het nu 3 maanden later weer?

Een database moet je gebruiken om data in op te slaan, niet om subdatabases in te bouwen waarin je weer subdatabases kunt gaan bouwen. Wat jij wil is allemaal heel leuk maar moet je in C++ gaan implementeren waar het lekker performant hardpointered met custom opslagstructuren kan, niet in een database die hardcoded getraind is voor hele andere trucjes.

[J2pc]

Maak eens een ERD ERD voor de grap. Dat praat zo veel makkelijker ivm relaties. Ook makkelijker voor de rest om dan verbeteringen / SQL voor te stellen.

Dan wordt 't vaak duidelijker hoe je relaties liggen en hoe je moet joinen.

Maar als ik curry684 zo lees heeft ie wel een valide punt

[ Voor 11% gewijzigd door J2pc op 04-02-2008 13:12 ]

[dusty]

Gerwin schreef op maandag 04 februari 2008 @ 09:19:
Dusty ik heb je tip ter hande genomen en ben bezig geweest met UNION. Maar is een UNION in beginsel niet voor tabellen die allemaal dezelfde velden hebben?
[...]

Dezelfde TYPE velden hebben, of met een select hetzelfde gemaakt kunnen worden, in jouw geval zijn alle tabellen zelfs van dezelfde typen. Wat er op zicht duidt dat er geen fatsoenlijke normalisatie heeft plaats gevonden.

[Gerwin]

Arrrg, hoe kan ik nog duidelijker maken wat het probleem is. De naam van de tabellen en wat de data in de tabellen eigenlijk is doet er in mijn voorbeeld niet toe. Een ERD komt er in de eerste 'laag' zo uit te zien als Rogierslag gepost heeft (rogierslag in "[Mysql] meerdere JOIN's in één, JOIN met...")

code:

   A
 / | \
B -|- D
 \ | /
   C

Echter dat wil niet, dus wil ik zegmaar eerst die 'geldige combinatie'-tabellen samenstellen. Om vervolgens de tabellen A, B, C en D te joinen en dan te laten samensmelten tot 4 kolommmen.

De volgende relaties bestaan:

A gejoind op AB, AC en AD;
B gejoind op AB, BC en BD;
C gejoind op AC, BA en CD;
D gejoind op AD, BD en CD;

Hoe krijg ik dat voor elkaar zodat ik results krijg met kolom A, B, C en D?


In feite moet ook nog AB gejoind worden of 'toegevoegd' worden, maar als ik dat voor het moment dat A gejoind word doe dan mist op een gegeven moment A data van de rijen die ontstaan door de join van B.

Join ik tabel AB na A kan niet, na B kan ook niet.

[ Voor 13% gewijzigd door Gerwin op 05-02-2008 05:31 ]

[Bolukan]

Bedoel je dat er setjes van 4 bestaan (A,B,C en D), waar tussen 8 relaties (AB, BA, etz) zijn gedefinieerd en dat je die wilt opvragen? En dat een A en B van zo'n setje ook nog een setje kan vormen met een andere C, resp andere D en dat je ook die dan apart wilt krijgen?

[ACM]

Als je enkel de relaties wilt volgen die je in je laatste reactie noemt is het toch een kwestie van:

SQL:

SELECT DISTINCT A.id, B.id, C.id, D.id
FROM
(
SELECT A.id, B.id, C.id, D.id
FROM A
   LEFT JOIN (AB JOIN B ON AB.BID = B.ID) ON A.ID = AB.AID 
   LEFT JOIN (AC JOIN C ON AC.CID = C.ID) ON A.ID = AC.AID
   LEFT JOIN (AD JOIN D ON AB.DID = D.ID) ON A.ID = AD.AID 
UNION ALL
SELECT A.id, B.id, C.id, D.id
FROM B
   LEFT JOIN (AB JOIN A ON AB.AID = A.ID) ON B.ID = AB.BID 
   LEFT JOIN (BC JOIN C ON BC.CID = C.ID) ON B.ID = BC.BID
   LEFT JOIN (BD JOIN D ON BD.DID = D.ID) ON B.ID = BD.BID
UNION ALL 
...
) as foo

Of heb je weer nog meer moeilijkheden erbij bedacht waardoor het nog minder mogelijk in simpele SQL is?

[Olaf van der Spek]

Gerwin schreef op dinsdag 05 februari 2008 @ 05:25:
A gejoind op AB, AC en AD;
B gejoind op AB, BC en BD;
C gejoind op AC, BA en CD;
D gejoind op AD, BD en CD;

Hoe krijg ik dat voor elkaar zodat ik results krijg met kolom A, B, C en D?

select * from A, B, C, D, AB, AC, AD, BC, BD, CD where
A.aid = AB.aid and B.bid = AB.bid and
A.aid = AC.aid and C.cid = AC.cid and
A.aid = AD.aid and D.did = AD.did and
B.bid = BC.bid and C.cid = BC.cid and
B.bid = BD.bid and D.did = BD.did and
C.cid = CD.cid and D.did = CD.cid

Zoiets?

[Gerwin]

Bolukan schreef op dinsdag 05 februari 2008 @ 06:52:
Bedoel je dat er setjes van 4 bestaan (A,B,C en D), waar tussen 8 relaties (AB, BA, etz) zijn gedefinieerd en dat je die wilt opvragen? En dat een A en B van zo'n setje ook nog een setje kan vormen met een andere C, resp andere D en dat je ook die dan apart wilt krijgen?

Juist er bestaan in deze case 4 tabellen (setjes) die relaties met elkaar hebben die staan in AB, AC, AD, BC, CD. Vervolgens moet er een lijst gevormd worden uit die 4 tabellen (setjes) die de relaties in die 'relatie tabellen' respecteren. Het probleem zit hem in het feit dat de joins blijkbaar in verschillende 'lagen' opgebouwd moeten worden, dit omdat 'liniear' dit niet kan (dat heb ik in een ander topic al eens geprobeerd).

ACM schreef op dinsdag 05 februari 2008 @ 09:03:
Als je enkel de relaties wilt volgen die je in je laatste reactie noemt is het toch een kwestie van:

SQL:

SELECT DISTINCT A.id, B.id, C.id, D.id
FROM
(
SELECT A.id, B.id, C.id, D.id
FROM A
   LEFT JOIN (AB JOIN B ON AB.BID = B.ID) ON A.ID = AB.AID 
   LEFT JOIN (AC JOIN C ON AC.CID = C.ID) ON A.ID = AC.AID
   LEFT JOIN (AD JOIN D ON AB.DID = D.ID) ON A.ID = AD.AID 
UNION ALL
SELECT A.id, B.id, C.id, D.id
FROM B
   LEFT JOIN (AB JOIN A ON AB.AID = A.ID) ON B.ID = AB.BID 
   LEFT JOIN (BC JOIN C ON BC.CID = C.ID) ON B.ID = BC.BID
   LEFT JOIN (BD JOIN D ON BD.DID = D.ID) ON B.ID = BD.BID
UNION ALL 
...
) as foo

Of heb je weer nog meer moeilijkheden erbij bedacht waardoor het nog minder mogelijk in simpele SQL is?

Dank je wel. Zoiets lijkt verdacht veel wat ik juist voor ogen had. Alleen ben ik geen held met JOIN in JOINs en dat soort fratsen Na mijn vorige poging ben ik helemaal afgestapt van zelf de relaties laten bepalen en wil op zo'n manier als je schetst inderdaad eerst een laag met relaties bepalen en ze dan samensmelten. Alleen ben ik er nog niet helemaal uit of dit nu exact is wat de oplossing is, maar ik voel dat dit een heel eind de goede richting opgaat.

Ik ben zo vrij geweest die query verder af te maken:

SQL:

SELECT DISTINCT foo.AID, foo.BID, foo.CID, foo.DID
FROM
(
SELECT A.AID, B.BID, C.CID, D.DID
FROM A
   LEFT JOIN (AB JOIN B ON AB.BID = B.BID) ON A.AID = AB.AID 
   LEFT JOIN (AC JOIN C ON AC.CID = C.CID) ON A.AID = AC.AID
   LEFT JOIN (AD JOIN D ON AD.DID = D.DID) ON A.AID = AD.AID 
UNION ALL
SELECT A.AID, B.BID, C.CID, D.DID
FROM B
   LEFT JOIN (AB JOIN A ON AB.AID = A.AID) ON B.BID = AB.BID 
   LEFT JOIN (BC JOIN C ON BC.CID = C.CID) ON B.BID = BC.BID
   LEFT JOIN (BD JOIN D ON BD.DID = D.DID) ON B.BID = BD.BID 
UNION ALL
SELECT A.AID, B.BID, C.CID, D.DID
FROM C
   LEFT JOIN (AC JOIN A ON AC.AID = A.AID) ON C.CID = AC.CID 
   LEFT JOIN (BC JOIN B ON BC.BID = B.BID) ON C.CID = BC.CID
   LEFT JOIN (CD JOIN D ON CD.DID = D.DID) ON C.CID = CD.CID 
UNION ALL
SELECT A.AID, B.BID, C.CID, D.DID
FROM D
   LEFT JOIN (AD JOIN A ON AD.AID = A.AID) ON D.DID = AD.DID 
   LEFT JOIN (BD JOIN B ON BD.BID = B.BID) ON D.DID = BD.DID
   LEFT JOIN (CD JOIN C ON CD.DID = C.CID) ON D.DID = CD.DID 
) AS foo

Nu komen we echt ergens Ik als resultaat krijg ik al bij een hoop tests terug wat ik juist terug wil hebben. Maar ik denk dat er nog een laag op moet want ik mis iets, ik zal uitleggen wat.

Ik heb de volgende data in de tabellen staan:

SQL:

INSERT INTO `A` VALUES(1, 'eerste A');
INSERT INTO `A` VALUES(2, 'tweede A');
INSERT INTO `A` VALUES(3, 'derde A');

INSERT INTO `B` VALUES(1, 'eerste B');
INSERT INTO `B` VALUES(2, 'tweede B');
INSERT INTO `B` VALUES(3, 'derde B');

INSERT INTO `C` VALUES(1, 'eerste C');
INSERT INTO `C` VALUES(2, 'tweede C');
INSERT INTO `C` VALUES(3, 'derde C');

INSERT INTO `D` VALUES(1, 'eerste D');
INSERT INTO `D` VALUES(2, 'tweede D');
INSERT INTO `D` VALUES(3, 'derde D');

INSERT INTO `AB` VALUES(1, 1);
INSERT INTO `BC` VALUES(1, 1);
INSERT INTO `CD` VALUES(1, 3);

code:

A   B  C     D
3  -  -  -
1  1  -  -
2  -  -  -
1  1  1  -
-  2  -  -
-  3  -  -
-  1  1  3
-  -  2  -
-  -  3  -
-  -  -  1
-  -  -  2
-  -  3  3



'-' = NULL; A, B, C en D zijn uiteraard de A.AID, B.BID, C.CID en D.DID kolommen

En nu valt me op dat die laatste de CD hij komt netjes voor op die CD combinatie zoals verwacht, maar niet op de BC combinatie, is dat te fixen met een nieuwe 'sub sub'-join. En hoe ziet dat er dan uit?

Edit: Het gaat me dus om regel 5. Waarom komt er geen 1-1-1-3 voor?


---

Olaf van der Spek schreef op dinsdag 05 februari 2008 @ 11:25:
[...]

select * from A, B, C, D, AB, AC, AD, BC, BD, CD where
A.aid = AB.aid and B.bid = AB.bid and
A.aid = AC.aid and C.cid = AC.cid and
A.aid = AD.aid and D.did = AD.did and
B.bid = BC.bid and C.cid = BC.cid and
B.bid = BD.bid and D.did = BD.did and
C.cid = CD.cid and D.did = CD.cid

Zoiets?

Dit is weer een heel andere constructie dan die met de JOINs en sub-JOINsvan ACM. Ik heb hem even aangepast aan de opbouw van de voorbeeld/test-database:

SQL:

SELECT * 
FROM A, B, C, D, AB, AC, AD, BC, BD, CD 
WHERE
A.AID = AB.AID AND B.BID = AB.BID AND
A.AID = AC.AID AND C.CID = AC.CID AND
A.AID = AD.AID AND D.DID = AD.DID AND
B.BID = BC.BID AND C.CID = BC.CID AND
B.BID = BD.BID AND D.DID = BD.DID AND
C.CID = CD.CID AND D.DID = CD.CID

Maar hier krijg ik met de volgende data helemaal niets terug.

SQL:

INSERT INTO `A` VALUES(1, 'eerste A');
INSERT INTO `A` VALUES(2, 'tweede A');
INSERT INTO `A` VALUES(3, 'derde A');

INSERT INTO `B` VALUES(1, 'eerste B');
INSERT INTO `B` VALUES(2, 'tweede B');
INSERT INTO `B` VALUES(3, 'derde B');

INSERT INTO `C` VALUES(1, 'eerste C');
INSERT INTO `C` VALUES(2, 'tweede C');
INSERT INTO `C` VALUES(3, 'derde C');

INSERT INTO `D` VALUES(1, 'eerste D');
INSERT INTO `D` VALUES(2, 'tweede D');
INSERT INTO `D` VALUES(3, 'derde D');

INSERT INTO `AB` VALUES(1, 1);
INSERT INTO `BC` VALUES(1, 1);
INSERT INTO `CD` VALUES(1, 3);

[ Voor 23% gewijzigd door Gerwin op 05-02-2008 12:30 ]

[ACM]

Gerwin schreef op dinsdag 05 februari 2008 @ 12:07:
Edit: Het gaat me dus om regel 5. Waarom komt er geen 1-1-1-3 voor?

Omdat er geen AD tussen A1 en D3 is. Als je dat er ook bij wilt hebben wordt het een *kuch* wat uitgebreidere constructie... Als performance je niet boeit kan het misschien wel met zoiets:

SQL:

SELECT DISTINCT ...
FROM (
 SELECT A.ID,...
 FROM A
    LEFT JOIN B ON B.ID IN (select bid from ab where aid = A.id)
    LEFT JOIN C ON C.ID IN (select cid from ac where aid = A.id union select cid from bc where bid = B.id)
    LEFT JOIN D ON D.ID IN (select did from ad where aid = A.id union select did from bd where bid = B.id union ...)
UNION ALL
 SELECT NULL, B.ID, C.ID, D.ID
FROM B
    LEFT JOIN C ON C.ID IN (select cid from bc where bid = B.id)
    LEFT JOIN D ON D.ID IN (select did from bd where bid = B.id union ...)
UNION ALL
SELECT NULL, NULL, C.ID, D.ID
FROM C
    LEFT JOIN D ON D.ID IN (select did from cd where cid = C.id)
) as foo

Hoewel het dan waarschijnlijk iets vlotter is om de A-B en daarna de B-C en C-D verbindingen met een normale left join te verbinden.

Mocht je database (null, null, 1, 1) als iets anders zien dan (null, null, 1, 1) door de null's, dan kan je natuurlijk een 0 ipv null schrijven en in je selectlists verder coalesce(b.id, 0) enzo.

[ Voor 7% gewijzigd door ACM op 05-02-2008 13:03 ]

[Gerwin]

ACM schreef op dinsdag 05 februari 2008 @ 13:01:
[...]

Omdat er geen AD tussen A1 en D3 is. Als je dat er ook bij wilt hebben wordt het een *kuch* wat uitgebreidere constructie... Als performance je niet boeit kan het misschien wel met zoiets:

SQL:

SELECT DISTINCT ...
FROM (
 SELECT A.ID,...
 FROM A
    LEFT JOIN B ON B.ID IN (select bid from ab where aid = A.id)
    LEFT JOIN C ON C.ID IN (select cid from ac where aid = A.id union select cid from bc where bid = B.id)
    LEFT JOIN D ON D.ID IN (select did from ad where aid = A.id union select did from bd where bid = B.id union ...)
UNION ALL
 SELECT NULL, B.ID, C.ID, D.ID
FROM B
    LEFT JOIN C ON C.ID IN (select cid from bc where bid = B.id)
    LEFT JOIN D ON D.ID IN (select did from bd where bid = B.id union ...)
UNION ALL
SELECT NULL, NULL, C.ID, D.ID
FROM C
    LEFT JOIN D ON D.ID IN (select did from cd where cid = C.id)
) as foo

Hoewel het dan waarschijnlijk iets vlotter is om de A-B en daarna de B-C en C-D verbindingen met een normale left join te verbinden.

Mocht je database (null, null, 1, 1) als iets anders zien dan (null, null, 1, 1) door de null's, dan kan je natuurlijk een 0 ipv null schrijven en in je selectlists verder coalesce(b.id, 0) enzo.

Geweldig deze manier van query's maken is 'not my cup of tea' om het maar eens simpel te zeggen.
Ik heb nu het volgende:

SQL:

SELECT DISTINCT foo.AID, foo.BID, foo.CID, foo.DID
FROM
(
   SELECT A.AID, B.BID, C.CID, D.DID
   FROM A
      LEFT JOIN B ON B.BID IN (
         SELECT BID FROM AB WHERE AID=A.AID
      )
      LEFT JOIN C ON C.CID IN (
         SELECT CID FROM AC WHERE AID = A.AID
         UNION SELECT CID FROM BC WHERE BID = B.BID
      )
      LEFT JOIN D ON D.DID IN (
         SELECT DID FROM AD WHERE AID = A.AID
         UNION SELECT DID FROM BD WHERE BID = B.BID
         UNION SELECT DID FROM CD WHERE CID = C.CID
      )
   UNION ALL
   SELECT NULL, B.BID, C.CID, D.DID
   FROM B
      LEFT JOIN C ON C.CID IN (
         SELECT CID FROM BC WHERE BID = B.BID
      )
      LEFT JOIN D ON D.DID IN (
         SELECT DID FROM BD WHERE BID = B.BID
      )
   UNION ALL
   SELECT NULL, NULL, C.CID, D.DID
   FROM C
      LEFT JOIN D ON D.DID IN (
         SELECT DID FROM CD WHERE CID = C.CID
      )
) AS foo


INSERT INTO `AB` VALUES(1, 1);
INSERT INTO `BC` VALUES(1, 1);
INSERT INTO `CD` VALUES(1, 3);

code:

A   B   C   D
1   1   1   3
2   -   -   -
3   -   -   -
-   1   1   -
-   2   -   -
-   3   -   -
-   -   1   3
-   -   2   -
-   -   3   -

Nu ontbreken dan wel weer andere zaken, maar dat is misschien niet zo heel ingewikkeld te tackelen . Zo ontbreekt nu de simpele 1-1-0-0 uit regel 36 (AB). Het vreemde is dat hij de BC combinatie uit regel 37 wel apart teruggeeft en terwijl daar toch ook andere relaties op zijn gezet, evenals de CD uit regel 38. Die staat er ook. Die enkele combinaties die kan middels een union op al die andere tabellen nog wel toegevoegd worden.

SQL:

UNION (SELECT DISTINCT AB.AID, AB.BID, NULL, NULL FROM AB)
UNION (SELECT DISTINCT AC.AID, AC.CID, NULL, NULL FROM AC)
UNION (SELECT DISTINCT AD.AID, AD.DID, NULL, NULL FROM AD)
UNION (SELECT DISTINCT BC.BID, BC.CID, NULL, NULL FROM BC)
UNION (SELECT DISTINCT BD.BID, BD.DID, NULL, NULL FROM BD)
UNION (SELECT DISTINCT CD.CID, CD.DID, NULL, NULL FROM CD)

Als tweede ontbreekt nu 1-1-1-0. (AB is 1-1-0-0 en BC 0-1-1-0). En deze vindt ik misschien wel de belangrijkste, maar met de technieken die ik hier geleerd heb ga ik daar eens mee bezig. Als het niet in één SELECT kan dan kan dat net als die enkele combinaties hierboven ook weer een union worden. Als derde ontbreekt ook 0-1-1-3. (BC is 0-1-1-0 en CD is 0-0-1-3). Wat betreft de drie cijfers blijkt het alles of niets te zijn in alle vormen; dus niet de tussenstappen.

Of het allemaal netjes is om het zo te doen is een ander verhaal, laat staan of dit daadwerkelijk gaat werken. Suggesties en tips blijven uiteraard welkom, op deze manier JOINS doen dat is voor mij al een geheel nieuwe ervaring geweest.

[? ?]

Jouw heb ik al gezien met dezelfde A B C D E F tabellen...
Maak een ERD schema en ik zou wel eens willen zien waarvoor je nu weer zo'n #"@^% (excuse me) databaseschema nodig hebt. Gaat vast ook een goeie performance geven met een miljoen records...

[Olaf van der Spek]

Gerwin schreef op dinsdag 05 februari 2008 @ 12:07:
Dit is weer een heel andere constructie dan die met de JOINs en sub-JOINsvan ACM. Ik heb hem even aangepast aan de opbouw van de voorbeeld/test-database:
Maar hier krijg ik met de volgende data helemaal niets terug.

Het is (mij) dan ook nog steeds niet duidelijk wat je precies wil hebben. Blijkbaar wil je in de result set een A, B, C en D kolom hebben.
Maar wat is de relatie tussen die A, B, C en D?

[bigbeng]

Je doorloopt je query nu van A links naar D rechts, dus alleen de combinaties
A,B,C,D
-,B,C,D
-,-,C,D

komen nu voor. Omdat er geen verband is tussen C en D via B, komt de -,1,1,- toevallig voor.

[ACM]

Gerwin schreef op dinsdag 05 februari 2008 @ 14:11:
Nu ontbreken dan wel weer andere zaken, maar dat is misschien niet zo heel ingewikkeld te tackelen. Zo ontbreekt nu de simpele 1-1-0-0 uit regel 36 (AB).

Er is toch een BC 1-1? Hoe moet de DB dan verzinnen dat ie die BC er niet bij had mogen trekken?

Als je echt alle varianten van relaties wilt die je nu lijkt te noemen, dan krijg je een behoorlijke draak van een query. Je kan je uitgewerkte versie van de mijne aanvullen met join-combinaties voor de mogelijke A-B-C-varianten en de mogelijke A-B, A-C, A-D, B-C en B-D (je hebt nu alleen A-B-C-D, B-C-D en C-D).

era.zer schreef op dinsdag 05 februari 2008 @ 14:24:
Gaat vast ook een goeie performance geven met een miljoen records...

Een nette genormaliseerde variant hiervan (met een [AID, Naam] en een [AID-AID-type] selfjoin-tabel) zal hier niet beter presteren dan deze oplossing, domweg omdat je hier in SQL nogal vervelende queries voor nodig hebt.
Ik denk dat je alleen met een gedenormaliseerde oplossing met een platgeslagen ster-tabel ([AID,BID,CID,DID]) je enigszins vlot de boel kan querien. Maar dat is natuurlijk weer niet erg flexibel.
Tenzij je een compleet andere aanpak weet te verzinnen natuurlijk, maar de kans dat je het dan in SQL kunt verwerken lijkt me niet erg groot.

[ Voor 35% gewijzigd door ACM op 05-02-2008 18:30 ]

[Verwijderd]

Even gejat uit een andere post:

code:

   A
 / | \
B -|- D
 \ | /
   C

Wat ik hier niet helemaal begrijp is je 'start'-tabel. Je hebt een model gemaakt dat recursief doorlopen moet worden zonder echt beginpunt, maar dat is niet iets 'native' van SQL. Je selecteert rijen uit A, maar via B naar C terug naar A kan je ook weer misschien nieuwe rijen uit A selecteren... Je kan nog wel 2x de tabel A koppelen (A2), maar dat zal je query niet simpeler maken, want die moet je ook weer aan B, C en D koppelen...

Maar wat is je drijfveer om dit perse op te lossen met SQL?
Ingewikkelde queries verzinnen of misschien in een programmeer-taal op te lossen? Een simpele select (ja, zelfs op miljoenen rijen) kost toch niet zoveel als onbegrijpelijke (niet onderhoudbare) query...

[Bolukan]

Volgens mij moet je 24 queries combineren, vanwege alle routes die kunnen worden gelopen (4x3x2x1). Nog steeds vind ik 1 stamtabel en 1 koppeltabel genoeg:

SQL:

SELECT
 S.Type AS Type1,
 S.Nr AS Nr1,
 K1.TypeNaar AS Type2,
 K1.Naar AS Nr2,
 K2.TypeNaar AS Type3,
 K2.Naar AS Nr3,
 K3.TypeNaar AS Type4,
 K3.Naar AS Nr4
FROM
 ((S LEFT JOIN K AS K1 ON (S.Nr = K1.Van) AND (S.Type = K1.TypeVan)) 
 LEFT JOIN K AS K2 ON (K1.TypeNaar = K2.TypeVan) AND (K1.Naar = K2.Van))
 LEFT JOIN K AS K3 ON (K2.TypeNaar = K3.TypeVan) AND (K2.Naar = K3.Van);

Uitkomst:

Type1	Nr1	Type2	Nr2	Type3	Nr3	Type4	Nr4
A	1	B	1	C	1	D	3
A	2						
A	3						
B	1	C	1	D	3		
B	2						
B	3						
C	1	D	3				
C	2						
C	3						
D	1						
D	2
D	3

Edit: Aan koppeltabel alle stamgegevens naar Null toevoegen en aan query een WHERE clausule:

SQL:

WHERE (((K2.TypeNaar) Is Null Or ((K2.TypeNaar)<>[S].[Type])) AND ((K3.TypeNaar) Is Null Or ((K3.TypeNaar)<>[S].[Type] And (K3.TypeNaar)<>[K1.TypeNaar])));

om A-B-A, A-B-C-A en A-B-C-B combinaties te voorkomen.

Uitkomst:

Type1	Nr1	Type2	Nr2	Type3	Nr3	Type4	Nr4
A	1						
A	1	B	1				
A	1	B	1	C	1		
A	1	B	1	C	1	D	3
A	2						
A	3						
B	1						
B	1	C	1				
B	1	C	1	D	3		
B	2						
B	3						
C	1						
C	1	D	3				
C	2						
C	3						
D	1						
D	2						
D	3						

[ Voor 29% gewijzigd door Bolukan op 05-02-2008 21:28 ]

[curry684]

Gerwin schreef op dinsdag 05 februari 2008 @ 14:11:
[...]

Geweldig deze manier van query's maken is 'not my cup of tea' om het maar eens simpel te zeggen.

Da's niemand's cup of tea omdat SQL er niet voor bedoeld is. Zodra je 24 joins hebt voor de simpelste operaties zit je simpelweg zoals dat in ICT zo mooi heet met "the wrong tool for the wrong job".

[Gerwin]

era.zer schreef op dinsdag 05 februari 2008 @ 14:24:
Jouw heb ik al gezien met dezelfde A B C D E F tabellen...
Maak een ERD schema en ik zou wel eens willen zien waarvoor je nu weer zo'n #"@^% (excuse me) databaseschema nodig hebt. Gaat vast ook een goeie performance geven met een miljoen records...

Dat zit er in de toekomst misschien wel in als er een nieuw soort data bijkomt. Dit gaat zoals het er uitziet inderdaad geen goede performance geven, maar ik zou zo niet weten hoe dat anders te kunnen doen. Het enige wat ik tot mijn beschikking heb dit te realiseren is een normale server met Mysql5 en PHP 5.

Olaf van der Spek schreef op dinsdag 05 februari 2008 @ 14:37:
[...]

Het is (mij) dan ook nog steeds niet duidelijk wat je precies wil hebben. Blijkbaar wil je in de result set een A, B, C en D kolom hebben.
Maar wat is de relatie tussen die A, B, C en D?

Ik wil de mogelijkheid hebben om heel simpel zaken aan elkaar te kunnen koppelen zonder dat ik de hele meuk zelf moet gaan zitten bijhouden. In vorige pogingen heb ik geprobeerd om alles door de database te laten verzinnen, maar dat werkt niet. Maar in theorie lijkt dit wel mogelijk om in lagen dit aan elkaar te koppelen.

ACM schreef op dinsdag 05 februari 2008 @ 18:24:
[...]

Er is toch een BC 1-1? Hoe moet de DB dan verzinnen dat ie die BC er niet bij had mogen trekken?

Als je echt alle varianten van relaties wilt die je nu lijkt te noemen, dan krijg je een behoorlijke draak van een query. Je kan je uitgewerkte versie van de mijne aanvullen met join-combinaties voor de mogelijke A-B-C-varianten en de mogelijke A-B, A-C, A-D, B-C en B-D (je hebt nu alleen A-B-C-D, B-C-D en C-D).


[...]

Een nette genormaliseerde variant hiervan (met een [AID, Naam] en een [AID-AID-type] selfjoin-tabel) zal hier niet beter presteren dan deze oplossing, domweg omdat je hier in SQL nogal vervelende queries voor nodig hebt.
Ik denk dat je alleen met een gedenormaliseerde oplossing met een platgeslagen ster-tabel ([AID,BID,CID,DID]) je enigszins vlot de boel kan querien. Maar dat is natuurlijk weer niet erg flexibel.
Tenzij je een compleet andere aanpak weet te verzinnen natuurlijk, maar de kans dat je het dan in SQL kunt verwerken lijkt me niet erg groot.

Ik begrijp het alles moet dus aan elkaar gekoppeld worden, het is niet mogelijk dit samen te voegen in wat minder JOINS en moet met echt meerdere unions.

Verwijderd schreef op dinsdag 05 februari 2008 @ 19:12:
Even gejat uit een andere post:

code:

   A
 / | \
B -|- D
 \ | /
   C

Wat ik hier niet helemaal begrijp is je 'start'-tabel. Je hebt een model gemaakt dat recursief doorlopen moet worden zonder echt beginpunt, maar dat is niet iets 'native' van SQL. Je selecteert rijen uit A, maar via B naar C terug naar A kan je ook weer misschien nieuwe rijen uit A selecteren... Je kan nog wel 2x de tabel A koppelen (A2), maar dat zal je query niet simpeler maken, want die moet je ook weer aan B, C en D koppelen...

Maar wat is je drijfveer om dit perse op te lossen met SQL?
Ingewikkelde queries verzinnen of misschien in een programmeer-taal op te lossen? Een simpele select (ja, zelfs op miljoenen rijen) kost toch niet zoveel als onbegrijpelijke (niet onderhoudbare) query...

In feite heb ik in dit voorbeeld 4 start tabellen. Die vervolgens gejoind worden op elkaar zodat één lijst ontstaat. SQL en PHP is de enige mogelijkheid dit ik heb. Een mogelijkheid met PHP kan ook, maar is dan de constructie niet dezelfde?

Bolukan schreef op dinsdag 05 februari 2008 @ 21:15:
Volgens mij moet je 24 queries combineren, vanwege alle routes die kunnen worden gelopen (4x3x2x1). Nog steeds vind ik 1 stamtabel en 1 koppeltabel genoeg:

SQL:

SELECT
 S.Type AS Type1,
 S.Nr AS Nr1,
 K1.TypeNaar AS Type2,
 K1.Naar AS Nr2,
 K2.TypeNaar AS Type3,
 K2.Naar AS Nr3,
 K3.TypeNaar AS Type4,
 K3.Naar AS Nr4
FROM
 ((S LEFT JOIN K AS K1 ON (S.Nr = K1.Van) AND (S.Type = K1.TypeVan)) 
 LEFT JOIN K AS K2 ON (K1.TypeNaar = K2.TypeVan) AND (K1.Naar = K2.Van))
 LEFT JOIN K AS K3 ON (K2.TypeNaar = K3.TypeVan) AND (K2.Naar = K3.Van);

Uitkomst:

Type1	Nr1	Type2	Nr2	Type3	Nr3	Type4	Nr4
A	1	B	1	C	1	D	3
A	2						
A	3						
B	1	C	1	D	3		
B	2						
B	3						
C	1	D	3				
C	2						
C	3						
D	1						
D	2
D	3

Edit: Aan koppeltabel alle stamgegevens naar Null toevoegen en aan query een WHERE clausule:

SQL:

WHERE (((K2.TypeNaar) Is Null Or ((K2.TypeNaar)<>[S].[Type])) AND ((K3.TypeNaar) Is Null Or ((K3.TypeNaar)<>[S].[Type] And (K3.TypeNaar)<>[K1.TypeNaar])));

om A-B-A, A-B-C-A en A-B-C-B combinaties te voorkomen.

Uitkomst:

Type1	Nr1	Type2	Nr2	Type3	Nr3	Type4	Nr4
A	1						
A	1	B	1				
A	1	B	1	C	1		
A	1	B	1	C	1	D	3
A	2						
A	3						
B	1						
B	1	C	1				
B	1	C	1	D	3		
B	2						
B	3						
C	1						
C	1	D	3				
C	2						
C	3						
D	1						
D	2						
D	3						

Ik kom op de volgende query's uit.

code:

A -> A
A -> B
A -> C
A -> D
A -> A & B
A -> A & C
A -> A & D
A -> B & C
A -> C & D
A -> A & B & C
A -> A & B & D
A -> B & C & D
A -> A & C & D

En dan idem voor de B, C en D tabellen, dan joinen als ik het goed heb.

curry684 schreef op woensdag 06 februari 2008 @ 00:27:
[...]

Da's niemand's cup of tea omdat SQL er niet voor bedoeld is. Zodra je 24 joins hebt voor de simpelste operaties zit je simpelweg zoals dat in ICT zo mooi heet met "the wrong tool for the wrong job".

Juist hierom post ik ook op het forum, met de manieren die hier gepost zijn kom ik in elk geval een stukje verder, maar het gaat wel een draak van een query worden. Kan dit kleiner door toch op een manier de database zelf de query te laten maken ofzo. Iets met een loop of een if-else erin? Of is het dan echt een php/mysql combinatie. Of kan het toch met een kleinere mysql query?

[Bolukan]

Wat mis je in mijn uitkomst??? (met A1-B1, B1-C1 en C1-D3)

[Gerwin]

Bolukan, als je alleen A-B, B-C en C-D doet dan mis je uiteindelijk de connecties die uit de C-D ontstaan in de koppeling A-B, dit omdat deze pas bestaan 'na' de connectie C-D.

Inmiddels ben ik al wel een heel eind verder gekomen met toch wel speciale manier van zaken aan elkaar joinen met subquery's. Omdat echt alles aan elkaar koppelen wel een gigantische bulk wordt ben ik de zaken meer gespitst op het probleem. Tevens heb ik een echt schema gemaakt met de bestaande echte tabellen. Daarbij heb ik een hoop relaties laten vallen. Hieronder het schema.



Daarbij heb ik de volgende query.

SQL:

SELECT `Company`,`Location`,`Product`,`Type`,`Video`,`Image`,`Genre`,`Title`,`Description`,`Text`
FROM `Company`
LEFT JOIN `Location` ON `Location`.`CompanyID` = `Company`.`CompanyID`
LEFT JOIN `Location2Product` ON `Location2Product`.`LocationID` = `Location`.`LocationID`
LEFT JOIN `Product` ON `Product`.`ProductID` = `Location2Product`.`ProductID`
LEFT JOIN `Product2Type` ON `Product2Type`.`ProductID` = `Product`.`ProductID`
LEFT JOIN `Type` ON `Type`.`TypeID` = `Product2Type`.`TypeID`
LEFT JOIN `Video` ON `Video`.`VideoID` IN (
   SELECT `VideoID` FROM `Location2Video` WHERE `LocationID` = `Location`.`LocationID`
   UNION SELECT `VideoID` FROM `Product2Video` WHERE `ProductID` = `Product`.`ProductID`
)
LEFT JOIN `Image` ON `Image`.`ImageID` IN (
   SELECT `ImageID` FROM `Location2Image` WHERE `LocationID` = `Location`.`LocationID`
   UNION SELECT `ImageID` FROM `Product2Image` WHERE `ProductID` = `Product`.`ProductID`
   UNION SELECT `ImageID` FROM `Video2Image` WHERE `VideoID` = `Video`.`VideoID`
   UNION SELECT `ImageID` FROM `Genre2Image` WHERE `GenreID` IN (
      SELECT `GenreID` FROM `Company`
      LEFT JOIN `Location` ON `Location`.`CompanyID` = `Company`.`CompanyID`
      LEFT JOIN `Location2Product` ON `Location2Product`.`LocationID` = `Location`.`LocationID`
      LEFT JOIN `Product` ON `Product`.`ProductID` = `Location2Product`.`ProductID`
      LEFT JOIN `Video` ON `Video`.`VideoID` IN (
         SELECT `VideoID` FROM `Location2Video` WHERE `LocationID` = `Location`.`LocationID`
         UNION SELECT `VideoID` FROM `Product2Video` WHERE `ProductID` = `Product`.`ProductID`
      )
      LEFT JOIN `Genre` ON `Genre`.GenreID` IN (
         SELECT `GenreID` FROM `Location2Genre` WHERE `LocationID` = `Location`.`LocationID`
         UNION SELECT `GenreID` FROM `Product2Genre` WHERE `ProductID` = `Product`.`ProductID`
         UNION SELECT `GenreID` FROM `Image2Genre` WHERE `ImageID` = `Image`.`ImageID`
         UNION SELECT `GenreID` FROM `Video2Genre` WHERE `VideoID` = `Video`.`VideoID`
      )
   )
)
LEFT JOIN `Genre` ON `Genre`.`GenreID` IN (
   SELECT `GenreID` FROM `Location2Genre` WHERE `LocationID` = `Location`.`LocationID`
   UNION SELECT `GenreID` FROM `Product2Genre` WHERE `ProductID` = `Product`.`ProductID`
   UNION SELECT `GenreID` FROM `Image2Genre` WHERE `ImageID` = `Image`.`ImageID`
   UNION SELECT `GenreID` FROM `Video2Genre` WHERE `VideoID` = `Video`.`VideoID`
)
LEFT JOIN `Title` ON `Title`.`TitleID` IN (
   SELECT `TitleID` FROM `Location2Title` WHERE `LocationID` = `Location`.`LocationID`
   UNION SELECT `TitleID` FROM `Product2Title` WHERE `ProductID` = `Product`.`ProductID`
   UNION SELECT `TitleID` FROM `Type2Title` WHERE `TypeID` = `Type`.`TypeID`
   UNION SELECT `TitleID` FROM `Video2Title` WHERE `VideoID` = `Video`.`VideoID`
   UNION SELECT `TitleID` FROM `Genre2Title` WHERE `GenreID` = `Genre`.`GenreID`
   UNION SELECT `TitleID` FROM `Image2Title` WHERE `ImageID` = `Image`.`ImageID`
)
LEFT JOIN `Description` ON `Description` IN (
   SELECT `DescriptionID` FROM `Location2Description` WHERE `LocationID` = `Location`.`LocationID`
   UNION SELECT `DescriptionID` FROM `Product2Description` WHERE `ProductID` = `Product`.`ProductID`
   UNION SELECT `DescriptionID` FROM `Type2Description` WHERE `TypeID` = `Type`.`TypeID`
   UNION SELECT `DescriptionID` FROM `Video2Description` WHERE `VideoID` = `Video`.`VideoID`
   UNION SELECT `DescriptionID` FROM `Genre2Description` WHERE `GenreID` = `Genre`.`GenreID`
   UNION SELECT `DescriptionID` FROM `Image2Description` WHERE `ImageID` = `Image`.`ImageID`
)
LEFT JOIN `Text` ON `Text` ON `Text` IN (
   SELECT `TextID` FROM `Location2Text` WHERE `LocationID` = `Location`.`LocationID`
   UNION SELECT `TextID` FROM `Product2Text` WHERE `ProductID` = `Product`.`ProductID`
   UNION SELECT `TextID` FROM `Type2Description` WHERE `TypeID` = `Type`.`TypeID`
   UNION SELECT `TextID` FROM `Video2Description` WHERE `VideoID` = `Video`.`VideoID`
   UNION SELECT `TextID` FROM `Genre2Description` WHERE `GenreID` = `Genre`.`GenreID`
   UNION SELECT `TextID` FROM `Image2Description` WHERE `ImageID` = `Image`.`ImageID`
)

Alleen loopt deze vast op het moment dat ik op regel 12 tot en met 32 middels een 'subjoin' de GenreID wil bepalen voor de Genre2Image koppeling. Hier is opnieuw heel duidelijk te zien wat ik in begin van het topic voor probleem aangaf. Hoe krijg ik op regel 12 de GenreID's die gemaakt worden verder in de query op regel 33.

Zet ik de Genre-join eerst dan mis ik daar de Image-join en omgekeerd. Nu wilde ik zoals je ziet dit middels een subquery doen door gewoon de hele meuk opnieuw te joinen in een join, maar dat pikt hij niet...

[dusty]

Nieuwe Tip: Leer normalizeren, en ga dan nog eens je database model opstellen.

[Gerwin]

dusty schreef op zondag 10 februari 2008 @ 19:45:
Nieuwe Tip: Leer normalizeren, en ga dan nog eens je database model opstellen.

Ik dacht dat in het normaliseren toch al aardig onder de knie had. Feit is nu eenmaal dat het geheel niet makkelijk te normaliseren is. Dit komt omdat er 'meerdere lagen' zitten in de query. Toegespitst op het probleem de Image heeft een Genre, maar de Genre kan ook een Image hebben. Zou ik dus Image2Genre en Genre2Image tabel tot één laten samensmelten dan blijft het probleem bestaan.

Hoe krijgt de Image-join regel 12 de Genre-join data die later op regel 33 bepaald wordt? Dat wilde ik fixen door de hele meuk opnieuw in een subquery te bepalen, maar zoals ik het nu doe gaat het in elk geval niet werken...

Dat alles niet helemaal netjes gaat at begrijp ik, dat is meer dan eens gezegd in het topic. Desondanks wil ik toch proberen - al is het dan maar op een niet zo nette manier - dit voor elkaar te krijgen.

[Verwijderd]

Gerwin schreef op zondag 10 februari 2008 @ 20:11:

Ik dacht dat in het normaliseren toch al aardig onder de knie had. Feit is nu eenmaal dat het geheel niet makkelijk te normaliseren is.

Feit is dat jij het normaliseren niet beheerst. Ergens heb je de fout gemaakt om voor iets generieks te kiezen, en niet het ontwerp van de database toe te spitsen op jouw wensen en eisen.

Je zult altijd beperkingen moeten inbouwen. Je kunt niet "alles" opslaan in een database, en dat moet je helemaal niet willen. Dit ziet eruit als een database waarin elk product, elk type, elk genre, elke afbeelding en elke video aparte titels, omschrijvingen en tekst moeten kunnen hebben per bedrijf of locatie.

Je kiest er om onduidelijke redenen voor om zo ongeveer elke kolom in een aparte tabel te zetten. Denk eens bij jezelf: hoevaak bestaat er in de praktijk een database met 40 tabellen met elk 2 of 3 kolommen?

[Voutloos]

Gerwin schreef op zondag 10 februari 2008 @ 20:11:
Dat alles niet helemaal netjes gaat at begrijp ik, dat is meer dan eens gezegd in het topic.

Topic? Topics bedoel je. Topic na topic kom je met een vraag welke voortkomt uit een brak datamodel.

Desondanks wil ik toch proberen - al is het dan maar op een niet zo nette manier - dit voor elkaar te krijgen.

FF snel iets voor elkaar willen krijgen is 1 ding, maar als je continu tegen dezelfde problemen oploopt doe je toch consequent iets fout.

dusty schreef op zondag 10 februari 2008 @ 19:45:
Nieuwe Tip: Leer normalizeren, en ga dan nog eens je database model opstellen.

Eens, maar het is geen nieuwe tip. In eerdere topics zijn velen je voorgegaan en hebben velen de moed opgegeven.

[Gerwin]

Dat het allemaal niet gebruikelijk is om het te doen zou ik niet weten hoe ik anders de bepaalde zaken wel aan elkaar kan koppelen. Daarom is mijn vraag vanaf het begin van het topic ook om afgezien van de netheid en gebruikelijkheid: 'als je echt zoiets wilt doen hoe het dan voor elkaar te krijgen'. Nu alle zaken gewoon in tabellen staan moet het toch mogelijk zijn dit voor elkaar te boksen?

Inmiddels heb ik de volgende query. Dit is wat ik nu heb, dit lijkt op wat ik bedoel.

SQL:

SELECT `Company`,`Location`,`Product`,`Type`,`Video`,`Image`,`Genre`,`Title`,`Description`,`Text`
FROM `Company`
LEFT JOIN `Location` ON `Location`.`CompanyID` = `Company`.`CompanyID`
LEFT JOIN `Location2Product` ON `Location2Product`.`LocationID` = `Location`.`LocationID`
LEFT JOIN `Product` ON `Product`.`ProductID` = `Location2Product`.`ProductID`
LEFT JOIN `Product2Type` ON `Product2Type`.`ProductID` = `Product`.`ProductID`
LEFT JOIN `Type` ON `Type`.`TypeID` = `Product2Type`.`TypeID`
LEFT JOIN `Video` ON `Video`.`VideoID` IN (
   SELECT `VideoID` FROM `Location2Video` WHERE `LocationID` = `Location`.`LocationID`
   UNION SELECT `VideoID` FROM `Product2Video` WHERE `ProductID` = `Product`.`ProductID`
)
LEFT JOIN `Image` ON `Image`.`ImageID` IN (
   SELECT `ImageID` FROM `Location2Image` WHERE `LocationID` = `Location`.`LocationID`
   UNION SELECT `ImageID` FROM `Product2Image` WHERE `ProductID` = `Product`.`ProductID`
   UNION SELECT `ImageID` FROM `Video2Image` WHERE `VideoID` = `Video`.`VideoID`
   UNION SELECT `ImageID` FROM `Genre2Image` WHERE `GenreID` IN (
      SELECT `GenreID` 
      FROM `Company` as `tmpCompany`
      LEFT JOIN `Location` `tmpLocation` ON `tmpLocation`.`CompanyID` = `tmpCompany`.`CompanyID`
      LEFT JOIN `Location2Product` `tmpLocation2Product` ON `tmpLocation2Product`.`LocationID` = `tmpLocation`.`LocationID`
      LEFT JOIN `Product` `tmpProduct` ON `tmpProduct`.`ProductID` = `tmpLocation2Product`.`ProductID`
      LEFT JOIN `Product2Type` `tmpProduct2Type` ON `tmpProduct2Type`.`ProductID` = `tmpProduct`.`ProductID`
      LEFT JOIN `Type` `tmpType` ON `tmpType`.`TypeID` = `tmpProduct2Type`.`TypeID`
      LEFT JOIN `Video` `tmpVideo` ON `tmpVideo`.`VideoID` IN (
         SELECT `VideoID` FROM `Location2Video` AS `tmpLocation2Video` WHERE `LocationID` = `tmpLocation`.`LocationID`
         UNION SELECT `VideoID` FROM `Product2Video` AS `tmpProduct2Video`  WHERE `ProductID` = `tmpProduct`.`ProductID`
      )
      LEFT JOIN `Image` `tmpImage` ON `tmpImage`.`ImageID` IN (
         SELECT `ImageID` FROM `Location2Image` AS `tmpLocation2Image` WHERE `LocationID` = `tmpLocation`.`LocationID`
         UNION SELECT `ImageID` FROM `Product2Image` AS `tmpProduct2Image` WHERE `ProductID` = `tmpProduct`.`ProductID`
         UNION SELECT `ImageID` FROM `Video2Image` AS `tmpVideo2Image` WHERE `VideoID` = `tmpVideo`.`VideoID`
      )
      LEFT JOIN `Genre` `tmpGenre` ON `tmpGenre`.`GenreID` IN (
         SELECT `GenreID` FROM `Location2Genre` AS `tmpLocation2Genre` WHERE `LocationID` = `tmpLocation`.`LocationID`
         UNION SELECT `GenreID` FROM `Product2Genre` AS `tmpProduct2Genre` WHERE `ProductID` = `tmpProduct`.`ProductID`
         UNION SELECT `GenreID` FROM `Image2Genre` AS `tmpImage2Genre` WHERE `ImageID` = `tmpImage`.`ImageID`
         UNION SELECT `GenreID` FROM `Video2Genre` AS `tmpVideo2Genre` WHERE `VideoID` = `tmpVideo`.`VideoID`
      )
   )
)
LEFT JOIN `Genre` ON `Genre`.`GenreID` IN (
   SELECT `GenreID` FROM `Location2Genre` WHERE `LocationID` = `Location`.`LocationID`
   UNION SELECT `GenreID` FROM `Product2Genre` WHERE `ProductID` = `Product`.`ProductID`
   UNION SELECT `GenreID` FROM `Image2Genre` WHERE `ImageID` = `Image`.`ImageID`
   UNION SELECT `GenreID` FROM `Video2Genre` WHERE `VideoID` = `Video`.`VideoID`
)
LEFT JOIN `Title` ON `Title`.`TitleID` IN (
   SELECT `TitleID` FROM `Location2Title` WHERE `LocationID` = `Location`.`LocationID`
   UNION SELECT `TitleID` FROM `Product2Title` WHERE `ProductID` = `Product`.`ProductID`
   UNION SELECT `TitleID` FROM `Type2Title` WHERE `TypeID` = `Type`.`TypeID`
   UNION SELECT `TitleID` FROM `Video2Title` WHERE `VideoID` = `Video`.`VideoID`
   UNION SELECT `TitleID` FROM `Genre2Title` WHERE `GenreID` = `Genre`.`GenreID`
   UNION SELECT `TitleID` FROM `Image2Title` WHERE `ImageID` = `Image`.`ImageID`
)
LEFT JOIN `Description` ON `Description`.`DescriptionID` IN (
   SELECT `DescriptionID` FROM `Location2Description` WHERE `LocationID` = `Location`.`LocationID`
   UNION SELECT `DescriptionID` FROM `Product2Description` WHERE `ProductID` = `Product`.`ProductID`
   UNION SELECT `DescriptionID` FROM `Type2Description` WHERE `TypeID` = `Type`.`TypeID`
   UNION SELECT `DescriptionID` FROM `Video2Description` WHERE `VideoID` = `Video`.`VideoID`
   UNION SELECT `DescriptionID` FROM `Genre2Description` WHERE `GenreID` = `Genre`.`GenreID`
   UNION SELECT `DescriptionID` FROM `Image2Description` WHERE `ImageID` = `Image`.`ImageID`
)
LEFT JOIN `Text` ON `Text`.`TextID` IN (
   SELECT `TextID` FROM `Location2Text` WHERE `LocationID` = `Location`.`LocationID`
   UNION SELECT `TextID` FROM `Product2Text` WHERE `ProductID` = `Product`.`ProductID`
   UNION SELECT `TextID` FROM `Type2Description` WHERE `TypeID` = `Type`.`TypeID`
   UNION SELECT `TextID` FROM `Video2Description` WHERE `VideoID` = `Video`.`VideoID`
   UNION SELECT `TextID` FROM `Genre2Description` WHERE `GenreID` = `Genre`.`GenreID`
   UNION SELECT `TextID` FROM `Image2Description` WHERE `ImageID` = `Image`.`ImageID`
)

[curry684]

Holy shit wat is dat, de 12e normaalvorm of zo?

[MueR]

Respect hoor

Dit kan zo in de categorie "Hoe snel blaas ik mijn database server op wanneer dit drakenbeestje een paar keer draait".

[RobIII]

Normaliter ben ik niet zo van "het reeds bevestigde nogmaals bevestigen"...maar holy...
Ik kan dan ook alleen nogmaals nablaten wat anderen zeggen: neem een lesje of 2 in normaliseren en vraag je eens heel goed af wat je nou eigenlijk wil bereiken. Dit gaat nergens meer over

[BCC]

Inderdaad, koop een boek of volg een studie!

[ACM]

curry684 schreef op zondag 10 februari 2008 @ 21:49:
Holy shit wat is dat, de 12e normaalvorm of zo?

Volgens mij is dit de 6e, althans als ik het me goed herinner is dat de normaalvorm met per tabel hooguit drie kolommen. Hoewel het ook weer niet helemaal goed gedaan wordt nu, want het lijkt me niet dat er in de 6e normaalvorm alle text-velden uiteindelijk naar een tabel worden geschreven, alleen maar omdat het text-velden zijn.

Magoed, in elk (goed) boek dat de normaalvormen behandelt wordt ook direct genoemd dat je over het algemeen niet verder dan de 3e en bij uitzondering de 4e hoeft te gaan...

[Creepy]

Eeeh.. zie OnTracK in "[Mysql] meerdere JOIN's in één, JOIN met...". Daarin staan twee vragen:

1) Wat wil je opslaan
2) Wat wil je nou eigenlijk selecteren?

Als ik het topic, de queries en het gegeven schema bekijk is me dat echt totaal onduidelijk. Wat ben je nu aan het opslaan en wat wil je nu selecteren? Zou je dat voor mij kunnen uitleggen zodat ik het zou kunnen proberen te snappen wat je nu probeert te doen en waarom je dit wilt?

[curry684]

Wat me nog het meest shockeert aan dit datamodel is nog niet eens de keuze om Title, Text en Description af te splitsen naar losse tabellen: dat is gewoon een ondubbelzinnige zotte fout der overnormalisatie, daar hoeft weinig discussie over te bestaan. Nee, ik kijk met name met wijd open mond naar de aanwezigheid van Video2Image, Video2Genre, Image2Genre en Genre2Image. Wat de neuk probeer je daar nu mee te bereiken? Nog afgezien van het feit dat de eerste 3 samen al tot redelijk zotte situaties gaan leiden (images hebben een ander genre dan hun bijbehorende video, wtf?) klapt m'n stem weg bij de aanwezigheid van de laatste 2: de relatie van image naar genre is een andere dan die van genre naar image? Bedoel je daarmee nu te zeggen dat je voorbeeldplaatjes bij een genre wil kunnen toevoegen en tegelijkertijd een genre aan plaatjes wil kunnen hangen?

Please, omschrijf nu eens je business case, wat probeer je op te lossen en wat is het doel van deze database. Gewoonlijk kun je uit een beetje ERD direct de globale business case afleiden, maar ook dat lukt me in dit geval niet, het beste wat ik kan gokken is dat je iets voor een videotheek aan het bouwen bent.

Je probleem zit 'm ook nog niet eens zozeer in het normaliseren, maar in dat je je database niet voor een doel aan het bouwen bent. Ja, theoretisch heb je nu een super-database waarin je iedere mogelijke toepassing van Images, Videos, Companies en Genres in hebt opgeborgen, maar daarmee los je nog steeds niemands' probleem op. Simpelweg world logic op je probleem toepassen kan dit walgelijke ERD reeds 5 keer kleiner en simpeler maken. Leg het ons uit en we doen het je echt graag voor.

[Cavorka]

Gerwin schreef op zondag 10 februari 2008 @ 21:29:
[code=sql](... INSERT THE MOTHER OF ALL QUERIES HERE ...)

Ik kon echt niet stoppen met lachen toen ik deze query zag. Niet echt bijzonder dat je daar niet in een keer op kwam... O M F'ing GOD.

Als dit ook echt de oplossing is, dan is er iets grondig mis in je datamodel, maar daar waren meer mensen geloof ik ook al mee naar voren gekomen.

Dit topic is echt way, way beyond 'Slechtste programmeervoorbeelden deel 3'. Maar evengoed wel indrukwekkend natuurlijk, als exercise en brainfuck, maar als echt real life voorbeeld is het een beetje beangstigend.

[? ?]

Verwijderd schreef op zondag 10 februari 2008 @ 20:23:
Dit ziet eruit als een database waarin elk product, elk type, elk genre, elke afbeelding en elke video aparte titels, omschrijvingen en tekst moeten kunnen hebben per bedrijf of locatie.

Wat de TS kan doen -naast normaal te leren normaliseren- is zijn ideeën wat te minderen. Begin met wat simpels, wil je een product dat je aan verschillende bedrijfjes wil aanbieden, maak een aparte database voor elk bedrijfje en/of locatie. Zo heb je al wat minder tabellen en technisch gezien is het beter voor je performance (je kan scalen als je 1000 bedrijfjes hebt), eenvoudiger voor backups en veiliger.

Je moet niet álles willen in één website, wat jij probeert is zo'n beetje een auto te maken die kan vliegen, rijden, varen, duiken, koken en stofzuigen.. Begin met wat eenvoudig en brij er wat aan.

Wat ik me ook afvraag is wat er met je vorig project gebeurd is? [Mysql] Complexe query (meer-op-meer relatie) 5 tabellen
Daar had je winkels met producten en kleuren en die kleuren hadden vast ook weer producten...
De vraag is: waar haal je deze projecten vandaan? Als je zoiets voor de fun maakt: stop er mee en begin met een basis-database projecten (klanten-facturen-factuurregels) da's ook al leuk om te doen

Verder mag Gerwin ook eens in zijn eigen woorden schrijven wat er allemaal benodigd is voor het project en hoe het in elkaar zit (vanuit een standpunt van een niet IT-er, zoals het met papier en pen zou werken). Zo begin je namelijk aan elk IT project: je laat je klant mooi uitleggen wat hij wil in gewoon Nederlands.
Als iemand bij mij begint met "ik zou daar graag een knop hebben en dan moet..." zeg ik: begin maar opnieuw en nu zonder "knoppen".

btw: dit topic is gieren

[ Voor 31% gewijzigd door ? ? op 11-02-2008 00:42 ]

[LoBbY_1]

Pff... Kijk eens naar oracle datawarehouse builder... Misschien dat je daar wat verder mee komt. Dan kan je ook alles schematisch opstellen. Je kan dan erg makkelijk een hele ingewikkelde join maken. En attributen toevoegen (filters if/else constructies enz..) Verder kan je ook nog een starjoin maken om vervolgens verder met je data analyse te gaan..

Dit is echt vreemd haha, maar wel leuk om te zien Verder begrijp ik het commentaar over het leren normaliseren wel...

[? ?]

deleted

[ Voor 100% gewijzigd door ? ? op 11-02-2008 00:54 ]

[curry684]

Ik heb even Visio aangeslingerd en het volgende model getekend:



Ik denk zelf dat je hiermee alles kan wat je wil en nodig hebt, en ben erg benieuwd naar welke tekortkomingen ik hier ingestopt heb. Sterker nog, met dit model kun je wel bijvoorbeeld aangeven hoeveel exemplaren van een bepaald produkt er op een bepaalde locatie slingeren. Oh en met dit model zijn INSERTs wel simpel te realiseren, shockeer je me als je ooit een UNION nodig gaat hebben, en kan ik me geen realistische query voorstellen die meer dan 8 joins vereist in het ergste geval, laat staan subqueries.

[Gerwin]

curry684 schreef op maandag 11 februari 2008 @ 01:00:
Ik heb even Visio aangeslingerd en het volgende model getekend:

[afbeelding]

Ik denk zelf dat je hiermee alles kan wat je wil en nodig hebt, en ben erg benieuwd naar welke tekortkomingen ik hier ingestopt heb. Sterker nog, met dit model kun je wel bijvoorbeeld aangeven hoeveel exemplaren van een bepaald produkt er op een bepaalde locatie slingeren. Oh en met dit model zijn INSERTs wel simpel te realiseren, shockeer je me als je ooit een UNION nodig gaat hebben, en kan ik me geen realistische query voorstellen die meer dan 8 joins vereist in het ergste geval, laat staan subqueries.

Dank je wel voor de tijd die je in dit topic steekt. Het schema wat je gemaakt hebt komt heel erg overeen met wat het doel is. Het begint me wel duidelijk te worden waarom bepaalde zaken niet of moeilijk kunnen. In het idee mis ik bijvoorbeeld de volgende zaken.

• Location heeft een eigen reeks Title's. Denk hier aan een extra Title die voor alle rows toegevoegd word van die Location bijvoorbeeld "Verkocht op Location 1".
• Location heeft een eigen reeks Description's, idem als voor Title.
• Location heeft een eigen reeks Text's, idem als voor Title.
• Location heeft een eigen reeks Image's, idem als voor Title, met toevoeging dat de Image's op hun beurt ook Title, Description, Text, Genre, Video's kunnen toevoegen.
• Location heeft een eigen reeks Video's, idem als voor Title, met toevoeging dat de Video's op hun beurt ook Title, Description, Text, Genre, Image's kunnen toevoegen.
• Location heeft een eigen reeks Genre's. Dit heeft oorspronkelijk als doel zodat als een Product toegevoegd word op een Location deze standaard een Genre bevat zonder afzonderlijk dat Genre te moeten opgeven. Bijvoorbeeld een Location verkoopt alleen Producten met Genre A, je voegd een nieuw product toe, deze heeft automatisch Genre A omdat die Location enkel die Genre verkoopt. Genre's kunnen op hun beurt ook Title, Description, Text en Image's hebben.
• Type heeft een eigen reeks Image's. Denk hier aan een extra Image die voor alle rows toegevoegd wordt van dat Product bijvoorbeeld een Image met een kleur erop, Daarnaast zullen die Imageś op hun beurt ook Title (de tekst 'rood', 'blauw'), Description en Text.
• Genre heeft een eigen reeks Image's. Een plaatje dat bij het Genre hoort. Als we het bijvoorbeeld over een boek hebben dan heeft deze op Type een plaatje (plaatje van een boek). Daarbaast voor het Genre (fantasy bijvoorbeeld) word een extra plaatje toegevoegd. Met toevoeging dat de Image's op hun beurt ook Title, Description, Text, Genre, Video's kunnen toevoegen.
• Video's hebben eigen Image's. Bijvoorbeeld een reeks caps van de Video. Dit hoort niet direct bij het Product maar als de Video gekoppeld is aan het Product moeten die plaatjes ook daar toegevoegd worden. Met toevoeging dat de Image's op hun beurt ook Title, Description, Text en Genre kunnen toevoegen.
• Video's hebben eigen Genre. Ik wil in een andere query ook de Video's van een Genre kunnen selecteren, en als er een Video is die niet gekoppeld is aan een Product dan gaat dat niet.

Er zitten een aantal relaties bij die het doel hebben om dingen gemakkelijker te maken als iets toegevoegd word. Zoals aangegeven als ik aan de Location een Titel koppel en ik voeg vervolgens iets toe aan die Location dan heb ik automatisch die Titel erbij en hoef ik niet alles handmatig na te lopen. Dit geld voor de Location ook met Images, Video's.

Daarnaast zitten er een aantal zaken in die ook als doel hebben om dingen makkelijker te maken bij het toevoegen. Geeft ik aan Product een Type mee (een kleur ofzo). Dan wil ik automatisch ook alle Titels hebben van dat type "Titel Blauw", en de Image's "Image Blauw", NAAST de reguliere zaken die toch al aan het Product gekoppeld zaten zegmaar.

Zoals in je schema heeft een Product een Image, Genre, Type en Video. Laten we zeggen dat we een camera toevoegen met in alle andere tabellen een recors. Image van de camera, Genre is camera's, Type is zwart en een Video van de camera in aktie. Aan de Type voegen we een compleet zwart plaatje toe. In als we een query maken krijgen we twee rows: eentje met een plaatje van de camera en eentje met dat complete zwarte plaatje. De reden dat ik dat complete zwarte plaatje aan de Type toevoeg is dat het meer zegt over het Type dan over de camera. Laten we twee nieuwe camera's van Type zwart toevoegen. Automatisch heb ik alle plaatjes erbij zonder dat ik apart het complete zwarte plaatje apart moet toevoegen. Ook alle andere data dat 'hangt' aan de andere tabellen heb ik automatisch erbij.

[curry684]

Gerwin schreef op maandag 11 februari 2008 @ 18:08:
[...]

• Location heeft een eigen reeks Title's. Denk hier aan een extra Title die voor alle rows toegevoegd word van die Location bijvoorbeeld "Verkocht op Location 1".

Maar hoe kom je erbij dat dat een Title zou zijn van Location? Als je sales wil opslaan van een product, maak je een entity Sale of Order met een foreign key naar Location en Product, dan ga je dat niet ten koste van alles in je bestaande entiteiten frotten. Een database is geoptimaliseerd voor veel relaties tussen veel tabellen onderhouden, je cripplet 'm juist als je 'm dat niet laat doen.

• Location heeft een eigen reeks Description's, idem als voor Title.
• Location heeft een eigen reeks Text's, idem als voor Title.

Kijk en het woord 'reeks' hier is waar je steeds de mist op in gaat. Een Location heeft een Description, zonder 'reeks', want de Description van een Location is een unieke property van 1 enkele Location, niet een relatie van een Location. Er is bijna geen verdedigbare reden om dingen als title en description naar een losse tabel af te splitsen, hoogstens als je met vertalingen bezig bent of alternative titles, maar dan nog maak je een gerichte afsplitsing, geen generieke catch-all die alleen een puinzooi maakt van je maintainability.

• Location heeft een eigen reeks Image's, idem als voor Title, met toevoeging dat de Image's op hun beurt ook Title, Description, Text, Genre, Video's kunnen toevoegen.

Voeg die dan als property toe aan je Image

• Location heeft een eigen reeks Video's, idem als voor Title, met toevoeging dat de Video's op hun beurt ook Title, Description, Text, Genre, Image's kunnen toevoegen.

Maar waarom heeft een location video's, en waarin komen die overeen met de video's van produkten?

[...knip rest....]

Er zitten een aantal relaties bij die het doel hebben om dingen gemakkelijker te maken als iets toegevoegd word.

Maar feitelijk ben je het jezelf alleen maar moeilijk aan het maken door dingen overgeneriek te maken. Focus op je business case, en leg alleen relaties op dingen die relaties zijn, en voeg properties toe als properties. En probeer te voorkomen dat je potentiele relaties of properties gaat toevoegen die geen enkel ander doel dienen dan generiek zijn, want dan ben je dus aan het overnormaliseren.

Hoe dan ook, zelfs als ik alle relaties toevoeg die je nu in je business case omschrijft krijg je nooit queries die het moeilijk maken. Want je vraagt in alle situaties hoe dan ook alleen een op dat moment relevante subset van je gespecificeerde data op, en nooit een monsterquery from hell van 70 regels. Want als je alle data tegelijk in je programma wil hebben, waarom heb je dan nog een databeest?

[Confusion]

Gerwin schreef op maandag 11 februari 2008 @ 18:08:
• Location heeft een eigen reeks Title's. Denk hier aan een extra Title die voor alle rows toegevoegd word van die Location bijvoorbeeld "Verkocht op Location 1".

Laten we hier eens mee beginnen. Wat bedoel je met 'alle rows van een location'? Een enkele 'location' is een enkele rij in de Location tabel. Als er een unieke verkooptekst vastgelegd moet worden voor die 'location', dan krijgt de Location tabel een kolom 'verkooptekst'. Als er veel van dat soort teksten zijn, dan voeg je geen extra kolom voor iedere tekst toe, maar maak je een losse tabel 'LocationTeksten'. Wat je niet doet, zoals we je de vorige keer ook al vertelden, is die locatiespecifieke teksten aan een generieke 'title' tabel toevoegen, waar ook productTitles, genreTitles, imageTitles en fooBarTitles instaan.

Een product heeft 1 enkele productTitle. Deze kan in de kolom van het product opgenomen worden. Als een location de title van een product moet kunnen overriden, dan maak je een tabel locationProductTitles, waarin een locationId, een productId en een titleOverride zitten. Vervolgens selecteer je de titel van een product voor een bepaalde location middels een COALESCE(locationProductTitle, productTitle), waarbij de locationProductTitle meestal NULL zal zijn en je dus de 'default' productTitle eruit krijgt.

[Gerwin]

curry684 schreef op dinsdag 12 februari 2008 @ 00:14:
[...]

Maar hoe kom je erbij dat dat een Title zou zijn van Location? Als je sales wil opslaan van een product, maak je een entity Sale of Order met een foreign key naar Location en Product, dan ga je dat niet ten koste van alles in je bestaande entiteiten frotten. Een database is geoptimaliseerd voor veel relaties tussen veel tabellen onderhouden, je cripplet 'm juist als je 'm dat niet laat doen.

Via de Location wil ik Title kunnen toevoegen aan de Producten zegmaar. Het is moeilijk uit te leggen wat ik hier mee wil bereiken, maar ik zal nogmaals een poging doen.

Neem aan dat voor deze 'subcase' er twee Locations zijn met elk twee Products. De Products hebben alle twee twee Titles. Doen we hier een query op zouden er acht rows terugkomen.

code:

Location 1 - Product 1 - Title 1
Location 1 - Product 1 - Title 2
Location 1 - Product 2 - Title 1
Location 1 - Product 2 - Title 2
Location 2 - Product 1 - Title 1
Location 2 - Product 1 - Title 2
Location 2 - Product 2 - Title 1
Location 2 - Product 2 - Title 2

Als ik nu Title 3 aan de Producten wil toevoegen die in Location 1 staan zou ik in jou schema dit heel makkelijk kunnen doen. (select ProductID from ProductInLocation where Location = 1) en dan inserten in ProductTitle. Nu voeg ik achteraf ook Product 2 aan Location 1 toe. (insert into ProductInLocation), maar nu hebben die Producten niet die Titels die ik eerder als opgegeven.

Dit dacht ik op te lossen middels een nieuwe relatietabel (Location2Title). Op die manier staat vast ten alle tijde dat er Titles aan de Producten moeten worden toegevoegd. Hoe doe jij dat dan in jou visie?

Kijk en het woord 'reeks' hier is waar je steeds de mist op in gaat. Een Location heeft een Description, zonder 'reeks', want de Description van een Location is een unieke property van 1 enkele Location, niet een relatie van een Location. Er is bijna geen verdedigbare reden om dingen als title en description naar een losse tabel af te splitsen, hoogstens als je met vertalingen bezig bent of alternative titles, maar dan nog maak je een gerichte afsplitsing, geen generieke catch-all die alleen een puinzooi maakt van je maintainability.

Volgens mij zit het niet in het woord 'reeks'. Maakt het echt zoveel uit of in bovenstaande case één of twee Title's toegevoegd word aan Products op basis van de Location van de Producten? Het probleem zit hem in het feit dat als na dat de Titles zijn toegevoegd op basis van de Producten in Location het voor volgende Producten toegevoegd aan die Location niet te weten meer is dat ze ook een extra Title krijgen.

Voeg die dan als property toe aan je Image

Dat kan, maar dat doe ik toch, alleen net als bij bovenstaande case met de Title voor Location voegt de Image een Title toe aan Product.

Maar waarom heeft een location video's, en waarin komen die overeen met de video's van produkten?

Neem bijvoorbeeld aan dat deze Video een reclamespotje is van die Location. Deze heeft eigen Titels, Descriptions, Text, Genre, en Images (caps bijvoorbeeld). Alle producten voor die Location moeten dus ook die Video hebben, met alle Title, Description, Text, Genre, Image koppelingen.
[/]

Maar feitelijk ben je het jezelf alleen maar moeilijk aan het maken door dingen overgeneriek te maken. Focus op je business case, en leg alleen relaties op dingen die relaties zijn, en voeg properties toe als properties. En probeer te voorkomen dat je potentiele relaties of properties gaat toevoegen die geen enkel ander doel dienen dan generiek zijn, want dan ben je dus aan het overnormaliseren.

Het relaties leggen is in feite zoals jij in je schema aangeeft. Maar via die extra tabellen wil ik het mogelijk maken om heel simpel dingen te kunnen toevoegen. (zoals bij die Title voor Location). Ik zou niet weten hoe als ik dat anders dan met een aparte tussentabel kan realiseren.[/]

Hoe dan ook, zelfs als ik alle relaties toevoeg die je nu in je business case omschrijft krijg je nooit queries die het moeilijk maken. Want je vraagt in alle situaties hoe dan ook alleen een op dat moment relevante subset van je gespecificeerde data op, en nooit een monsterquery from hell van 70 regels. Want als je alle data tegelijk in je programma wil hebben, waarom heb je dan nog een databeest?

Die tabellen die ik opnoem naast je tabellen in je schema zijn eigenlijk 'configuratie' tabellen, maar ik begrijp wat je bedoeld en ik begin een heel stuk verder te komen. Als dit niet in een query kan moet via een php script op het moment dat er een product toegevoegd wordt gekeken worden in die 'configuratie' tabellen of er een Title extra moet zijn voor Location ofzo.

Confusion schreef op dinsdag 12 februari 2008 @ 08:37:
[...]

Laten we hier eens mee beginnen. Wat bedoel je met 'alle rows van een location'? Een enkele 'location' is een enkele rij in de Location tabel. Als er een unieke verkooptekst vastgelegd moet worden voor die 'location', dan krijgt de Location tabel een kolom 'verkooptekst'. Als er veel van dat soort teksten zijn, dan voeg je geen extra kolom voor iedere tekst toe, maar maak je een losse tabel 'LocationTeksten'. Wat je niet doet, zoals we je de vorige keer ook al vertelden, is die locatiespecifieke teksten aan een generieke 'title' tabel toevoegen, waar ook productTitles, genreTitles, imageTitles en fooBarTitles instaan.

Hiermee bedoel ik alle rows die voortkomen uit de 'Location. Als er bijvoorbeeld 10 Producten zijn op die Location krijgen die allemaal 'Verkocht op Location 1' als extra Title. Het is inderdaad een soort verkooptekst, maar wel zegmaar 'dezelfde kolom, als de Titel van het Product. En de Titel van de Image's van dat Product, Titel van de Genre van dat Product...

Ik begin het idee wat je hebt te begrijpen, alleen of het dan mog mogelijk is te doen wat ik wil bereiken is me nog niet duidelijk. In elk geval is zoiets dan niet op te vangen in één enkele query, maar zou middels meerdere query's en wat php code tabellen bijgewerkt moeten worden op basis van die configuratiedata ofzo.

Een product heeft 1 enkele productTitle. Deze kan in de kolom van het product opgenomen worden. Als een location de title van een product moet kunnen overriden, dan maak je een tabel locationProductTitles, waarin een locationId, een productId en een titleOverride zitten. Vervolgens selecteer je de titel van een product voor een bepaalde location middels een COALESCE(locationProductTitle, productTitle), waarbij de locationProductTitle meestal NULL zal zijn en je dus de 'default' productTitle eruit krijgt.

Overriden is niet het juiste woord. Ik wil 'extra rows' krijgen op die manier. Zoals ik eerder in mijn post heb aangegeven over die Location met een Title die extra Titles toevoegd aan de Product. Om die reden wilde ik ze 'samenvoegen' of laten 'samensmelten' tot één kolom.

[Gerwin]

Ik heb een nieuw schema gemaakt met de tips die ik gekregen heb in dit topic.



Deze tabellen zijn in mijn ogen echt nodig. Ik heb een groot aantal laten vallen maar waar ik niet uit ben gekomen is op welke manier ik dan onder andere de volgende akties kan doen:

• Location van Product en Video voegt een Title/Description/Text toe.
• Location van Product en Video voegt een Image toe, vervolgens voegt de Image Title/Description/Text toe op de Product/Video.

• Genre van Product en Video voegt een Title/Description/Text toe.
• Genre van Product en Video voegt een Image toe, vervolgens voegt de Image Title/Description/Text toe op de Product/Video.

• Type van Product voegt een Title/Description/Text toe.
• Type van Product voegt een Image toe, vervolgens voegt de Image Title/Description/Text toe op het Product.

[dusty]

Antwoord de volgende vragen eens:

1) Hoeveel titels heeft EEN product?
2) Hoeveel beschrijvingen heeft EEN product?
3) Hoeveel Texten heeft EEN product?
4) Hoeveel titels heeft EEN video?
5) Hoeveel beschrijvingen heeft EEN video?
6) Hoeveel Texten heeft EEN video?

En de vragen die jij hebt duiden erop dat je schema inderdaad nog niet is wat jij wilt hebben.

[Verwijderd]

Gerwin schreef op dinsdag 12 februari 2008 @ 11:33:
Als ik nu Title 3 aan de Producten wil toevoegen die in Location 1 staan zou ik in jou schema dit heel makkelijk kunnen doen. (select ProductID from ProductInLocation where Location = 1) en dan inserten in ProductTitle. Nu voeg ik achteraf ook Product 2 aan Location 1 toe. (insert into ProductInLocation), maar nu hebben die Producten niet die Titels die ik eerder als opgegeven.

Ik zit werkelijk me hoofd te breken wat je hier bedoelt... en waarom jij denkt dat het fout gaat.
Als je "Title 3" toevoegt aan "Product 1", dan heeft dát product een extra titel.
Dat er meerdere locations zijn waar dát product ligt, heeft er eigenlijk niets mee te maken. Je moet dan niet zeggen dat die locations een extra titel erbij krijgen, want dat klopt niet.

Stel dat je bijvoorbeeld een type-fout had gemaakt in de titel? Dan wijzig je dat toch ook bij dát product, en daardoor verandert de titel ook in elke location die dát product heeft...

[ Voor 3% gewijzigd door Verwijderd op 22-02-2008 11:35 ]

[Gerwin]

dusty schreef op vrijdag 22 februari 2008 @ 03:38:
Antwoord de volgende vragen eens:

1) Hoeveel titels heeft EEN product?
2) Hoeveel beschrijvingen heeft EEN product?
3) Hoeveel Texten heeft EEN product?
4) Hoeveel titels heeft EEN video?
5) Hoeveel beschrijvingen heeft EEN video?
6) Hoeveel Texten heeft EEN video?


En de vragen die jij hebt duiden erop dat je schema inderdaad nog niet is wat jij wilt hebben.

Een Product heeft meerdere titels:
Titel van het Product:
• select ProductID from Product'
• 'insert into Title (Title) values ($Title)
• 'insert into Product2Title (ProductID,TitleID) values ($ProductID,$TitleID)
Titel van de Image van Product & Video
• select ProductID from Product2Image where ProductID = $ProductID
• insert into Title (Title) values ($Title)
• insert into Product2Title (ProductID,TitleID ) values ($ProductID,$TitleID)
Titel van Genre van Product & Video
• select ProductID from Product2Genre where ProductID = $ProductID
• insert into Title (Title) values ($Title)
• insert into Product2Title (ProductID,TitleID ) values ($ProductID,$TitleID)
Titel van de Type van Product & Video
• select ProductID from Product2Type where ProductID = $ProductID
• insert into Title (Title) values ($Title)
• insert into Product2Title (ProductID,TitleID ) values ($ProductID,$TitleID)

Waar hier Product staat worden dezelfde query's ook tegelijktijdig voor Video uitvoerd

Natuurlijk geld dit alles ook voor de Description en Text

---

Daarnaast voeg ik de volgende zaken makkelijk toe:

• Product / Video, toevoegen
• Genre van Product / Video, toevoegen
• Niche van Product / Video, toevoegen
• Location van Product / Video, toevoegen
• Titel van Product / Video, toevoegen
• Description van Product / Video, toevoegen
• Text van Product / Video toevoegen
• Type van Product toevoegen

Deze 'makkelijke' dingen is het probleem niet zozeer. Maar hoe bijvoorbeeld te doen:
Voor elke Product / Video waar 'Image = 1' doe extra Titel erbij.

Dit gaat met de eerdergenoemde query's, maar als ik hem dan wil verwijderen dan verwijders hij ook automatisch de Titel als deze wel mag bestaan op het product. Er ontstaat een conflict.

Verwijderd schreef op vrijdag 22 februari 2008 @ 11:34:
[...]

Ik zit werkelijk me hoofd te breken wat je hier bedoelt... en waarom jij denkt dat het fout gaat.
Als je "Title 3" toevoegt aan "Product 1", dan heeft dát product een extra titel.
Dat er meerdere locations zijn waar dát product ligt, heeft er eigenlijk niets mee te maken. Je moet dan niet zeggen dat die locations een extra titel erbij krijgen, want dat klopt niet.

Stel dat je bijvoorbeeld een type-fout had gemaakt in de titel? Dan wijzig je dat toch ook bij dát product, en daardoor verandert de titel ook in elke location die dát product heeft...

Volgens mij loopt dit ergens fout of omdat het product bijvoorbeeld een Titel heeft en het product een titel van een image heeft gekregen. Maar als deze titel vervolgens verwijderd wordt van de Image dan gaat deze ook weg bij het product, terwijl dat voor dat product juist moet blijven bestaan.

---

Bijvoorbeeld:

(dit loopt natuurlijk ook op de Video tabellen, maar om het overzichtelijk te houden geeft ik hier alleen de Product-tabellen 'editie')

Voeg Titel toe op Product
• insert into Title (TitleID) values ($Title)
• insert into Product2Title (ProductID,TitleID) values ($ProductID,$TitleID)

Voeg Image toe op Product
• insert into Image (ImageID) values ($Image)
• insert into Product2Image (ProductID,ImageID) values ($ProductID,$ImageID)

We voegen een titel op de image door, product krijgt dus ook de titel van de image

Voeg Titel toe op Image
• select ProductID from Product2Image where ImageID = $ImageID
• insert into Title (Title) values ($Title)
• insert into Product2Title (ProductID,TitleID ) values ($ProductID,$TitleID)

Nu wis ik de titel van de image.

Delete Titel op Image
• select ProductID from Product2Image where Image = $ImageID
• delete from Product2Title where ProductID = $ProductID and TitleID = $TitleID

Maar heb ik nu niet ook de Titel van het Product verwijderd?

[RobIII]

Gerwin schreef op vrijdag 22 februari 2008 @ 15:23:
[...]

Een Product heeft meerdere titels:
Titel van het Product:
• select ProductID from Product'
• 'insert into Title (Title) values ($Title)
• 'insert into Product2Title (ProductID,TitleID) values ($ProductID,$TitleID)

...en daarna ben ik je kwijt hoor
Is dat een onderbouwing voor je 'meerdere titels'?

Heeft een product 1 titel? Of meer?

Heet een product (ID = 1719):
• 1719: "Bavaria pilsener bier"

of

• 1719: "Bavaria pilsener bier"
én
• 1719: "Dommelsch pilsener bier"
én
• 1719: "Amstel pilsener bier"
én ...
?

Doorgaans heeft een product maar 1 titel hoor; alleen in uitzonderlijke gevallen en zelfs dan zou ik een alias veld toevoegen en dus niet een compleet nieuwe tabel introduceren. Wil je ook Amstel en Dommelsch gaan verkopen dan zijn dat nieuwe producten en niet nieuwe titels.

[ Voor 47% gewijzigd door RobIII op 22-02-2008 17:50 ]

[Gerwin]

RobIII schreef op vrijdag 22 februari 2008 @ 17:46:
[...]

...en daarna ben ik je kwijt hoor
Is dat een onderbouwing voor je 'meerdere titels'?

Heeft een product 1 titel? Of meer?

Heet een product (ID = 1719):
• 1719: "Bavaria pilsener bier"

of

• 1719: "Bavaria pilsener bier"
én
• 1719: "Dommelsch pilsener bier"
én ...

Doorgaans heeft een product maar 1 titel hoor; alleen in uitzonderlijke gevallen en zelfs dan zou ik een alias veld toevoegen en dus niet een compleet nieuwe tabel introduceren.

Zoals ik probeerde aan te geven in mijn reply is het inderdaad zo dat Producten/Videos meerdere Titels (Descriptions, Text, Image, Genre, Type) hebben. Deze worden toegevoegd/verwijderd op basis van ProductID/VIdeoID en van LocationID, GenreID, TypeID, ImageID van ProductID/VideoID.

[Confusion]

Om curry684 te herhalen: wat is je business case?

Los daarvan: als je bijvoorbeeld wilt dat locatie A bij product 1 het plaatje foo met beschrijving bar kan tonen, terwijl locatie B bij product 1 plaatje flurp met beschrijving hopseflops moet kunnen tonen, terwijl locatie C bij product 1 plaatje flurp met beschrijvingen foo en hopselops moet kunnen tonen, dan heb je nog steeds niet dit hopeloos ingewikkelde, overgenormaliseerde datamodel nodig.

[Webgnome]

Gerwin schreef op vrijdag 22 februari 2008 @ 17:52:
[...]

Zoals ik probeerde aan te geven in mijn reply is het inderdaad zo dat Producten/Videos meerdere Titels (Descriptions, Text, Image, Genre, Type) hebben. Deze worden toegevoegd/verwijderd op basis van ProductID/VIdeoID en van LocationID, GenreID, TypeID, ImageID van ProductID/VideoID.

Call me stupid maar dan zijn het toch geen titels meer maar gewoon properties van een product ? Zoals confusion ook al aangeeft. Het is toch volstrekt onzinnig om voor elke mogelijke propertie die er zou kunnen komen op een bepaald product een apparte tabel te verzinnen met daarbij de nodige koppeltabellen omdat je er vanuit zou kunnen gaan dat unieke properties gedeelt kunnen worden met andere entiteiten in je systeem (en dus niet meer uniek zijn).

[ Voor 25% gewijzigd door Webgnome op 22-02-2008 19:01 ]

[HendrikN]

Ik mis overigens nog steeds een echt/genormaliseerd ERD diagram. Wat ik tot nu toe zie zijn paint-creaties.

[ Voor 7% gewijzigd door HendrikN op 22-02-2008 19:15 ]

[dB90]

Echt het spijt me, maar dit is echt belachelijk Waarom?!!? (wilde hier een heleboel waarom-vragen neerzetten, maar het is korter om alleen 'waarom' te vragen... )

Zoals meerdere mensen je al meerder malen hebben aangeraden...

• Schrijf eerst uit, in normale taal, wat je wilt bereiken..(zonder gelijk in relaties en queries te gaan denken)
• Schrijf op welke gegevens je moet/wil opslaan in je database
• Maak dan een ERD met de relaties (Ondertussen een tutorial normaliseren erbij)
• Zet je database op
• Nu pas in queries denken en kijk of je alles eruit kan halen wat je wil
• Zorg er tussentijds voor dat je niet verdrinkt in je eigen "logica" want daardoor loopt het telkens fout

Een andere tip: Koop gewoon een goed boek en doe het stap voor stap, begin klein

Maar please stop met deze onzin, het is bij voorbaat al kansloos om hiermee door te blijven modderen

[Gerwin]

Confusion schreef op vrijdag 22 februari 2008 @ 18:29:
Om curry684 te herhalen: wat is je business case?

Los daarvan: als je bijvoorbeeld wilt dat locatie A bij product 1 het plaatje foo met beschrijving bar kan tonen, terwijl locatie B bij product 1 plaatje flurp met beschrijving hopseflops moet kunnen tonen, terwijl locatie C bij product 1 plaatje flurp met beschrijvingen foo en hopselops moet kunnen tonen, dan heb je nog steeds niet dit hopeloos ingewikkelde, overgenormaliseerde datamodel nodig.

De business case is een makkelijke manier te zoeken voor Producten en Videoś waaraan in beginsel een Location, Genre, Type, Image, Title, Description, Text te koppelen is.

Vervolgens heeft de Location, Genre, Type, Image die gekoppeld zijn een 'overkoepelende' extra Image, Title, Description en Text.

Dit met als reden dat op deze manier alles makkelijker te onderhouden is, als je eenmalig zegt dat Location 1 een Image 1 (en de Title, Description, Text die daarbij hoort ook worden gekoppeld), ben je ineens klaar voor alle producten die ooit worden toegevoegd (of verwijderd) worden aan die Location 1.

Webgnome schreef op vrijdag 22 februari 2008 @ 18:59:
[...]


Call me stupid maar dan zijn het toch geen titels meer maar gewoon properties van een product ? Zoals confusion ook al aangeeft. Het is toch volstrekt onzinnig om voor elke mogelijke propertie die er zou kunnen komen op een bepaald product een apparte tabel te verzinnen met daarbij de nodige koppeltabellen omdat je er vanuit zou kunnen gaan dat unieke properties gedeelt kunnen worden met andere entiteiten in je systeem (en dus niet meer uniek zijn).

De Titels in het huidige schema zijn 'properties' van Product / Video. Echter omdat een Product / Video meerdere Titels kan bevatten (ProductTitel, ProductlocationTitel, ProductimageTitel, ProductgenreTitel, ProducttypeTitel & VideoTitel, VideolocationTitel, VideoimageTitel, VideogenreTitel) heb ik deze als 'koppeltabel' opgenomen in Product2Titel en Video2Titel.

Van het idee om voor alle nieuw 'properties' een extra tabel met koppeltabel te maken ben ik op dit moment niet verder aan het onderzoeken. Ik heb hierom een groot aantal tabellen laten vallen en wil dit middels PHP query's kunnen realiseren. Echter zoals ik aangeef zie ik hierin op dit moment ook nog geen licht in de duisternis schijnen.

HendrikN schreef op vrijdag 22 februari 2008 @ 19:12:
Ik mis overigens nog steeds een echt/genormaliseerd ERD diagram. Wat ik tot nu toe zie zijn paint-creaties.

Arrg, ik dacht toch mijn best gedaan te hebben met een ERD programma om zo'n diagram te maken in onderstaande afbeelding, dit maakt toch duidelijk waar de relaties, 1-op-meer relelaties zitten en wat de index ID's zijn?

dB90 schreef op vrijdag 22 februari 2008 @ 19:19:
Echt het spijt me, maar dit is echt belachelijk Waarom?!!? (wilde hier een heleboel waarom-vragen neerzetten, maar het is korter om alleen 'waarom' te vragen... )

Zoals meerdere mensen je al meerder malen hebben aangeraden...

• Schrijf eerst uit, in normale taal, wat je wilt bereiken..(zonder gelijk in relaties en queries te gaan denken)
• Schrijf op welke gegevens je moet/wil opslaan in je database
• Maak dan een ERD met de relaties (Ondertussen een tutorial normaliseren erbij)
• Zet je database op
• Nu pas in queries denken en kijk of je alles eruit kan halen wat je wil
• Zorg er tussentijds voor dat je niet verdrinkt in je eigen "logica" want daardoor loopt het telkens fout

Een andere tip: Koop gewoon een goed boek en doe het stap voor stap, begin klein

Maar please stop met deze onzin, het is bij voorbaat al kansloos om hiermee door te blijven modderen

Laten we zeggen dat ik alleen een Product tabel heb met alle data erin, Location, Genre, Type etc. als velden in die tabel. Nu wil ik voor Alle producten op een Locatie een Titel toevoegen, maar ik wil ook dat die Titel voor de producten op toekomstige producten op die locatie wordt toegevoegd. Daarbij wil ik ook de mogelijkheid hebben om de Titel van alle producten op een Locatie te verwijderen, met dat ik gedachte dat de Titels van de producten zelf onaangetast moeten blijven.

[Confusion]

Gerwin schreef op vrijdag 22 februari 2008 @ 20:57:
De business case is een makkelijke manier te zoeken voor Producten en Video's [..]

Kan een video bij een product horen, terwijl de video bij een andere locatie dan het product hoort?

Verder is dit model best aardig, maar hier horen dan ook zeker geen absurde queries bij.

Vervolgens heeft de Location, Genre, Type, Image die gekoppeld zijn een 'overkoepelende' extra Image, Title, Description en Text.

Ik heb geen flauw idee wat hier staat.

Dit met als reden dat op deze manier alles makkelijker te onderhouden is, als je eenmalig zegt dat Location 1 een Image 1 (en de Title, Description, Text die daarbij hoort ook worden gekoppeld), ben je ineens klaar voor alle producten die ooit worden toegevoegd (of verwijderd) worden aan die Location 1.

Een image van een location heeft niets te maken met de producten van die location. Het is nooit nodig een directe koppeling te leggen tussen een product en een image van een location waar dat product toevallig verkrijgbaar is. Als je dat ook niet bedoeld, dan begrijp ik de toegevoegde waarde van die zin niet

[Gerwin]

Laat ik het heel simpel beginnen op te bouwen dan, maak naar eigen dunken een ERD-diagram.

[list=1]
• er bestaan 10 producten
• vervolgens krijgen alle producten location 1 en 2 toegekend
• product 1 krijgt titel 1
• alle producten die location 1 hebben krijgen titel 1
• alle producten die location 1 hebben wordt titel 1 verwijderd

In al mijn gevallen verwijder ik met de laatste opdracht alle titels van de producten, en dus ook de titel opgegeven is in regel 3. Dit is één van de redenen om zoveel tabellen te gebruiken, en op de manier met 'minder tabellen' in plaats van 'meer' zie ik hier geen oplossing voor. Wie wel?

Als deze case opgelost ik zal ik de volgende posten betreffende titels via andere eigenschap dan productid.

[ Voor 22% gewijzigd door Gerwin op 22-02-2008 21:38 ]

[Verwijderd]

Gerwin schreef op vrijdag 22 februari 2008 @ 20:57:
Dit met als reden dat op deze manier alles makkelijker te onderhouden is, als je eenmalig zegt dat Location 1 een Image 1 (en de Title, Description, Text die daarbij hoort ook worden gekoppeld), ben je ineens klaar voor alle producten die ooit worden toegevoegd (of verwijderd) worden aan die Location 1.

Dus stel je hebt een product 'A' en die heeft natuurlijk een ID (zeg '1') in de tabel Producten.
(ik neem even aan dat het product bestaat, want anders wordt een plaatje verzinnen wel erg moeilijk ).
Dan wil jij dus voor alle locaties apart dat plaatje al toevoegen (zeg dat ik voor een multi-national werk met ruim 1.000 winkels) omdat misschien dat product daar komt te liggen. En dat nog onder de noemer van 'makkelijker te onderhouden'
Dan is het toch veel logischer om 1 keer dat plaatje onder de product te hangen. Ik kan nog eventueel met je meegaan door er een taal-code bij het plaatje te zetten.

[Gerwin]

Verwijderd schreef op vrijdag 22 februari 2008 @ 21:39:
[...]

Dus stel je hebt een product 'A' en die heeft natuurlijk een ID (zeg '1') in de tabel Producten.
(ik neem even aan dat het product bestaat, want anders wordt een plaatje verzinnen wel erg moeilijk ).
Dan wil jij dus voor alle locaties apart dat plaatje al toevoegen (zeg dat ik voor een multi-national werk met ruim 1.000 winkels) omdat misschien dat product daar komt te liggen. En dat nog onder de noemer van 'makkelijker te onderhouden'
Dan is het toch veel logischer om 1 keer dat plaatje onder de product te hangen. Ik kan nog eventueel met je meegaan door er een taal-code bij het plaatje te zetten.

Zonder te diep van wal te gaan en weer een topic te staten over hoe wn waarom en wat voor kleuren er in het diagram gebruikt worden klopt het wat je zegt.

In dit geval (is maar een onderdeel ervan want dit komt meerdere malen en met kleine verschillen voor).

[list=1]
• er bestaan 10 producten (A, B, C....)
• vervolgens krijgen alle producten location A en B toegekend
• product A krijgt Image A
• alle producten die location A hebben krijgen Image A
• alle producten die location A hebben wordt wordt Image A verwijderd


In de laatste regel worden alle images A van producten verwijderd op location A, maar ook de image op regel 3. Dat is niet de bedoeling...

[Verwijderd]

Kap even met het "Producten hebben een Locatie" gedoe. Wat is nou exact je business case? Wat moet je systeem gaan doen? Wat moet je verkopen, verhuren, bijhouden of wat dan ook? Wie moet het bijhouden? Welke bijzondere situaties zul je in de praktijk tegenkomen?

Laat dat hele ERD even lekker weg, want daar ga je pas aan beginnen als je alles in gewone mensen taal hebt beschreven. Uit die beschrijving ga je namelijk pas de entiteiten en relaties afleiden. Maar éérst dus in gewone taal.

[Gerwin]

Verwijderd schreef op vrijdag 22 februari 2008 @ 22:10:
Kap even met het "Producten hebben een Locatie" gedoe. Wat is nou exact je business case? Wat moet je systeem gaan doen? Wat moet je verkopen, verhuren, bijhouden of wat dan ook? Wie moet het bijhouden? Welke bijzondere situaties zul je in de praktijk tegenkomen?

Laat dat hele ERD even lekker weg, want daar ga je pas aan beginnen als je alles in gewone mensen taal hebt beschreven. Uit die beschrijving ga je namelijk pas de entiteiten en relaties afleiden. Maar éérst dus in gewone taal.

Ik wil op een website een lijst kunnen tonen waarin de volgende twee soorten output gebruikt wordt, één gebaseerd op de waarde van Producten de ander op Video. De velden zijn:

voor product
Company, Location, Product, Type, Image, Genre, Title, Description, Text
voor video
Company, Location, VIdeo, Image, Genre, Title, Description, Text

De lijst kan verkleind worden door alleen de Product en Image te tonen, of elke andere combinatie uit één van de twee rijen. Daarnaast kan de lijst vernauwd worden door te zeggen enkel een selectie te tonen, bijvoorbeeld alleen Type A of Location B.

Dan kom ik weer terug over hoe de zaken aan elkaar gekoppeld zijn zoals aangegeven in onderstaand schema. De rode lijnen geven aan waar een één-op-meer relatie tussen bestaat.



Hierbij moet vermeld worden dat softwarematig de volgende moet gerealiseerd worden:

• voeg Company toe
• voeg Location toe
• voeg Genre toe
• voeg Image toe
• voeg Type toe
• voeg Product toe
• waar Product bevat voeg Title toe
• waar Product bevat voeg Description toe
• waar Product bevat voeg Text toe
• waar Product bevat voeg Image toe
• waar Product bevat voeg Type toe
• waar Product een Location bevat voeg daarop een Title toe
• waar Product een Location bevat voeg daarop een Description toe
• waar Product een Location bevat voeg daarop een Text toe
• waar Product een Location bevat voeg daarop een Image toe
• waar Product een Genre bevat voeg daarop een Title toe
• waar Product een Genre bevat voeg daarop een Description toe
• waar Product een Genre bevat voeg daarop een Text toe
• waar Product een Genre bevat voeg daarop een Image toe
• waar Product een Image bevat voeg daarop een Title toe
• waar Product een Image bevat voeg daarop een Description toe
• waar Product een Image bevat voeg daarop een Text toe
• waar Product een Image bevat voeg daarop een Image toe
• waar Product een Type bevat voeg daarop een Title toe
• waar Product een Type bevat voeg daarop een Description toe
• waar Product een Type bevat voeg daarop een Text toe
• waar Product een Type bevat voeg daarop een Image toe
• voeg Video toe
• waar Video bevat voeg Title toe
• waar Video bevat voeg Description toe
• waar Video bevat voeg Text toe
• waar Video bevat voeg Image toe
• waar Video een Location bevat voeg daarop een Title toe
• waar Video een Location bevat voeg daarop een Description toe
• waar Video een Location bevat voeg daarop een Text toe
• waar Video een Location bevat voeg daarop een Image toe
• waar Video een Genre bevat voeg daarop een Title toe
• waar Video een Genre bevat voeg daarop een Description toe
• waar Video een Genre bevat voeg daarop een Text toe
• waar Video een Genre bevat voeg daarop een Image toe
• waar Video een Image bevat voeg daarop een Title toe
• waar Video een Image bevat voeg daarop een Description toe
• waar Video een Image bevat voeg daarop een Text toe
• waar Video een Image bevat voeg daarop een Image toe


bovenstaande moet ook weer kunnen worden verwijderd
En mijn volgende probleem met deze structuur waarin - op aanraden - minder tabellen bestaan.

Gerwin schreef op vrijdag 22 februari 2008 @ 21:36:
Laat ik het heel simpel beginnen op te bouwen dan, maak naar eigen dunken een ERD-diagram.

[list=1]
• er bestaan 10 producten
• vervolgens krijgen alle producten location 1 en 2 toegekend
• product 1 krijgt titel 1
• alle producten die location 1 hebben krijgen titel 1
• alle producten die location 1 hebben wordt titel 1 verwijderd

In al mijn gevallen verwijder ik met de laatste opdracht alle titels van de producten, en dus ook de titel opgegeven is in regel 3. Dit is één van de redenen om zoveel tabellen te gebruiken, en op de manier met 'minder tabellen' in plaats van 'meer' zie ik hier geen oplossing voor. Wie wel?

Als deze case opgelost ik zal ik de volgende posten betreffende titels via andere eigenschap dan productid.

[ Voor 34% gewijzigd door Gerwin op 22-02-2008 22:49 ]

[dB90]

Gerwin schreef op vrijdag 22 februari 2008 @ 22:33:
[...]

Ik wil op een website een lijst kunnen tonen [knip] met video's

[...]

Begin gewoon bij het begin. Je blijft maar verzanden in dingen als:

soorten output[...]de velden zijn[...]de relaties blaat

Wat ik al helemáál niet begrijp zijn zinnen als:

vervolgens krijgen alle producten location 1 en 2 toegekend

en

alle producten die location 1 hebben krijgen titel 1

Zo ingewikkeld kan het toch niet zijn om een (relationele) database op te zetten voor video's? Er zijn honderden duizenden bedrijven die een productendatabase hebben en uitgerekend jij hebt daar honderdduizend tabellen voor nodig en een query van 70 regels... Ga je dan op geen enkel moment aan je aanpak twijfelen? Of nadat een boel mensen je (vrij duidelijke) hints geven, dat je even rustig aan opnieuw de case moet bekijken?

Nofi maar je komt hier op dit forum hulp vragen voor een probleem, omdat je denk ik het idee hebt dat hier mensen rondhangen die er redelijk wat vanaf weten? Als je antwoord hierop ja is, neem dan het advies van die mensen aan, dat er iets niet klopt aan je aanpak, je logica en je model.

[Webgnome]

Gerwin schreef op vrijdag 22 februari 2008 @ 22:33:
[...]afbeelding]
Hierbij moet vermeld worden dat softwarematig de volgende moet gerealiseerd worden:

• voeg Company toe
• voeg Location toe
• voeg Genre toe
• voeg Image toe
• voeg Type toe
• voeg Product toe
• waar Product bevat voeg Title toe
• waar Product bevat voeg Description toe
• waar Product bevat voeg Text toe
• waar Product bevat voeg Image toe
• waar Product bevat voeg Type toe
• waar Product een Location bevat voeg daarop een Title toe
• waar Product een Location bevat voeg daarop een Description toe
• waar Product een Location bevat voeg daarop een Text toe
• waar Product een Location bevat voeg daarop een Image toe
• waar Product een Genre bevat voeg daarop een Title toe
• waar Product een Genre bevat voeg daarop een Description toe
• waar Product een Genre bevat voeg daarop een Text toe
• waar Product een Genre bevat voeg daarop een Image toe
• waar Product een Image bevat voeg daarop een Title toe
• waar Product een Image bevat voeg daarop een Description toe
• waar Product een Image bevat voeg daarop een Text toe
• waar Product een Image bevat voeg daarop een Image toe
• waar Product een Type bevat voeg daarop een Title toe
• waar Product een Type bevat voeg daarop een Description toe
• waar Product een Type bevat voeg daarop een Text toe
• waar Product een Type bevat voeg daarop een Image toe
• voeg Video toe
• waar Video bevat voeg Title toe
• waar Video bevat voeg Description toe
• waar Video bevat voeg Text toe
• waar Video bevat voeg Image toe
• waar Video een Location bevat voeg daarop een Title toe
• waar Video een Location bevat voeg daarop een Description toe
• waar Video een Location bevat voeg daarop een Text toe
• waar Video een Location bevat voeg daarop een Image toe
• waar Video een Genre bevat voeg daarop een Title toe
• waar Video een Genre bevat voeg daarop een Description toe
• waar Video een Genre bevat voeg daarop een Text toe
• waar Video een Genre bevat voeg daarop een Image toe
• waar Video een Image bevat voeg daarop een Title toe
• waar Video een Image bevat voeg daarop een Description toe
• waar Video een Image bevat voeg daarop een Text toe
• waar Video een Image bevat voeg daarop een Image toe


bovenstaande moet ook weer kunnen worden verwijderd
En mijn volgende probleem met deze structuur waarin - op aanraden - minder tabellen bestaan.


[...]

Mag ik weten waarom elke entiteit in je db (product, video, genre, image, etc) een text, image title EN description heeft? Neem nu genre's. Even er vanuit gaande dat een product meerdere genre's kan hebben. Dan volstaat toch een tabel genre's met daarin een ID + genrenaam ( aangezien een omschrijving niet echt nodig is.. Is dat wel dan zou ik het genre hernoemen..)en een tabel genre2product met daarin de pk's en fk's van genre / producten die bij elkaar horen. simpele join erop .. en klaar is gerwin.

Ik vraag me , zoals ik al heb laten weten, daadwerkelijk af waarom er bij elke entiteit een text en een image etc MOET staan. Is even kijken:

• voeg Company toe
• voeg Location toe
• voeg Genre toe
• voeg Image toe
• voeg Type toe
• voeg Product toe
• waar Product bevat voeg Title toe
• waar Product bevat voeg Description toe
• waar Product bevat voeg Text toe
• waar Product bevat voeg Image toe
• waar Product bevat voeg Type toe
• waar Product een Location bevat voeg daarop een Title toe
• waar Product een Location bevat voeg daarop een Description toe
• waar Product een Location bevat voeg daarop een Text toe
• waar Product een Location bevat voeg daarop een Image toe
  • waar Product een Genre bevat voeg daarop een Title toe
  • waar Product een Genre bevat voeg daarop een Description toe
  • waar Product een Genre bevat voeg daarop een Text toe
  • waar Product een Genre bevat voeg daarop een Image toe
  • waar Product een Image bevat voeg daarop een Title toe
  • waar Product een Image bevat voeg daarop een Description toe
  • waar Product een Image bevat voeg daarop een Text toe
  • waar Product een Image bevat voeg daarop een Image toe
  • waar Product een Type bevat voeg daarop een Title toe
  • waar Product een Type bevat voeg daarop een Description toe
  • waar Product een Type bevat voeg daarop een Text toe
  • waar Product een Type bevat voeg daarop een Image toe
• voeg Video toe
• waar Video bevat voeg Title toe
• waar Video bevat voeg Description toe
• waar Video bevat voeg Text toe
• waar Video bevat voeg Image toe
• waar Video een Location bevat voeg daarop een Title toe
• waar Video een Location bevat voeg daarop een Description toe
• waar Video een Location bevat voeg daarop een Text toe
• waar Video een Location bevat voeg daarop een Image toe
  • waar Video een Genre bevat voeg daarop een Title toe
  • waar Video een Genre bevat voeg daarop een Description toe
  • waar Video een Genre bevat voeg daarop een Text toe
  • waar Video een Genre bevat voeg daarop een Image toe
  • waar Video een Image bevat voeg daarop een Title toe
  • waar Video een Image bevat voeg daarop een Description toe
  • waar Video een Image bevat voeg daarop een Text toe
  • waar Video een Image bevat voeg daarop een Image toe

Waarom bestaan de vet gedrukte cases? Het is toch volkomen onzinnig om per verandering die een product/video doormaakt ook de description aan te gaan lopen passen? Nogmaals dit kan veel makkelijker met product, video, genre, image en location als maintabellen met daarbij de nodige koppeltabellen om ze aan elkaar te hangen, waar nodig.

Zoals ook al vaker is aangegeven.. WAAROM deze ontzettend onnodig ingewikkelde opzet?

[Verwijderd]

Gerwin schreef op vrijdag 22 februari 2008 @ 22:33:
• waar Product bevat voeg Image toe
• waar Product een Location bevat voeg daarop een Image toe

Nu kom ik zelf uit de detailhandel, dus misschien dat ik het daarom niet begrijp.
In "mijn wereld" is de tweede case erg raar.

Stel, ik ga pennen verkopen (je product).
Ik heb hier voor me op me bureau een blauwe Bic-pen liggen, als voorbeeld.
Dus in me product-tabel voeg ik toe: ID=1000, Name=Bic-pen, kleur Blauw.
Ik voeg ook nog even een plaatje toe:

Dat was je eerste case.

Stel ik heb 3 winkels (je locations).
Dus in me locations-tabel voeg ik toe: ID=1, Name=Amsterdam; ID=2, Name=Rotterdam; ID=3, Name=Utrecht.

Nu ga ik die Bic-pen verkopen in al me winkels.
Dus ik leg de koppeling tussen me producten en locations (aangenomen Aantal=1): LocationID=1, ProductID=1000; LocationID=2, ProductID=1000; LocationID=3, ProductID=1000;

In de praktijk rij ik rond in me auto en leg ook die Bic-pen in de verschillende winkels.

Nu het vreemde. Waarom moet het plaatje dan veranderen op het moment dat het in de winkel ligt, en nog een ander plaatje per winkel!?
Op het moment dat ik die pen in de winkel leg, lijkt ie dan niet meer eens op???:


Misschien kan dat bij jouw producten hoor, maar met "mijn Bic-pennen" is dat onmogelijk...

[ Voor 3% gewijzigd door Verwijderd op 23-02-2008 09:14 ]

[Verwijderd]

Gerwin schreef op vrijdag 22 februari 2008 @ 22:33:

Ik wil op een website een lijst kunnen tonen waarin de volgende twee soorten output gebruikt wordt, één gebaseerd op de waarde van Producten de ander op Video. De velden zijn:

voor product
Company, Location, Product, Type, Image, Genre, Title, Description, Text
voor video
Company, Location, VIdeo, Image, Genre, Title, Description, Text

Blablablablablabla

Is het nou echt zo moeilijk om die technische onzin achterwege te laten en in gewoon Nederlands te beschrijven waarvoor het hele systeem bedoeld is? Weet je wat een business case is? Ken je het verschil tussen een business case en een functioneel ontwerp? Waarom denk je dat jij die stappen kunt overslaan? Heb je dan zoveel ervaring? Probeer het nou niet op jouw manier te doen, want het is duidelijk dat dat niet werkt en dat heb je zelf ook wel in de gaten als je hier een topic opent. Dit is helemaal geen MySQL probleem, dit is een fundamenteel denkprobleem. Ik wil geen ERD's zien, maar gewoon een beschrijving van het bedrijf of het idee waarvoor het bedoeld is? Wat doen ze? Wat is belangrijk?

Je begint in je 2e zin met "Mijn voornemen is om een mysql systeem te ontwikkelen ...", maar daaruit blijkt gewoon dat je geen flauw idee hebt van wat je nou precies wilt doen. Je weet simpelweg je probleem niet te beschrijven. Werk daaraan.

[ Voor 3% gewijzigd door Verwijderd op 23-02-2008 10:49 ]

[whoami]

Al heb je duizend jaar ervaring, dan nog kan je gewoon een functioneel ontwerp niet overslaan.

Verder zie ik niet zo veel heil meer in dit topic. De topicstarter blijft gewoon vasthouden aan z'n koppigheid, en wil blijkbaar niet geholpen worden.

[Creepy]

[quote]Gerwin schreef op vrijdag 22 februari 2008 @ 22:05:
[...]


Zonder te diep van wal te gaan en weer een topic te staten over hoe wn waarom en wat voor kleuren er in het diagram gebruikt worden klopt het wat je zegt.

In dit geval (is maar een onderdeel ervan want dit komt meerdere malen en met kleine verschillen voor).

• er bestaan 10 producten (A, B, C....)
• vervolgens krijgen alle producten location A en B toegekend
• product A krijgt Image A


Duidelijk..
[quote]
• alle producten die location A hebben krijgen Image A

Lost me there... als Location A een image heeft, waarom dan in hemelsnaam wil je dit dan toekennen aan je product?

[quote]
• alle producten die location A hebben wordt wordt Image A verwijderd

Again, lost me there..om dezelfde reden als hierboven..


Edit: aarrgh, anders zit dit topic al ff dicht

[ Voor 3% gewijzigd door Creepy op 23-02-2008 20:23 ]