Hi all, I am trying to work out whether or not custom data should live within the umbraco tbales, or whether custom tables should be built for them. The project i am currently working on is going to accept application forms, and they envisage this data to grow quiet quickly. Should i be storing this data within the umbraco tables or should i build custom ones ? My concern about putting them into umbraco is that the node could end up becoming very large, and so i would not want to keep them within the Content section and was thinking if there is the possibility of duplicating the content section as a new one .... called Custom data. This way i would get all the functinality of being able to use datat types, doc types, and the publishing options...
Help in working out which way i shoudl go will be greatly appreciated.
In my opinion, data like this is not content that is going to be used in your website, so it should not really live in Umbraco. That being said, it is handy for the editors of the site to be able to access this info from within Umbraco.
Copying the tree would give the same problem elsewhere, right?
I think I would use custom tables and use a simple Dynamic Data project (it's very nice, simple and easy CRUD) in a tab in the backend of Umbraco.
Or, if you still want to keep it in Umbraco, you could solve the problem by creating a somewhat logical sorting structure like date folders (all the form submissions in week x or month x for example).
HI Sebastiaan, thank you for your comment. Is there any limit as to how much data should be stored in umbraco ... as an example one of the tables i am thinking of moving into umbraco will have upwards to 200,000 records .... this would turn out to be quiet a lot of XML
In theory there is no limit, I'm currently running a site with 30000 records an the umbraco.config is only 15 megabytes. Maybe with more text, it would grow to about 20-30 megs. XSLT is super fast so I'm not worried about the size of the XML.
However, if there is a long list of childnodes under one node, you will suffer some performance issues because Umbraco needs to do a lot of queries to expand the nodetree.
To get around the child node issue, yes i will look to do what you suggest (year folder, month folder) ... and also maybe A-Z folders for some of the contents ...... I have created a few custom sections in umbraco, and should be easy to create it for this, howeevr how would i go about creating a duplicate of the Contents section .... i woudl want to do this so i can keep all the publishing controls
Alot of it has to do with the complexity of the data and how often that data will be updated. If you're storing application data it might be better to store in custom tables since it is probably more efficient to write you're own CRUD operations that will provide more flexibility.
I also don't envision application forms as content, so it might be better to manage elsewhere, outside the content tree. custom section -> custom tables.
If you accepting applications, have you looked at contour?
Custom data
Hi all, I am trying to work out whether or not custom data should live within the umbraco tbales, or whether custom tables should be built for them. The project i am currently working on is going to accept application forms, and they envisage this data to grow quiet quickly. Should i be storing this data within the umbraco tables or should i build custom ones ? My concern about putting them into umbraco is that the node could end up becoming very large, and so i would not want to keep them within the Content section and was thinking if there is the possibility of duplicating the content section as a new one .... called Custom data. This way i would get all the functinality of being able to use datat types, doc types, and the publishing options...
Help in working out which way i shoudl go will be greatly appreciated.
Thanks
In my opinion, data like this is not content that is going to be used in your website, so it should not really live in Umbraco. That being said, it is handy for the editors of the site to be able to access this info from within Umbraco.
Copying the tree would give the same problem elsewhere, right?
I think I would use custom tables and use a simple Dynamic Data project (it's very nice, simple and easy CRUD) in a tab in the backend of Umbraco.
Or, if you still want to keep it in Umbraco, you could solve the problem by creating a somewhat logical sorting structure like date folders (all the form submissions in week x or month x for example).
HI Sebastiaan, thank you for your comment. Is there any limit as to how much data should be stored in umbraco ... as an example one of the tables i am thinking of moving into umbraco will have upwards to 200,000 records .... this would turn out to be quiet a lot of XML
In theory there is no limit, I'm currently running a site with 30000 records an the umbraco.config is only 15 megabytes. Maybe with more text, it would grow to about 20-30 megs. XSLT is super fast so I'm not worried about the size of the XML.
However, if there is a long list of childnodes under one node, you will suffer some performance issues because Umbraco needs to do a lot of queries to expand the nodetree.
To get around the child node issue, yes i will look to do what you suggest (year folder, month folder) ... and also maybe A-Z folders for some of the contents ...... I have created a few custom sections in umbraco, and should be easy to create it for this, howeevr how would i go about creating a duplicate of the Contents section .... i woudl want to do this so i can keep all the publishing controls
Any other points of view ?
Asif,
Similar topic a while back. http://our.umbraco.org/forum/developers/api-questions/8419-Store-lots-of-data-in-nodes-(documents)?p=0#comment30953
Alot of it has to do with the complexity of the data and how often that data will be updated. If you're storing application data it might be better to store in custom tables since it is probably more efficient to write you're own CRUD operations that will provide more flexibility.
I also don't envision application forms as content, so it might be better to manage elsewhere, outside the content tree. custom section -> custom tables.
If you accepting applications, have you looked at contour?
-Chris
is working on a reply...