I recommend: http://en.wikipedia.org/wiki/Database_normalization
There are examples for every normalization form. This should help you think of what aspects you want to capture and how to relate to one another. Teddy On 1/12/07, Scott Weikert <[EMAIL PROTECTED]> wrote: > > You might consider a table that basically is one row per interaction. > > You'd have the seller's account ID, the interested party's account ID, > the ID of the item in question. A field with an "interaction type" value > - different codes for what's going on. Maybe a currency field for the > value in question - i.e. the price if buying outright, or an offer price > if the buyer is trying to haggle, and then the seller's counter offer > price should he respond. > > So something like: > > TTransaction > TransactionID (int identity PK) > ItemID (int FK on item table) > SellerUserID (int FK on user table) > BuyerUserID (int FK on user table) > CurrentPrice (currency/money data type) > InteractionType (could be int with FK to a table with the various > interaction types listed, or just a simple code with no extra table) > Timestamp (date/time, autopopulated) > > You could then pull all the appropriate records at any time and list out > the history of the transaction. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Create robust enterprise, web RIAs. Upgrade & integrate Adobe Coldfusion MX7 with Flex 2 http://ad.doubleclick.net/clk;56760587;14748456;a?http://www.adobe.com/products/coldfusion/flex2/?sdid=LVNU Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:266407 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
