SGA/PGA best practice

Question

With an XE limitation of 1GB for the PGA and SGA, how would one best preserve this limitation?
In other words, how would one minimise the PGA and SGA usage via ones interface with Oracle?
For instance, in a SQL query I was building I could either (The query has multiple aggregates on multiple tables in a 'one to many' join relationship):
1) Use WITH clauses
2) Use inline views
3) Use standard views
4) Use temporary tables
5) Maybe more possibilities
Without much of an insite into how Oracle 'works' it's difficult to gauge which of these is less 'resource hungry'.
Possibly there is a reference on how to use the PGA & SGA efficiently?
Or possibly a more definitive explanation on what's actually stored in these memory areas (rather than just 'prorgam' and 'system' data).
Regards all,

Answer 1

SGA is used in 2 main areas: parsing the SQL and avoiding disk reads by having stuff in memory. There is one SGA for all of XE instance.
PGA is used heavily for sorting, hash joining and 'working stuff'. The PGA is created for each Dedicated Server process. Much of the PGA is inside the SGA for Shared Server processes
SGA: (There are exceptions to each of these 'Rules Of Thumb' or 'ROT' statements)
Good coding technique will allow reuse of SQL and avoid as much as possible reparsing;
Use bind variables;
Do not create SQL on the fly;
Avoid dynamic SQL (concat strings to create SQL on the fly);
Forget about tweakiing the buffer cache as it is mainly a performance thing that you can't do much about in XE;
WITH clause is nice as it may reduce the count of subqueries;
Leave it with 'automatic memory management' (again a perf hit, but it will attempt to optimize mem availability);
Don't reinvent - Use the features that are loaded as they will likely get statements out faster, releasing memory faster;
Stored Views may (often do) grab unneeded table data. When joining to stored views, see whether they can be replaced by cleaner code;
Do not create SQL on the fly.
PGA:
Use shared server when feasible (at risk of performance hit);
Global Temp Tables go into PGA, watch the use;
Maximize reuabale SQL, minimze all other languages (remote or in DB) including PL/SQL;
Watch for PGA wasters such as UNION vs the better UNION ALL, and unneeded sorts;
PGA is 'swapped out' to Temporary tablespace. Make sure temp tablespace big enough ... it's not counted in the 4GB disk;
Avoid using COMMIT except at end of transaction. Avoid COMMIT in loops. Make sure undo tablespace is big enough ... it's not counted in the 4GB disk ;
Did I mention it's not a good idea to create SQL on the fly?