[mysql] normalisatie kwestie

[Verwijderd]

Ik ben bezig met de automatisering van een groot bedrijf. Dit bedrijf krijgt heel basic gezegd te maken met de volgende entities:

Er is opdracht (=tabel).
Deze opdracht wordt uitgevoerd met behulp van een tekening (=tabel).
Deze tekening bestaat uit (een x-aantal) onderdelen.

Wat wil het bedrijf?
Het bedrijf wil in één overzicht zien wat de status is van alle opdrachten.

Ik doe daarvoor het navolgende.
• Haal alle opdrachten op.
(gebruik een relatie met tekeningen om info over de tekeningen op te halen)
• Haal vervolgens pér opdracht/tekening alle onderdelen op.
Van alle onderdelen bekijk ik de statussen qua voorraad en geef vervolgens achter de opdracht weer of de onderdelen er zijn/ of niet.
Gemiddeld zijn er altijd 100 opdrachten in het overzicht te zien. De tekeningen die hier aan gerelateerd zijn hebben gemiddeld met 10 verschillende onderdelen een relatie.

Het probleem is dat dit alles ontzettend traag gaat. Ik denk dat de parsing time (ik heb dit niet daadwerkelijk ge-checked) rond de 3 of 4 seconden ligt. Het is in ieder geval té traag omdat er vaak mee gewerkt gaat worden.

Heeft iemand een idee c.q. tip om dit beter aan te pakken?
Ik kan de database structuur niet verder optimaliseren, ik heb geen mogelijkheid om de tabellen-structuur aan te passen. Wel de tabellen zelf eventueel.
Echter denk ik dat ik dat de structuur wel goed is qua entities.

Een klein overzichtje van de tabellen (afbeelding).

Ik heb ook al aangeboden met tab-bladen te werken (opdracht 1tm/10, 11t/m 20, etc.) maar dit is geen optie daar de klant alle opdracht in een keer wil zien.
Als er geen oplossing is dan zal ik moeten melden dat de klant moet leven met de vertraging die steeds optreed.

[ Voor 3% gewijzigd door Verwijderd op 12-10-2004 12:07 ]

[Cavorka]

Laat eens wat van de queries zien die je gebruikt, en waar liggen je indices op? EXPLAIN al gebruikt? Om hoveel rows gaat het ongeveer per tabel (hoeveel staan erin)?

3 a 4 seconden is echt megalang, ik zet mijn geld so far op missing indices aangezien ikzelf een soortgelijk probleem had een tijdje geleden.

[ Voor 79% gewijzigd door Cavorka op 12-10-2004 12:12 ]

[whoami]

Verwijderd schreef op 12 oktober 2004 @ 12:05:

Ik doe daarvoor het navolgende.
• Haal alle opdrachten op.
(gebruik een relatie met tekeningen om info over de tekeningen op te halen)
• Haal vervolgens pér opdracht/tekening alle onderdelen op.
Van alle onderdelen bekijk ik de statussen qua voorraad en geef vervolgens achter de opdracht weer of de onderdelen er zijn/ of niet.
Gemiddeld zijn er altijd 100 opdrachten in het overzicht te zien. De tekeningen die hier aan gerelateerd zijn hebben gemiddeld met 10 verschillende onderdelen een relatie.

Kan je dat niet in één query doen?
Je haalt bv eerst 100 records op, en dan ga je nog eens voor ieder record alle informatie gaan ophalen, dat zijn dus nog eens 100 queries.

[Verwijderd]

whoami schreef op 12 oktober 2004 @ 12:17:
[...]

Kan je dat niet in één query doen?
Je haalt bv eerst 100 records op, en dan ga je nog eens voor ieder record alle informatie gaan ophalen, dat zijn dus nog eens 100 queries.

Mee eens, maar het is een 3-level relatie. Opdrachten » Tekeningen » Onderdelen.
En eerlijk gezegd snap ik niet goed hoe ik dat in 1 query zou moeten doen.

Overigens, ik denk dat ik de oplossing al gevonden heb, ik heb namelijk de indexes verkeerd geplaatst denk ik. Ben er nu mee aan 't puzzelen..

[Cavorka]

Verwijderd schreef op 12 oktober 2004 @ 12:27:
[...]
Mee eens, maar het is een 3-level relatie. Opdrachten » Tekeningen » Onderdelen.
En eerlijk gezegd snap ik niet goed hoe ik dat in 1 query zou moeten doen.

Met Joins.

[Reinier]

Verwijderd schreef op 12 oktober 2004 @ 12:27:
[...]
Overigens, ik denk dat ik de oplossing al gevonden heb, ik heb namelijk de indexes verkeerd geplaatst denk ik. Ben er nu mee aan 't puzzelen..

Nee, Cavorka had de oplossing gevonden

Traagheid duidt heel vaak op verkeerde indices.

[Verwijderd]

Ik heb de indices even aangemaakt, ik heb alleen het idee dat het geen effect heeft.
De parsing tijden worden er niet beter van.

Komt dit omdat ik pas achteraf de indices heb gemaakt met queries als deze:

code:

CREATE INDEX index_naam
ON
tabelnaam(tabel_column)

Ik heb steeds de tabel_column als primary key.

?

[ Voor 9% gewijzigd door Verwijderd op 12-10-2004 14:13 ]

[Creepy]

Je moet de indexn leggen op de velden die je in de where gebruikt.

Klopt het dat als je nu alles op de prim. key hebt gedaan dat je dan een index hebt op de tabel opdrachten op de velden opr_id EN tek_id (dus 1 index op 2 velden)?

[drm]

Zet indices zowel op de velden die je in WHERE clauses, als velden die je in ON clauses gebruikt. En lees het stukje in de P&W FAQ over JOINS even door (onder SQL)

