I'd read up on some normalisation techniques. Check out something called 3rd normal form, or if your feeling tricky BCNF (Boyce-Codd Norman form).

In short, group things by concepts. For example: 
create table books (
                     cat_id   number,
                     pages_no number,
                     author   varchar
                    );
create table categories (
                         cat_id  <insert fav db sequence ref here>,
                         cat_desc varchar
                         );
                     
insert into categories(1,computers-general);
insert into categories(2,computers-programming);

[download]
Each concept table (ala books) would have all the attributes of the concept. (for this example we're looking at pages_no, author). You could then create a foreign key constraint to categories via cat_id.

Using a foreign key constraint you cannot have any illegal (meaning any cat_id has to be in the categories table) categories in your concept (books) table. The advantage of this is it keeps the integrity of your data, the disadvantage is it can be a pain sometimes, but well worth the effort IMHO.

If you use your RDBMS's version of a sequence (and create any _id's as a primary key) you wont have any trouble with duplicate _id's, as a primary key is by definition unique, and a sequence is an ever incrementing value.

As mentioned above, long wide tables are not very performant, and take up lots on unnecessary space as they tend to be sparce (ie not every field in the tuple is populated). If you go for narrow dense (ie, every field in the tuple is populated) you'll get better optimisation from your database.

Make sure you think about indexes as well. Indexes should be on primary keys at a minumum, and should be on a different physical device to your tables (if you have the hardware). In fact, if youre going hardcore, think about different disks for the os, the database software, the tables, and indexes.

If you dont have too much data and the transaction rate is not high one disk is prolly enuff for everything.. ;-)

Disclaimer
The table structure assummes you've got the same list of 'attributes' for each concept. ie every book has pages, and an auther, regardless of if its a programming book, or a book on gardening.

Alternatively, if you've got lots of concepts and shared attributes, (ie the server, workstation type of thing) perhaps you should look at something like LDAP or a multidimensional database that caters for sparcity in your data.

In reply to Re: database design issue: one big table vs hundred of smaller tables by Ryszard
in thread database design issue: one big table vs hundred of smaller tables by AltBlue

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.