sql server programming: Don't simply create tables - design a solution.

First of all, get a good understanding of the issue at hand. What ever it
is, you need to understand the basic principles of the business logic.

Identify individual informational entities (subjects, objects, properties),
identify similarities between the entities.

Identify how the entities are related to each-other.

In your specific case you could start by analyzing what you *actually have*,
then try to reverse-engineer what you *really should have*.

Unfortunatelly data modelling cannot be learned in news groups. We can,
however, help you get a good start at it. Maybe you can post the table DDL
and in a few words explain the business requirement behind your current
design.


ML

---

A couple of good resources that I have referenced are

http://www.utexas.edu/its/windows/database/datamodeling/rm/rm7.html

(which looks like the work of C.J. Date)

and

http://en.wikipedia.org/wiki/Database_normalization

An un-normalized database is typically easy to get information out of (a
single SELECT statement with no joins), but very difficult to put information
into or to update information (lots of UPDATES or INSERTS just to change
information about a single thing). A normalized database is harder to get
information out of (joins), but much easier to update in a consistent way.

A good place to start is building a prepositional statement about the things
you wish to describe in your relation (table). For example, if I wanted to
build a relation describing my friends, I'd state with this statement:

A have a friend, with the name ___________, is ______ years old, and has
friends for me for ______ years.

The statement should avoid repeating conditions that could not apply to all
friends, like

and they did this ______________ and this _________ and this __________

--



[quoted text, click to view]