Hi, I wanted to hear from you experienced umbraco dev's about using Umbraco nodes (documents) to store general data, instead of saving it directly in db tables. One gets a lot for free storing data in nodes, and the drawbacks would be some overhead, especially if the nodes are published. (However not publishing them means not being able to use them within xslts, right?) Say for example for a order system, that would store thousands of orders and x times more order rows, would it be a very bad idea to use nodes for that? I see a lot of re-usable stuff coming if there are no big drawbacks I'm missing here. Also turning to 4.1, less Sql calls will be made for each document operation, right?
I've always viewed nodes as a method for storing content or data supporting content which tends to be static and the only logic resides in the display of that content. The document type structure is very generalized and while this works for content, other types of data are probably better stored in a defined table structure. In your example of an order system, you would be missing out on triggers, stored procedures etc (without stepping to close to the core), which i am sure would benefit your order system's efficiency.
Two packages that might give you some insight from those on the Umbraco Core team are Commerce for Umbraco and uForums. Both packages store their fixed data in separate database tables.
Even storing your data in separate tables you can write custom xslt extensions to use within your macros to display the order information (ex: to a logged in customer).
It really depends on how much CRUD operations your intending to do on the data and just how complex it is.
If you've got dozens of properties on each item that you need to be updating on a frequent basis then the Umbraco API is probably not the way to go.
Using the Umbraco API as an interface to a complex relational database is not a good idea though as the performance overhead from constant CRUD operations will be a big hindrance.
Thanks a lot for sharing your wisdom guys! Yes, following good examples would probably be the safest way to go. The CRUDs will be kind of straight forward, no particular complexity, most data will be inserted once and never edited. Another thing is that the project does not have a data design set in stone, it will change and grow during the project. And for me document types first felt good and flexible to work with for that reason. With a port-all-of-this-to-external-tables in mind for later on. But, knowing that planned future improvements of that kind rarely come to realization I just might skip that plan and go for the db tables from start.
Store lots of data in nodes (documents)?
Hi, I wanted to hear from you experienced umbraco dev's about using Umbraco nodes (documents) to store general data, instead of saving it directly in db tables. One gets a lot for free storing data in nodes, and the drawbacks would be some overhead, especially if the nodes are published. (However not publishing them means not being able to use them within xslts, right?) Say for example for a order system, that would store thousands of orders and x times more order rows, would it be a very bad idea to use nodes for that? I see a lot of re-usable stuff coming if there are no big drawbacks I'm missing here. Also turning to 4.1, less Sql calls will be made for each document operation, right?
Regards
Jonas
Jonas,
I've always viewed nodes as a method for storing content or data supporting content which tends to be static and the only logic resides in the display of that content. The document type structure is very generalized and while this works for content, other types of data are probably better stored in a defined table structure. In your example of an order system, you would be missing out on triggers, stored procedures etc (without stepping to close to the core), which i am sure would benefit your order system's efficiency.
Two packages that might give you some insight from those on the Umbraco Core team are Commerce for Umbraco and uForums. Both packages store their fixed data in separate database tables.
Even storing your data in separate tables you can write custom xslt extensions to use within your macros to display the order information (ex: to a logged in customer).
Go with external tables IMHO:)
-Chris
It really depends on how much CRUD operations your intending to do on the data and just how complex it is.
If you've got dozens of properties on each item that you need to be updating on a frequent basis then the Umbraco API is probably not the way to go.
Using the Umbraco API as an interface to a complex relational database is not a good idea though as the performance overhead from constant CRUD operations will be a big hindrance.
4.1 has *some* improvements around reading data out of the database, but there's not a great deal of changes. See my response in this thread as to why Umbraco documents save in the way they do: http://our.umbraco.org/forum/ourumb-dev-forum/features/8279-Feature-request-to-improve-performance-when-modifying-Document-through-API
Thanks a lot for sharing your wisdom guys! Yes, following good examples would probably be the safest way to go. The CRUDs will be kind of straight forward, no particular complexity, most data will be inserted once and never edited. Another thing is that the project does not have a data design set in stone, it will change and grow during the project. And for me document types first felt good and flexible to work with for that reason. With a port-all-of-this-to-external-tables in mind for later on. But, knowing that planned future improvements of that kind rarely come to realization I just might skip that plan and go for the db tables from start.
Found this related post http://our.umbraco.org/forum/templating/templates-and-document-types
Regards
Jonas
is working on a reply...