[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.