[MySQL/PHP] Sorteren en foreign keys

[JayVee]

Hoi!

Ik heb het volgende probleem:
Bij het printen van een overzicht zorgen we er netjes voor dat alle 'foreign keys' vervangen worden. Dus: in plaats van de id (zoals het in de overzichts tabel A staat) printen we de bijbehorende naam (die natuurlijk in een aparte tabel B staat). Er wordt vaak naar meerdere B tabellen verwezen.

Als je nu gaat sorteren op een col waar een foreign key achter zit, wordt echter gesorteerd op de id en dus niet op naam (die staat ook in B, niet in A)!

Een mogelijke oplossing:
Bij het wijzigen (UPDATE, INSERT, DELETE) van zo een tabel B ervoor zorgen dat de ids op dezelfde volgorde als de 'namen' komen.
Aangezien echter gereferenced wordt kan dat niet door simpel de tabel (deze zijn gelukkig klein) uit te lezen en opnieuw erin te pompen. Maar het kan alsnog door eerst alle ids met auto_increment (of willekeurig groot getal) te verhogen en vervolgens alles naar alphabet gesorteerd weer te UPDATEN, id beginnend bij 1. [bErg[/b] hacky vind ik.

Het lastige is dat we nu gaan vertrouwen op een beetje rare code en de UPDATE CASCADE functionaliteit van de database. Het gaat hier om een bedrijfscritisch systeem. Er mag dus absoluut niets mis gaan!

Andere oplossing:
Resultset halen zonder order by en dan de arary in PHP gaan sorteren. Vervolgens paging (dus uitzoeken welke resultaten we willen hebben, bijv. 120-140) Probleem dan is dat de meeste van die A (overzichts) tabellen wel groot zijn... wordt dus langzaam.


Dit moet toch wel makkelijker kunnen? Op dit moment draaien we nog 4.0.22, maar de overstap naar 4.1 kan nu ook wel, mocht dat hiervoor nodig / handig zijn.

[ Voor 3% gewijzigd door JayVee op 18-01-2005 17:25 ]

[justmental]

In je select query kun je toch gewoon sorteren op de over de foreign key opgezochte naam?

code:

select tab1.blabla
, tab2.naam
from tabel1 tab1
, tabel2 tab2
where tab1.refid = tab2.id
order by tab2.naam

[ Voor 43% gewijzigd door justmental op 18-01-2005 17:25 ]

[JayVee]

Op dit moment gebruiken we (nog) geen subqueries of joins.
Jij dacht dus aan iets als: Ja dus...

Probleem is dat we het liefst SELECT * doen aangezien we 'niet weten" hoe veel en wat voor columns tabel a wel niet heeft. Ik ga even proberen.

[ Voor 70% gewijzigd door JayVee op 18-01-2005 17:31 ]

[djluc]

Zou je eens kunnen vertellen waarom je niet weet hoeveel kolommen daar in staan?

[justmental]

Aantal kolommen maakt ook niet uit:

code:

select tab1.*, tab2.naam
...

[JayVee]

Dit werkt inderdaad. Alleen wordt het nu nog lastiger om die queries te schrijven. Maar goed, daarvoor hoeven we een stuk minder PHP troep te schrijven.
Nu alleen nog een stukje code wat de juiste index verzind voor de result array:

code:

if ( deze_col == eentjemet_fk ) {
  gebruik dan niet result['deze_col']
  maar zoek uit welke het dan wel moet zijn
}

Ga ik mee aan de slag! Ik post hier wel als er nog problemen zijn. Zal wel tot vanavond duren!

// edit

djluc schreef op dinsdag 18 januari 2005 @ 17:33:
Zou je eens kunnen vertellen waarom je niet weet hoeveel kolommen daar in staan?

EN we weten niet hoe ze heten! Wil ik zeker even uitleggen!

offtopic:
Het gaat om een lab systeem waar gegevens opgeslagen worden. Elke productgroep kent een eigen analyseschema (pH, Viscositeit, Temperatuur, etc). Deze info staat in twee tabellen opgeslagen. In een van die twee staat ook de naam van de tabel waar de resultaten (in de vorm van: datum, user, product, waarde pH, waarde Viscositeit, etc) van analyses opgeslagen worden.
Anywho, natuurlijk weten we wel hoe veel cols zo een resultaten (die ik in TS overzicht heb genoemd) tabel heeft. Maar dat is dus niet triviaal en moet dus door paar regels script berekend worden.
Confused yet? We hebben namelijk ook nog een aparte tabel waarin staat welke cols in die overzichten foreign keys naar andere (en dus welke) tabellen zijn!

//edit2:
Ondertussen sta ik hier dus wel voor l*l als SQL n00b

[ Voor 59% gewijzigd door JayVee op 18-01-2005 17:55 ]