O.K. I've been agonizing over this for some time now,

in this website i'm building, every registered user is gonna have
some data that he can review add update delete.
what would be the best way to store this data? in sql?, so that we have this one huge
table where we have one column that identify's the user (on average each user will have after a while between 1400 to 1700 records),
2nd option with sql is create different table for each user?.
in either case the database size can potentially be pretty big, which will horribly effect hosting budget!

or should i create an xml file for each user (there will be no trouble of multiple users trying to access same file). this will be better for hosting budget, however i don't know how will it effect the system performance to have so
many files on it?, also accessing and retreiving data from many xml files at once might strain the system (because it
seems like to read the xml, it loads the whole file to the memory ram right?)

so what should i do?

thx a bunch nati.

Recommended Answers

All 3 Replies

Database is much better if you talking in large number of members.
Secondly think about how will you design it. Stacking all in one large table is silly idea. Your database should consist of number of tables specifically designed for certain task. For example user_data_table to store user details where each each user can be identify by unique ID. Then you can use this ID in others tables for example forum_posts. This will have unique ID for each post but also hold used ID as foreign key to associate post with user.

If you not sure how to approach database design make another post in Database Design section of this forum and provide full details of what you trying to store in database and what sort of functionality you want to achieve.

XML has a huge overhead in the textual naming of the entities. Also it is not meant to be humad readable, it is a transport medium. Store the data in a database, the DB overheads will be trivial compared to XML and the disk use will be much less.

I made a custom multi level XML db. Sure I would never put all that data into one XML file either? I hear people trying to save images and stuff like that IN THE XML file?
I dont think SQL stores the image like that either? I got fed up with when SQL when it goes corrupt you lose everything inside that MDB.

anyway if you are good with SQL and tables, use multi leveled XML files just like SQL KEYED tables. You have a KEY on fileA.xml that say one is signed in under say "tony" who is employee ID23432 on your employee fileB.xml AND tony happens to be uploading reports to a web folder root/year2010reports/file where fileC.xml captures the worddocuments root and filename location to its codes.

2 benefits, you parse employee xml then select tony and can view all his files, or view his employee info. OR look at the file records xml and cross back to which employees uploaded/edit them. Use your xml records with KEYs that cross ref other xml files.
AND if any one part gets corrupt, you dont have to lose everything of all your entered data.

If one says its not fast, look at wartimepress.com theres way over 10,000 records, way over 7,000 images and that xml parse in xpath and xquery is fast, just the back side in dom is slow uploading new record sets. in 2011 I plan to make even more multi tier xml sectioned by types and intergrat a user xml portal for member viewing pdf and searches. I did that in classic asp, xpath, xquery, dom, and pure xml files no SQL's.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, learning, and sharing knowledge.