| [reply] |
Actually, upon closer inspection, I am displeased by DBIx::Tree. It works by getting all the rows in the table, then proceeding though a linear sort of the rows to put them in nested format. I'm sure I can improve upon that performance. | [reply] |
Yes you can improve on that performance - if you are using
an object oriented database or something like DB_File.
(With some sort of threading of keys - MLDBM is not the
best of approaches either.)
Otherwise the fact that hierarchical data structures do
not map well onto relational databases will kill you.
And firing repeated queries against the database (a very
obvious guess) is really bad.
You can beat what they do though, but not portably. And
the way you do it is to create and populate a temp table
on the fly with a stored procedure. Works except that
all of that is mumbo jumbo that some databases (very
specifically MYSQL) doesn't understand, and which tends
to be non-portable from database to database.
| [reply] |
Right. All of which is why I was looking at my Mapping field concept. (although I'm sure it's been done before).
| [reply] |
| [reply] |
I was referring more to my home-brew mapping idea, which isn't terribly portable. I have found a few items that I'll be sending on to the module author however.
For the curious:
- It requests every row of the table, but often you can select only row with id_column >=start_id (most systems will not have older nodes as replies to newer ones.) It can happen, so this should be some sort of flag
- It orders those rows by data_column, which also may not be desired. sort_column should be given, and if blank, this line can be dropped, presumably improving speed.
- With all of these flags flying around, (it already had a limit option and a match option) it may be easier to drop in an anonymous hash with these options set
- A slight internal change should allow access to more than one data column.
| [reply] |