Database Design Question !!

[Adam Knight]

I currently have an member registration application written in asp which
currently consists of :

1) tblMemberOrders
2) tblMembers.

I am seriously contemplating merging these two table into one table
(tblUser); to differentiate in the new
table which are orders and which are confirmed members a status field would
be employed.

Does anyone have any ideas as to the pro's and con's of this approach and
any personal recommendations.

AK

[William Tasso]

Adam Knight wrote:

> I currently have an member registration application written in asp
> which currently consists of :
>
> 1) tblMemberOrders
> 2) tblMembers.
>
> I am seriously contemplating merging these two table into one table
> (tblUser);

What benefit would you gain?

> to differentiate in the new
> table which are orders and which are confirmed members a status field
> would be employed.
>
> Does anyone have any ideas as to the pro's and con's of this approach

Without seeing the data model - it's an impossible task.

> and any personal recommendations.
>

Ensure you data is normalised.

--
William Tasso - [url]http://WilliamTasso.com[/url]

[Ken Schaefer]

Model your entities and relationships in an ER diagram.

Each Entity should be in its own table.

From the sound of the tables you already have, it seems that they should be
separate tables (members, and orders don't sound like the same type of
"thing").

That said, without some kind of information on *what* these entities are, I
don't think we can recommand anything. Keep you data normalised was a good
suggestion posted by William

Cheers
Ken

"Adam Knight" <aj.knight@optusnet.com.au> wrote in message
news:ePhK5hjYDHA.2344@TK2MSFTNGP09.phx.gbl...
: I currently have an member registration application written in asp which
: currently consists of :
:
: 1) tblMemberOrders
: 2) tblMembers.
:
: I am seriously contemplating merging these two table into one table
: (tblUser); to differentiate in the new
: table which are orders and which are confirmed members a status field
would
: be employed.
:
: Does anyone have any ideas as to the pro's and con's of this approach and
: any personal recommendations.
:
: AK
:
:

[Adam Knight]

This is what i am looking at doing:

The user entity will consist of :
cn.execute("CREATE TABLE Users (User_Id COUNTER CONSTRAINT PK_User PRIMARY KEY, User_Name TEXT(30) NULL,User_Password TEXT(30) NULL,

User_Agreement TEXT(15) NULL,User_Listed TEXT(15) NULL,User_Type TEXT(30) NULL), User_Status TEXT(30) NULL")



cn.execute("CREATE TABLE User_Contact (User_Contact_Id COUNTER CONSTRAINT PK_Contact PRIMARY KEY, User_Contact_Type TEXT(30) NULL,

User_Contact_First_Name TEXT(60) NULL, User_Contact_Last_Name TEXT(60) NULL, User_Contact_Phone TEXT(15) NULL, User_Contact_Fax TEXT(15) NULL,

User_Contact_Mobile TEXT(15) NULL, User_Contact_Email TEXT(60) NULL, User_Contact_Website TEXT(100) NULL, User_Contact_User INTEGER,

User_Contact_Business INTEGER)")




cn.execute("CREATE TABLE User_Location (User_Location_Id COUNTER CONSTRAINT PK_Location PRIMARY KEY, User_Location_Type TEXT(30) NULL,

User_Location_Street TEXT(60) NULL, User_Location_Suburb TEXT(30) NULL, User_Location_State TEXT(8) NULL, User_Location_Post_Code TEXT(6) NULL,

User_Location_User INTEGER,User_Location_Business INTEGER)")



The User_Status Field dictates whether the user in pending or confirmed.

Previously i had two tables practically identical which contained all the information above. Once a users membership was confirmed their
details were place in the second table.



AK