Citat:
Ursprungligen postat av danjel
Det funkar väl rent praktiskt i de flesta fall men känns fel vad gäller objekt/system design.
En grej är att man vill att klassen ska mappa exakt mot tabellen men om man lägger till egenskaper i klassen som inte finns i tabellen så bryter man den principen.
|
Ja, jag håller med. Det är ju bättre att bryta upp det och separera entiteterna. Men är det det du vill göra förstår jag inte varför du undviker en ORM. Det är ju det en ORM gör - mappa entiteter mot en datastruktur - men om du vill uppfinna hjulet på nytt så...
Citat:
Ursprungligen postat av danjel
Jag funderar nu istället på att börja köra utan joins så mycket det går och köra lazy loading för att ladda relaterade objekt,dvs mer likt ett ORM.
Vad tror ni om prestanda/skalbarhet vad gäller ett (nästan) "join fritt" system?
Det skulle bli väsentligt fler queries, vilket kan väl tänkas sänka prestanda generellt.
Dock så kan jag tänka mig att det skalar bättre i vissa fall när det blir så mycket data att joins börjar bli sega(?)
|
I dom flesta fallen är inte joins såpass långsamma att man behöver byta ut dem mot något annat. Kanske indexeras inte tabellerna som de borde. Har du kollat vad query analyzern säger? Kanske kan lazy loading vara lösningen på ett par områden, kanske behöver du platta till andra. Vill du veta vad som skalar bäst får du mäta - ändra och mäta igen. Tror inte att någon här kan ge dig ett svar på den frågan. Att skippa joins helt och hållet i en RMDBS måste anses vara ganska radikalt. Ska du ändå göra det - se till att det är befogat. Att anta det ena eller det andra är sällan bra i sådana här sammanhang.
Har du tittat på någon form av cache? Att bara cacha dom tyngsta frågorna kan avlasta databasen en hel del.