Hmm,
That's what I thought I was doing by putting the
common fields of each article type in a single table.
I do need to rethink the search functions. Was
thinking of a fulltext index on title and
article_content fields.
basic table is
id | type | author | date | last_update | title |
keywords
A quick note, I've read Tom's email about using a hanger table and simply don't agree.
From: olinux <[EMAIL PROTECTED]>
> I have a table with a large number of news articles.
For my curiosity, how many article records is "a large number"? A few thousand, or
tens of millions?
> The question
I disagree. Joins can be expensive. Now PERHAPS Tom's suggestion is a good
one, but its hard to say. Remember, excess fields can always be left out of a
SELECT, so they don't neccessarily cause a performance problem. Some things
are true though, fixed length records are more efficient, so if yo
Hello olinux,
If I were in your shoes, I would put not only paths to images into a separate
table, but also a field called "content" and probably title, summary,
author and linked all this stuff together via ID-like fields which are
primary keys in those new tables. Then articles table can be sea
Hello,
I have a table with a large number of news articles.
Articles of type 'feature' (identified in the
article_type field) will have the path to an image
associated with the article stored. The question is
whether to 1) add a field to the database that most
records will not use OR 2) add a ta