[Verwijderd]

In navolging van mijn eerdere topic het navolgende.

Ik moet een 100-tal subprojecten ophalen uit de database. Zoals je kunt zien hebben deze subprojecten een relatie met een tekening. De tekening bevat een veld met ID's van onderdelen (onderdelen uit het onderdelen-archief om precies te zijn). Let op: ik ben mij ontzettend bewust van de foute manier van werken hier, echter ben ik niet in staat (opdrachtgever..) om dit te wijzigen!

Wat ik wil vragen, hoe kan ik het snelst en makkelijkst alle subprojecten + hun onderdelen ophalen? Ik doe dit nu met meerdere queries, namelijk 1 om alle subprojecten + hun tekeningen op te halen en vervolgens 1 om alle archief onderdelen + data uit de originele onderdelen tabel te halen.
Als je dus 100 subprojecten ophaalt, dan heeft dit als gevolg dat er 101 queries uitgevoerd worden. Ietwat veel dus. En erg traag, wat dus ook het probleem is.

Heeft iemand een tip voor me? Is dit gewoon een slechte basis (ik ben van mening dat dat inderdaad zo is, maar het is niet anders- alsdus den klant) en kan ik hier weinig mee? Of is er wellicht een work-around (wellicht met 1 query)?

[vinnux]

Ja dit is een slechte basis.
De oplossing zou het maken van een tabel tussen "tekeningen" en "onderdelen_archief" zijn.
De naam "tekening_onderdeel" zou van toepassing zijn met de volgende velden:
- tek_id -> FK tekeningen.tek_id
- achief_id -> FK onderdelen_archief.archief_id

En meervouden in tabellen is ook foei, maar dat wist je vast wel.
En zie ik daar nu vette redundantie?

Binnen alle redelijkheid is dit niet te doen in één query, dit vanwege het veld "onderdelen" waarin meerdere waardes zitten.

Echter het kan wel maar de complexiteit neem toe met het aantal onderdelen in het veld "onderdelen"

[ Voor 54% gewijzigd door vinnux op 15-10-2004 17:16 ]

[rb338]

Kan je niet beter een tabel met 'onderdelen in tekening' maken?
Nu heb je een m:n relatie, wat niet mag.
Als je er dus een tabel tussen zet heb je 2 1:n relaties, wat ok is

edit: mja, da's dus wat vgouw zei

[ Voor 14% gewijzigd door rb338 op 15-10-2004 17:32 ]

[CH4OS]

Misschien een domme vraag, maar waarom post je die vraag niet gewoon in [rml][ mysql] normalisatie kwestie[/rml]? Topic is pas 3 dagen oud, dus een nieuw topic is overbodig lijkt mij...

[Soultaker]

Verwijderd schreef op 15 oktober 2004 @ 17:00:
Wat ik wil vragen, hoe kan ik het snelst en makkelijkst alle subprojecten + hun onderdelen ophalen? Ik doe dit nu met meerdere queries, namelijk 1 om alle subprojecten + hun tekeningen op te halen en vervolgens 1 om alle archief onderdelen + data uit de originele onderdelen tabel te halen.

Als je dus 100 subprojecten ophaalt, dan heeft dit als gevolg dat er 101 queries uitgevoerd worden. Ietwat veel dus. En erg traag, wat dus ook het probleem is.

Hmz, dit is toch wel te doen met 1 query? Het is een beetje ingewikkeld, maar het werkt wel, en met wat geschikte indices ook wel efficient, denk ik:

SQL:

SELECT
  *
FROM
  subproject, tekeningen, onderdelen_archief, onderdelen
WHERE
  subproject.tek_id = tekeningen.tek_id AND
  onderdelen_archief.archief_id = tekeningen.tek_id AND
  onderdelen.ond_id = onderdelen_archief.origineel_id

Ik negeer hierbij de "onderdelen" kolom in de tabel "onderdelen_archief"; uit je schema blijkt helemaal niet dat die ergens voor nodig is. Zo'n samengesteld veld is sowieso vragen om problemen. Als je onderdelen aan een archief wil koppelen kun je beter vanuit een onderdeel verwijzen naar een archief, desnoods met een extra veld om ordening aan te geven. Voor echte M:N-relaties zijn koppeltabellen een geschikte keuze; dat is dus een tabel met twee kolommen, waarvan de ene aan het archief refereert en het andere aan het onderdeel.

[Verwijderd]

GJ-tje schreef op 15 oktober 2004 @ 17:50:
Misschien een domme vraag, maar waarom post je die vraag niet gewoon in [rml][ mysql] normalisatie kwestie[/rml]? Topic is pas 3 dagen oud, dus een nieuw topic is overbodig lijkt mij...

offtopic:
Ik zeg; GJ-tje for moderator! Alhoewel, moderators stellen geen domme vragen natuurlijk.

Modbreak:

En ik als moderator zeg: daar zijn TR's voor om dat te gaan melden. Het is niet de bedoeling om met de botte bijl zelf te gaan hakken.
En de vraag is best legitiem; in hoeverre is dit een ander probleem c.q. vergelijkbaar met het eerdere probleem.

[ Voor 25% gewijzigd door gorgi_19 op 15-10-2004 23:40 ]

[Verwijderd]

Verwijderd schreef op 15 oktober 2004 @ 21:54:
[...]

offtopic:
Ik zeg; GJ-tje for moderator! Alhoewel, moderators stellen geen domme vragen natuurlijk.

Mag ik vragen waar deze reactie op slaat? No offence verder hoor , maar hij heeft gelijk. Verder is er aan de post van vgouw niet veel toe te voegen

[.oisyn]

Gemerged met je vorige topic, GJ-tje heeft gewoon gelijk