database usage

[crawfd]

Currently building a site that could possibly contain 300+user accounts and give them the availability to post blogs.

Should I post these entries in text files instead, or store the blog entries for each user in just one field of a database in MySql?.

The reasons why I'm contemplating using a text file to store blog entries is database load. I'm concerned that if I do in fact get 300+users and get around 30 concurrent users, that the database will get sluggish because of the reading and writing of the entries field (which would contain and extermely large blob of text).

Any comments or suggestions? Thanks

[laserlight]

Well, if you use a flatfile database, you may still end up with a "sluggish" database.

MySQL should be able to easily handle what you described, though of course it really depends on the server.

[crawfd]

What if I have multiple entries in a users journal and store each journal entry as a record.

Let's say one users journal totals 100 entries in one month time period.

Now let's say I have 300 users, that would come out to 30,000 records by which the database would have to read and possibly write.

OR

That's why I'm just conisdered having a user enter info into one large blob (field) and not breaking it into records, thus eliminating the need for a large amount of records per user and database load.

Any suggestions????

[ahundiak]

Write a blog posting api. Functions (or methods) like post_blog_entry_for_user();
Have your application program use only these api functions.

Now you can start by implementing the blog api using only database tables. If performance is inadequate then implement a text based blog api. Either way, you application can remain unchanged.

[crawfd]

Is post_blog_entry_for_user(); a predefined function? Or are you telling me to build a custom function?

If I listed multiple functions wouldn't it be considered a class.

[laserlight]

Build a custom function.

What ahundiak means by "Write a blog posting api" is to write a function library/module/class to handle blog posting.

[Sxooter]

MySQL, properly tuned, should be fine for 300 people. IF you're looking at 30,000 people, you might wanna do some more parallel load testing on other databases to see how well each holds up to your load.

You've got two problems to solve here. 1: Editing content by up to 300 people (mixed read / write enfironment) and 2: Put these things on the web where tens of thousands of people may want to read it, i.e. all read, no write.

So, storing them in text files ain't such a bad idea. You can store each one in a directory, using something like a timestamp for its name or even checking it's last modified time to sort it by when displaying entries. It's not hard to write something that includes("") a file or two in it.

But a database may be fine too. If you plan it for parallel editing.

Since only one user is gonna be editing their data at a time, it's likely a very good place to use tables that support high performance under those conditions if you wanna just store all the articles in one big table.

Properly indexed, you should be able to retrieve individual rows pretty fast.

I'd test it under parallel load before I went live though.