Re: II article database II

>I guess, I dont want to slow the database down, >but I'm not quite sure what the capabilities are >for mySQL if I am putting long articles in the >database........also what type of datatype would >I use for this field in my database (for those >of you that are familiar with mySQL)........... Store it in the database. It's going to require a lot less code, you'll avoid some potentially messy code (e.g. potential file locking issues) and you'll probably see no difference in performance (possibly even a fair performance gain for MySQL depending on configuration). It's also much easier to work with if you decide to start syndicating content or using a template system. Ironically, I think your performance numbers might actually be better with larger articles as the network connection to the client takes up a higher percentage of the overall processing time, to say nothing about how long it will take the browser to render a large page. With MySQL I'd rank SELECT performance as follows from fast to slow: 1. SELECT COUNT(*), MIN(), MAX() - these are absurdly fast on indexed columns; COUNT(*) will be filled straight out of the in memory table definition. 2. SELECT single record on a single value for an index key (e.g. SELECT ID, Title, Content FROM Documents WHERE ID=$ID LIMIT 1). 3. SELECT single record on multiple values on an index key (e.g. SELECT ID, Title, Content FROM Documents WHERE ID=$ID OR ID=$OtherID LIMIT 1). 4. SELECT on multiple records as in #2 & #3. 7. SELECT with wildcards where the start of the search text is constant and you are search a column with an index (e.g. SELECT ID FROM Documents WHERE Content LIKE '$SearchWord%') 6. SELECT on non-indexed columns - this requires MySQL to check every single row in the database. Table scans are very expensive 7. SELECT with wildcards where the start is a wildcard (e.g. SELECT ID FROM Documents WHERE Content LIKE '%$SearchWord%') 8. SELECT on [non-indexed] fields with conversion (SELECT ID FROM Documents WHERE MD5(Content) = '$MD5Hash') Mixing in other tables, ORDER BY/GROUP BY and not using LIMIT when you can all impact performance. Worst case would be a SELECT from multiple tables using wildcards, complex GROUP BY/ORDER BY and multiple conversions. The MySQL manual has a fairly long section on all of the gory details about how to keep MySQL fast. It'd be a good idea to read this if you're worried about performance. As far as the field types go, look into TINYTEXT, TEXT, MEDIUMTEXT and LONGTEXT.