[dAEk]

Man kan såklart planera för olika driftmiljöer om man vill men det brukar inte vara lönt eftersom man sällan flyttar projekt till en annan miljö än den man utvecklat för. Man måste dra gränsen nånstans och koda utifrån det som är känt.


Notera att jag inte försvarar eller på något sätt tycker att loopar eller rekursiva anrop som kopplar upp sig mot en databas är något som borde finnas i produktion. Ville bara få det sagt eftersom jag inser att det inte framgår. Connys kodexempel skulle jag alltså inte använda mig av, dock kan man göra samma sak direkt i databasen istället.

[Clarence]

Ursprungligen postat av dAEk

Man kan såklart planera för olika driftmiljöer om man vill men det brukar inte vara lönt eftersom man sällan flyttar projekt till en annan miljö än den man utvecklat för. Man måste dra gränsen nånstans och koda utifrån det som är känt.


Notera att jag inte försvarar eller på något sätt tycker att loopar eller rekursiva anrop som kopplar upp sig mot en databas är något som borde finnas i produktion. Ville bara få det sagt eftersom jag inser att det inte framgår. Connys kodexempel skulle jag alltså inte använda mig av, dock kan man göra samma sak direkt i databasen istället.

Annan driftmiljö är ett exempel, andra exempel är förändrad datamängd, förändrade datadjup, ökad trafik osv. Jag tycker inte att alla måste använda en nested set model de inte förstår. Men jag tycker att idiotiskt ineffektiv kod aldrig ska läggas i produktion om den inte är ett proof of concept/prototyp som är tänkt att skrivas om snarare än vidareutvecklas.

Att lägga hanteringen i databasen med en struktur såsom föreslagits i denna tråd är fullt acceptabelt - om databassystemet stödjer rekursiva frågor (som t ex MSSQL, Oracle och PostgreSQL gör, men inte MySQL). I MySQL blir det mest bara jobbigare och krångligare än att använda nested-set modellen - men det blir mer en smakfråga.

Att ha strukturen som i tråden och vid varje skrivoperation lägga in denormaliserade sökvägar i tabellen är också fullt acceptabelt.

[frecka]

Tog efter din kod, den va enkel att förstå

function writeParents($fid) {
$check_parent = mysql_query("SELECT parent FROM forums WHERE id = {$fid} && parent != 0");
if(mysql_num_rows($check_parent) == 0):
return false;
else:
$new_parent = mysql_result($check_parent, 0, "parent");
writeParents($new_parent);
echo " - <a class='orange' href='".ROOT."forum.php?id=".mysql_result($check_p arent, 0, "parent")."'>". mysql_result(mysql_query("SELECT name FROM forums WHERE id = '".mysql_result($check_parent, 0, "parent")."'"), 0, "name")."</a>";
endif;
}

[dAEk]

Kul att du löste ditt problem även om lösningen i sig i stort sett är den sämsta tänkbara varianten. Förstår att det blir som det blir när inte fler bidrar med konkreta kodexempel. Det är ju trots allt ett väldigt bra sätt att lära sig när man är nybörjare inom programmering.

[dAEk]

Ursprungligen postat av Clarence

Men jag tycker att idiotiskt ineffektiv kod aldrig ska läggas i produktion om den inte är ett proof of concept/prototyp som är tänkt att skrivas om snarare än vidareutvecklas.

Ja, känner man till att det är stor skillnad på lösning a jämfört b är det väl dumt att medvetet välja den sämre så länge som det inte påverkar kodkomplexiteten. Fattar inte riktigt vilken kod du syftar på eftersom du citerar mig utan att jag har lagt upp någon kod, men jag börjar ledsna på den här ändlösa diskussionen. Man gör det som man tycker är bra, gör kunden nöjd och får systemen att snurra stabilt under de förutsättningar man har.

Ursprungligen postat av Clarence

Att ha strukturen som i tråden och vid varje skrivoperation lägga in denormaliserade sökvägar i tabellen är också fullt acceptabelt.

Absolut. Det är en poäng som många nog glömmer bort emellanåt. Jag vet iaf att jag glömmer bort platta/förberedda tabeller titt som tätt och istället snöar in på att få systemen så "rena" som möjligt. Lyfter man blicken lite brukar det hjälpa. Detsamma kan man förresten säga ang. att optimera på förhand. Se bara vad som skrivs i var och varannan tråd.