If you don’t use a database to hold any of your site’s content, then your content and the HTML markup are inextricably intertwined, and every new bit of content requires more markup.
By storing content that has a repeating structure of any kind in the database, new content can be added simply by filling in a form. You only need to create one page that shows the markup that surrounds the information from the database, and then the pages for each item in the database are created automatically, all with exactly the same markup. If you want to change the design, you only need to change that one page, and all instances change automatically.
Setting up your database takes some effort, but the rewards are great. Once you have the structure created and some initial content entered, you’ll find that it’s very easy to add new content, so your site will always be fresh. As you add more items, your site can grow to hundreds or even thousands of pages, yet there are only three pages that you need to design. Your design will always be consistent, and the people adding content don’t have to worry about markup.
To design your database structure, you have two primary tasks:
Categories enable you to organize content by topic. Categories are hierarchical and can be nested to any depth (sub-category, sub-sub-category, and so forth). For virtually all purposes, a sub-category at any depth functions the same as any other category. An item can be assigned to any number of categories.
For many sites, the top-level category names are used in the main navigation, and for this purpose it is best to limit the design to six to eight top-level categories. In most cases, a two-level structure (categories and sub-categories) is sufficient, and keeping it to two levels simplifies navigation. It is possible, however, to have any number of top-level categories, and to have as many levels as you want. (Note: a sub-category is just a category that has a parent category; all references to category apply to categories at any level. We talk about subcategories only when necessary to distinguish between categories that have a parent category, and those that do not.)
It is well worth spending time defining a good set of categories, since they will help you organize the information on your site, they’ll help visitors find the information they’re looking for, and they’ll provide better search-engine results because your pages will be thematically organized.
Every category must have a Name, which is used in navigation, so it should be brief. If you have a hierarchy, the subcategories are generally seen in the context of the parent category, so the name does not need to replicate that information. For example, suppose you have a site about fruit, with a category for apples and a subcategory for Gravensteins. You would use simply “Gravenstein” for the name of the category.
Every category can optionally have a Description, which typically appears at the top of each Category page. This description is primarily to set context for human visitors.
There's a separate meta description that is seen by search robots. It is initialized to be the same as the regular description when the page is created, if nothing is entered for the meta description, so you can ignore it when first setting up your site, as long as you are entering regular descriptions.
You can also set the Page Title, which appears in the browser’s title bar and as headlines in search engine results. If you don't set this explicitly, the category name will be used, but that's rarely a good choice from an SEO perspective. The page title should stand along and be fully descriptive of the category, including parent category context, and include the primary keywords for which the page is being optimized. (For example, while the category name may be simply “Gravenstein”, for the page title you might use something like “Gravenstein Apples, their history, flavor, growing conditions, and nurseries where you can purchase them”)
You can also enter Keywords, which are not visible to site visitors and generally thought to be ignored by Google. They are, however, potentially used by Yahoo and MSN. Less important than Page Title and Description, but still worth filling in if you're doing a thorough SEO job.
There's two options you can select when creating or editing a category: Draft and Special. Usually you won't want either of them.
Checking Draft makes the category invisible. This is sometimes useful when you're just setting up your taxonomy, or making major additions, and you want to get some categories set up but not make them publicly visible.
Checking Special identifies the category as one that is not part of the Knowledgebase. Use it when you have a category you are using for specific pages, such as a list of clients or press clippings, and that you don't want included in the "resources" part of the site.
Item Types determine what information is stored (i.e., what fields are available for data entry), and how it is displayed.
You can create custom item types to store any kind of information. For example, if you’re publishing a design portfolio, you might create a “Project” item type, with fields for project name, project description, client name, date completed, and a link.
If you’re building an information portal or organizing a set of resource links, the standard item types that come with the Webvanta system will generally suffice. Some of the standard item types have special behaviors. For example:
Other item types provided as part of a standard Webvanta site include fields for the URL, title, author, and description, and are distinguished only by their names. Examples include Web Articles, Web Sites, Blogs, and Podcasts. You can define as many versions of this generic type as you’d like, with different names, which helps segment your information for your users. For example, you may want types such as magazines, software, research, companies, agencies, or documentation.
Note that, unlike categories, for which each item can have any number, each item must have exactly one item type.
Custom types can be created with any desired metadata fields. You can use any of the standard item fields, optionally renaming them, and add as many additional fields as you’d like. See Creating Custom Item Types.