• Advertisement
Sign in to follow this  

Database Stuff

This topic is 4617 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm an applications guy. I can do SQL to get what I need out of a database but in working on my personal website project I, of course, just like everyone else on the web, have a database behind it with all the major content and the pages are generated on the fly (with PHP in my case) using queries. Now would it be a bad idea to store long documents, like articles/reviews/whatnot in the database? Actually now that I think about it, the alternative, storing a filename, would probably be more problematic because of concurrency issues (despite how unpopular my website may be...) Anyway, what will hurt me more? Having too many tables, too many rows, or too many columns? Obviously having too much of anything is bad, but which should I try to cap? To keep table size down, for instance, I was planning on having four~ tables to store user comments, that would rotate every three months so that they wouldn't get out of hand to the point of making queries arduously long after a while. Is this a bad or a good idea? Also, JOINing. Good because it prevents you from having to do two queries or bad because it has to deal with more data? Why can't life just be like C? Logical, simple, and Darwinian in nature? :P

Share this post


Link to post
Share on other sites
Advertisement
Sounds like premature optimization - namely of the "I should shorten the names of all my functions so my program runs faster" kind.

You'll probably want to learn a bit more about databases and database design (including the specific database you'll use). Right off the bat I can tell you splitting records across multiple tables to prevent one table from having a lot of records is just plain silly (the only time you'll see this is when running a powerhouse multiple server setup, in which a table is split across several servers and seamlessly joined together).

Share this post


Link to post
Share on other sites
For small databases, how you partition tables is probably not going to be an issue. The real hit in database performance comes at I/O time. If the entire database is small, it may fit into the database cache, and thus any seek will benefit from being in memory.

Once the database gets larger, the next biggest problem is queries. So, how you design your tables, views, and indexes will be important if you expect a larger database. For example, you may design a view that causes a 'table scan' (i.e. the database needs to look at every record in the table) when adding an index will allow the view to visit only certain records.

Modification issues (adding, changing, deleting records) will probably not be an issue with a single user database.

Some people ask, why not just put indexes on all data columns? The problem is both space (indexes take up space) and time (any table modifications require updating of all the indexes). So, for large scale databases, database design is a bit of an art.

There are books that go into great detail about how databases work, and give insight into how this art operates. If you think that you're going to have problems, or are just curious, pick up a good database design book (one that also includes performance and optimization). Besides, its a good skill to show on a resume (albeit more of a business skill instead of game skill). Good luck.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement