Well, there's really no "perfect" database setup.... only what's perfect for your situation. If it does your job, and does it efficiently, it may not be perfect for someone else. So you can't say that you'll never need to update it.
Anyway....
You want to make a news page, but you don't specify what data you want shown, or stored, and only give us a basic outline of one table from the database.
To me, it seems you'd want to have a few tables, one for categories, one for users, one for types, and one for the actual post/news item.
They'd look something like:
categories
cid integer(11) auto_increment NOT NULL
category text NOT NULL
users
uid integer(11) auto_increment NOT NULL
username varchar(32) NOT NULL
password varchar(64) NOT NULL
name text NOT NULL
types
tid integer(11) auto_increment NOT NULL
type text NOT NULL
news
nid integer(11) auto_increment NOT NULL
cid integer(11) NOT NULL
tid integer(11) NOT NULL
uid integer(11) NOT NULL
title text NOT NULL
description text NOT NULL
In the "news" table, the cid, tid, and uid would be "foreign keys" to the other tables. This helps so that when you query the table "news" you can join the other tables onto it and they'll all have a valid reference point.
Separating the information like I have above allows for more portability, and if you need to edit a title to a type or category, you only change it once, not every instance in the database.
It's a general way to go, but it's usually good bet that separating tables into specific parts is the best. This would give you the optimum opportunity to expand some tables as needed, or add other tables/columns later without destroying your code....
