Re: Data Storage
iRing-RLopen wrote:
Gunnar Hjalmarsson wrote:
The member datafile is a risk. If a member updats his data and writing the new file to disk, for some reason, malefunktion then all members data is gone. Happend on my system at least 4 times. Really? I got to know about a couple of such incidents with one of the first Ringlink releases (more than two years ago), but after a code fix, I haven't heard of it. Nevertheless, I agree that keeping all the site data for a ring in the same file implies a risk that emphasizes the importance of taking backups. One reason for the current one file solution is that it makes sorting/reordering of the sites easy. I would also suggest that the statistic-files are moved into the same directory as the ring-files and the subdirectorys for each member is deleted. This directorys (not the files) uses unnecessary space, how much is depending on server configuration. In my case each directory uses 4 KB (not including file-size). 1500 ringmembers menas 6 MB of diskspace. Such a modification wouldn't be that easily done, but it would require several changes all over the program. I must say that 6 Mb disk space doesn't sound very much to me for a system that hosts rings with 1,500 sites. Shouldn't you still have non-used disk space exceeding that size, just in case? the future. The use of MySQL databases has been mentioned once in a while. Even if I'm anxious to keep Ringlink portable, I have the impression that a typical web hosting account nowadays includes MySQL. Of course, there is always a possibility to make data storage in a MySQL database an *option* besides the current method.
I would prefere to run Ringlink with a SQL-database. But think that the flat file-database must be a possibility. If you run just your own ring(s) you may not want to spend the extra money for SQL. There may be other options. For instance, the latest Ringlink version makes use of SDBM files for the statistics. It's a binary database format that is available from Perl on all Unix like and Windows platforms. / Gunnar
|