Re: II article database II

I have yet to see an article-based script that resembles what I am looking to develop, however, it must be a very common script implemented among web-developers. Has anyone seen a similar script available somewhere? BTW, thanks Chris -- that helped plenty. I was thinking about setting up a search-input for people to query the article-db entirely -- based on your search-type #7... I will need to read up on the details with this type of implementation. Or maybe -- add a second column to my database that allows the content-editors to add search-key words or a summary that best describes their article << and limit the search based on these values only. -----Original Message----- From: Chris Adams <chris@digitaria.com> To: php-general <php-general@lists.php.net> Date: Tuesday, July 18, 2000 9:47 PM Subject: Re: [PHP] 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. > > > >-- >PHP General Mailing List (http://www.php.net/) >To unsubscribe, e-mail: php-general-unsubscribe@lists.php.net >For additional commands, e-mail: php-general-help@lists.php.net >To contact the list administrators, e-mail: php-list-admin@lists.php.net >