Change of structure of the table "modx_site_content"

Whether you consider possible to change structure of the table modx_site_content (or to add the new table) as is described below (for realization of a method "Preordered Tree Traversal").

Instead of a field parent to add following fields:
globalindex int (10) - contains an index of a folder/page in a tree of documents,
lastchild int (10) - contains value of "globalindex" of the last descendant (lastchild=globalindex if the document is page instead of a folder),
level int (3) - a level of an enclosure.

For example:
folder 1(globalindex=1, lastchild=10)
--page 1(globalindex=2, lastchild=2)
--folder 2(globalindex=3, lastchild=9)
----page 2(globalindex=4, lastchild=4)
----folder 3(globalindex=5, lastchild=8)
------page 3(globalindex=6, lastchild=6)
------page 4(globalindex=7, lastchild=7)
------page 5(globalindex=8, lastchild=8)
----page 6(globalindex=9, lastchild=9)
--page 7(globalindex=10, lastchild=10)
folder 4(globalindex=11, lastchild=13)
--page 8(globalindex=12, lastchild=12)
--page 9(globalindex=13, lastchild=13)
.....

Then for creation of a sitemap it is possible to use queries similar to the following:
1. SELECT * FROM modx_site_content WHERE id=$startPageId
2. SELECT * FROM modx_site_content WHERE globalindex > $startPageGlobalIndex AND lastchild <= $startPageLastChild ORDER BY globalindex ASC

For breadcrumbs:
1. SELECT * FROM modx_site_content WHERE id=$currentPageId
2. SELECT * FROM modx_site_content WHERE globalindex < $currentPageGlobalIndex AND lastchild > $carrentPageLastChild ORDER BY globalindex ASC

The list of child documents:
1. SELECT * FROM modx_site_content WHERE id=$startPageId
2. SELECT * FROM modx_site_content WHERE globalindex > $startPageGlobalIndex AND lastchild <= $startPageLastChild AND level=$startPageLevel+1 ORDER BY globalindex ASC

Addition of 1 child document:
1. SELECT * FROM modx_site_content WHERE id=$previousPageId - получаем значения globalindex и lastchild
2. LOCK TABLES modx_site_content WRITE
3. UPDATE modx_site_content SET globalindex=globalindex+1, lastchild=lastchild+1 WHERE globalindex > $previousPageGlobalIndex
4. UPDATE modx_site_content SET lastchild=lastchild+1 WHERE globalindex <= $previousPageGlobalIndex AND lastchild > $previousPageGlobalIndex
5. INSERT INTO modx_site_content SET globalindex=$previousPageGlobalIndex+1,lastchild=$previousPageGlobalIndex+1
6. UNLOCK TABLES

Deletion of 1 child document:
1. SELECT * FROM modx_site_content WHERE id=$deletePageId
2. LOCK TABLES modx_site_content WRITE
3. DELETE FROM modx_site_content WHERE id=$deletePageId
4. UPDATE modx_site_content SET globalindex=globalindex-1, lastchild=lastchild-1 WHERE globalindex > $deletePageGlobalIndex
5. UPDATE modx_site_content SET lastchild=lastchild-1 WHERE globalindex < $deletePageGlobalIndex AND lastchild > $deletePageGlobalIndex
6. UNLOCK TABLES

Etc.

What do you think about?

I appreciate your suggestion and I have considered several approaches to implementing nested set capabilities, but we will not be modifying the structure of this table in this way at this time.

One idea is to create an add-on that can store a model of this from the existing data; you could use this in scripts where you want access to this functionality.

I have understood. Thanks.