But that blows up your DB to an expensive amount, when you store the children node id's to a node. Remeber, you will never know how many children a node will have. But a child node always has only one parent.
Have a nice day
All decision is left to your taste | [reply] |
Well, I was figuring you would only store children's node id, and only one deep (ie, immediate children). Unless each node in your application is expected to have an extreme amout of immediate children, I don't see that it would be a problem.
Let's see... Generously, 4 bytes to store a node id and 100 immediate children on avg. gives only 400 extra bytes per node. That's not a huge amount and most nodes on PM have far less than 100 immediate children. I don't recall any I've seen with greater than 30. That's only 120 extra bytes per node.
Not sure how many, if any, DB's support variable length data-arrays but you could always use a blob and pack it yourself. A little more work, but not as much as an exhaustive search of the DB for every node with a parent ID of xx.
Don't get me wrong, I understand your point and I know that it might not be worth it in some cases. I just don't think that most cases (and this one in particular) would be that hurt by the cost and I think the benefit would outway the small cost of extra size. 'Tis, of course, the Implementator's call; and the point is moot in this case unless we feel like submitting a patch to EveryDevl.com. :-)
Disclaimer: It is quite possible (likely?) that I am mistaken and/or am relying on an invalid assumption. I don't know a great amount about the Everything engine, nor even the general implementation of such systems. Therefore, I provide no warranty for this post, expressed or implied, for fitness of use or merchantability or anything else. I disavow all knowledge of my own actions and assume no responsibility for anything. ;-)
bbfu
Seasons don't fear The Reaper.
Nor do the wind, the sun, and the rain.
We can be like they are.
| [reply] |
Not sure how many, if any, DB's support variable length data-arrays but you could always use a blob and pack it yourself. A little more work, but not as much as an exhaustive search of the DB for every node with a parent ID of xx.
The two things I've learned about relational databases are :
- Don't create artificial data structures within blobs, the DB is better at handling them than you are.
- If you have a many-to-many relationship (== variable length array in Perl), use another table with the relations in it.
In this case, this would mean having a relation table, isChild, which would consist of two columns,
parentID and childID. If you have a database with triggers, you can maintain the integrity with stored procedures, if not, you can at least handle node deletions gracefully with a small SQL script.
| [reply] |
