|
in reply to Re^3: Efficiently Walking Large Data Structures Stored in Multiple Tables
in thread Efficiently Walking Large Data Structures Stored Across Multiple Tables
whilst recursive queries are fun, as you can do a whole lot of lookups and join them together in one sql statement; they do take a long time to run, significantly degrading performance. The flatter you can make the structure of the database, especially the often used tables, the faster the retrieval -- unfortunatelly this also means you end up with extra effort in maintaining the tables, as they start having redundant data (not fully normalised). |
Re^5: Efficiently Walking Large Data Structures Stored in Multiple Tables
by adrianh (Chancellor) on Feb 29, 2004 at 22:29 UTC
|
whilst recursive queries are fun, as you can do a whole lot of lookups and join them together in one sql statement; they do take a long time to run, significantly degrading performance.
Take another look at the bits of the thread on using a nested set representation for hierarchical data. Flat structure, normalised data and fast queries. Some performance degradation on insertion, but since people usually read and update a lot more than they insert it's rarely an issue.
As for recursive queries - the old chestnut about premature optimization comes to mind. That and the fact that several databases have explicit support for hierarchical structures and appropriate optimisations to make access to those structures efficient - even if they set C.J. Date spinning in his grave ;-)
| [reply] |
|
