Infinate levels of hierarchal data
-
In many database solutions folk tend to use tables with one to many relationships in order to hierarchal data where as the following achieves the same. ID - Field1 - Field2 - ParentID 1 x y 0 2 xx yy 1 3 rr r 1 4 pr p 2
I won't downvote you for this but it is entirely the wrong place to post your code. If you really want to post this turn it into an article. I would remove it rather quickly if I were you, before it does get downvoted and obliterated.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. nils illegitimus carborundum me, me, me
-
I won't downvote you for this but it is entirely the wrong place to post your code. If you really want to post this turn it into an article. I would remove it rather quickly if I were you, before it does get downvoted and obliterated.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. nils illegitimus carborundum me, me, me
-
I don't have the power to do that I'm afraid.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. nils illegitimus carborundum me, me, me
-
I won't downvote you for this but it is entirely the wrong place to post your code. If you really want to post this turn it into an article. I would remove it rather quickly if I were you, before it does get downvoted and obliterated.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. nils illegitimus carborundum me, me, me
Top of Page:
The Weird and The Wonderful forum is a place to post Coding Horrors, Worst Practices, and the occasional flash of brilliance.
I'm guessing the OP thinks this is a brilliant data structure (though I don't agree).
-
Top of Page:
The Weird and The Wonderful forum is a place to post Coding Horrors, Worst Practices, and the occasional flash of brilliance.
I'm guessing the OP thinks this is a brilliant data structure (though I don't agree).
To be fair he is a n00b and the original post had much more code (not that it was any more insightful but we all have to learn, somehow).
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. nils illegitimus carborundum me, me, me
-
Top of Page:
The Weird and The Wonderful forum is a place to post Coding Horrors, Worst Practices, and the occasional flash of brilliance.
I'm guessing the OP thinks this is a brilliant data structure (though I don't agree).
The illustrated structure is not the normal approach to db design and not tought to everyone, It wasn't in my day. But is now given in some hard back publications, for the intermediate skilled person, as an example of how to use a database to run the .net menu control. Some folk prefer to code XML files to run the .net menu controls, but others prefer a database. Thus allowing one to standardise on using datbases for everything rather than a mix of db and xml on a website.:thumbsup: The structure is also great for managing lists as one does not need one table for the list name and one for the list items, less overhead:thumbsup: For example it is great for the storage of dropdown list values as one can basically use the same sql for all dropdown controls - just passing a different 'ParentID' to get a different data set for the control. This simplifies life in some areas when buildiong a N-Tier Application - Select field1, field2 From table Where ParentID = @ParentID is all you would ever need to code against/use to retrieve any list!:thumbsup: It all boils down to preference, what you need to do and how you have been tought! The structure is not for everyone and everyone should always use what they are happiest using. Happy coding :)
-
In many database solutions folk tend to use tables with one to many relationships in order to hierarchal data where as the following achieves the same. ID - Field1 - Field2 - ParentID 1 x y 0 2 xx yy 1 3 rr r 1 4 pr p 2
Somewhen in the past, hierarchical databases were used. For example, the programming language MUMPS was advertised as a programming language with integrated database - and that database was a hierarchical database. Somewhen later, hierarchical database were given up. Can you guess why?
-
The illustrated structure is not the normal approach to db design and not tought to everyone, It wasn't in my day. But is now given in some hard back publications, for the intermediate skilled person, as an example of how to use a database to run the .net menu control. Some folk prefer to code XML files to run the .net menu controls, but others prefer a database. Thus allowing one to standardise on using datbases for everything rather than a mix of db and xml on a website.:thumbsup: The structure is also great for managing lists as one does not need one table for the list name and one for the list items, less overhead:thumbsup: For example it is great for the storage of dropdown list values as one can basically use the same sql for all dropdown controls - just passing a different 'ParentID' to get a different data set for the control. This simplifies life in some areas when buildiong a N-Tier Application - Select field1, field2 From table Where ParentID = @ParentID is all you would ever need to code against/use to retrieve any list!:thumbsup: It all boils down to preference, what you need to do and how you have been tought! The structure is not for everyone and everyone should always use what they are happiest using. Happy coding :)
-
Somewhen in the past, hierarchical databases were used. For example, the programming language MUMPS was advertised as a programming language with integrated database - and that database was a hierarchical database. Somewhen later, hierarchical database were given up. Can you guess why?
Thenks for the feedback In many instances hierarchical is totally not worth looking at and can be a nightmare to manage, but there is a place for it, and when used with an interface to meet a functionality requirement it can be a great advantage. Expearience has shown that hierarchical data in a single table can be very effective when the user interface mimics that of a file management system to manage the data and you proved breadcumb navigation to go back a level or two. In short - hierarchical data to more than a few levels is not for the faint hearted and even then you realy need to be sure that you understand what you are getting yourself into. (be prepared for developing some prity elaborate loops and/or non pimple coding) Sitting on my bookshelf are numerious intermediate level books that show how to use hierarchical data to power .net sitemap and menu controls from a database rather than xml files. So whilst programming languages like MUMPS have dissapeared there is still a requirement for the strategic use of hierarchical data. The key word being STRATEGIC. For those who want to investigate things further #IHierarchicalDataSource Interface# can be found at http://msdn.microsoft.com/en-us/library/d3ef7363(v=vs.90).aspx #### ASP.net 3.5 Unleashed by Stephen Walther Chapter 19 gives a blow by blow example with sample code for binding a menu control directly to the database - a Hierarchical table. Happy coding :)
-
Thenks for the feedback In many instances hierarchical is totally not worth looking at and can be a nightmare to manage, but there is a place for it, and when used with an interface to meet a functionality requirement it can be a great advantage. Expearience has shown that hierarchical data in a single table can be very effective when the user interface mimics that of a file management system to manage the data and you proved breadcumb navigation to go back a level or two. In short - hierarchical data to more than a few levels is not for the faint hearted and even then you realy need to be sure that you understand what you are getting yourself into. (be prepared for developing some prity elaborate loops and/or non pimple coding) Sitting on my bookshelf are numerious intermediate level books that show how to use hierarchical data to power .net sitemap and menu controls from a database rather than xml files. So whilst programming languages like MUMPS have dissapeared there is still a requirement for the strategic use of hierarchical data. The key word being STRATEGIC. For those who want to investigate things further #IHierarchicalDataSource Interface# can be found at http://msdn.microsoft.com/en-us/library/d3ef7363(v=vs.90).aspx #### ASP.net 3.5 Unleashed by Stephen Walther Chapter 19 gives a blow by blow example with sample code for binding a menu control directly to the database - a Hierarchical table. Happy coding :)
You may be interested in another way of doing hierarchical data in a table. It looks a bit like this:
Id
ParentId
IdPath
WhateverData
1
NULL
1
Blah
2
1
1_2
Blah
3
1
1_3
Blah
4
NULL
4
Blah
5
2
1_2_5
Blah
6
5
1_2_5_6
Blah
If you include the full path of ID's (the ID and all ancestor ID's), you can reduce the number of queries required to get all descendents of a record. I think newer versions of SQL Server have some ability to query hierarchical data, but this approach will work on all SQL systems.
-
You may be interested in another way of doing hierarchical data in a table. It looks a bit like this:
Id
ParentId
IdPath
WhateverData
1
NULL
1
Blah
2
1
1_2
Blah
3
1
1_3
Blah
4
NULL
4
Blah
5
2
1_2_5
Blah
6
5
1_2_5_6
Blah
If you include the full path of ID's (the ID and all ancestor ID's), you can reduce the number of queries required to get all descendents of a record. I think newer versions of SQL Server have some ability to query hierarchical data, but this approach will work on all SQL systems.