I have created a database, what is data structure and relationship?

Question

I have a database.
I have 4 tables.
Employee table
Project Table
Sales order table
Customer table
================================
SalesOrderId is unique
EmploeeId Is unique
CustomerID is unique
ProjectId is unique
What would be the relationship for these tables?
Should I create 5th table that has salesOrderID and ProjectID and the primary key is the combination of salesOrderId and ProjectId?
Is the whole process correct?
Regards,
GGGGGNNNNN
GGGGGNNNNN

Answer 1

. IDENTITY is never part of a valid data model and certainly not  a key.
Identity can be a primary key, can't it be?
It can be. What Celko is trying to say is that IDENTITY is not a good choice for a key. Unfortunately, he is sitting in an ivory tower and does not have very good ideas of real-world systems.
More generally, when you design a database, you may decide to introduce a
surrogate key in your tables. That is, a key which is not drawn from the data, but just generated in the system. Ideally, you should still have a real key in the data. The reason you would use the surrogate key is that the real key may be difficult to
work with, for instance it is a long string or consists of many components.
In practice, far from all entities can (easily) be described with a natural key, why the surrogate key is the only one you will have. However, you should always strive for finding a natural key, and not slap on IDENTITY as a matter of routine. For instance,
say that you have a table called ProductCategories which defines which categories a product belongs to, that table should have a two-column of ProductID and CategoryID, and there should not be any IDENTITY column in that table.
Generally, when I see people post a table table definition with an IDENTITY column and all other columns nullable, I know that they have not put in enough thought to their data-modelling.
And, no, surrogate key != IDENTITY. IDENTITY is one way to implement surrogate keys, but you can also use guids, sequences (in SQL 2012 and up) or roll your own. Since IDENTITY incurs some limitations, you may want to avoid it. Sequences are cleaner and
you don't have the same limitations. And rolling your own works very well, as long as you don't expect a high level of parallel inserts, which is what IDENTITY and sequences really are aimed for.
We never put audit data in the table under audit. It is not just silly, it is illegal.
What do you mean?
Again, Celko is out of touch with reality. It may be illegal in Texas where he is sitting but not where you and I are sitting. It may also be illegal if the auditing is made for legal reasons. Obviously, if the auditing is mainly done to facilitate troubleshooting,
your local law-enforcing authorities could not care less.
Erland Sommarskog, SQL Server MVP, [email protected]