I've worked with both solutions and would like to say first off that it will take you longer to implement a solid XML solution versus the MySQL solution.
The point made by others is indexing and retrieving records based on indexes. You would rather say "Get 'bobs' record" Then "flip through all of the records until you find 'bobs'" So for the XML approach you would need to build binary indexes for each field that is to be a lookup. Perl's DB_File could do this for you. The index would reference the value of the field to the id of the file. DB_File is beyond the scope of this list but there are lots of resources for it. Other approaches to the indexing could be used. You would also need to implement a file locking mechanism so that the same file increment was not written by 2 processes. As well as locking for the indexes which is handled mostly by DB_File. This is going to be where your time is spent... Implement indexing for your xml data or learn MySQL? As far as performance, I actually think that the 2 are very comparable. As for stability and data integrity, also comparable when you think about the damage a corrupted database can do. There are ways to recover corrupted databases though, were as with the XML, you would need to be able to rebuild your indexes and have a backup of the XML files. Backup is important either way really. I like the flexibility XML offers. Although you may run into issues with character escaping in that MySQL offers you ways to let it safely quote your data for insertion. You will have to make sure that the data to be saved in the XML files does not compromise its integrity. C On 2/3/04 9:16 PM, "Bill Stephenson" <[EMAIL PROTECTED]> wrote: > If you're busy please forgive me and ignore this, if you have time to > offer an opinion I'd really like to hear from this list on this > subject; > > If I am building a web app from the ground up, what's the best way to > deal with storing/retrieving data? For arguments sake let's say the app > will have 2500 users to begin with that each hit the server an average > of 50 times a week. Each request delivers 40k of data. Users can search > through their saved records where each record contains 5-50k of data. > Users can have up to 2000 records. In 5 years the app will have, maybe, > 25,000 users. In 10 years, say, 100,000 users. If it ever has more > users than that, I'll write a help wanted message. > > I'd like to store using XML in a separate text file for each record > created because it's easy and gives me flexibility. I can add data > fields without tweaking tables in a MySQL database. I can add users > easily and keep their data in a separate directory that is easy to > locate. I'm told that storing/retrieving data in text files is slow and > so is parsing that data. I've never used XML::Parser but I thought I'd > give it a spin. > > I hear MySQL is speedy, but it seems to me that it adds complexity to > such a degree that it may not be an even trade off. I could store data > in an XML format in a single field in a MySQL database, but I'd still > have to parse it. > > As computers keep getting faster, and memory and storage cheaper, isn't > it beneficial to program in the most simple, human readable, least > learning required, method? > > In short, I'm lazy. I'd rather code this all in perl. Do I really need > to learn about and use MySQL or will computers get fast enough that it > won't matter anyway. > > Kindest Regards, > > Bill Stephenson >
