Help with naming a table

[Stuart Taylor]

Hi,

I was not sure where to post this.

I would like some help with the name of one of my tables.

I have a stock database that stores the data relating to an item being loaned / consigned or purchased and the moved around, possibly consigned to others and eventually sold or returned to the original supplier if unsold for an extended period of time.

Until now it has been fine to store this data on the record of the stock item, but i now have to create a secondary database to store this information as the sold items have begun to be re-purchased and sold on again. (I now have a 1 to many relationship between item and this information)

I just can not decide what to call the secondary table. Is there an industry standard name for this kind of table in this kind of structure.

So far i have considered:

Session - (but that seems to short)

Stock_Card - (but that seems too vague)

Sales_Card - (but that seems untrue as it also deals with acquisitions and can be used on other databases in which the context becomes strange)

Deal - but that seems wierd

Transaction - (confusing and not really true)

Stock_History (the context is wrong for current items)

Stock_Log (it seems more important than this)

Stock_Record (again confusing)

I would also like my user to have a vague idea what this is too.

Please post any other alternatives ... even if its not perfect it could get my little grey cells going... this may seem unimportant but i really need help on it ... its like the final part of a Jigsaw.

I usually find that in this situation the reason i am having problems naming a table is because the table structure is wrong... and i really think im right this time.

best

Stuart

[Singlequanta]

Hi Stu;

As i was reading through your post, and before i got to the descriptions of names you had already nixed.... i immediately thought "transaction"

I think if you got five developers around a table (pardon the pun) you would get seven answers (because two are related --- ohh i kill me)

How about Tbl.action

or Tbl.stock.action

Just a couple of suggestions

Steve

[comment]

'Transactions' would be my choice too. I might consider 'Contracts', but that requires renaming the Contacts table.

[Stuart Taylor]

Hi Singlequanta and Comment,

Thanks so much for your replies.

"Transaction" seems like the majority vote.

I suppose i was worried:

a) because in my mind i considered a transaction is between party "A" and party "B"

"A" the seller and "B" the buyer

So the senario is as follows:

I but a table from IKEA ("A" is IKEA and "B" is Me)

That is one transaction

Later I sell the table to my Brother ("A" is me and "B" is my Brother)

This is another transaction

But in my data model it gets really scary.

"A" is the IKEA

"B" is Me

"C" is My Brother

"D" is My Brothers Friend

The following senarios can occur

I Buy a table with the intention of selling it to my brother

So this is infact 2 transactions

1. Ikea Sells it, I buy it

2. I sell it, My brother buys it

1. I Loan it from IKEA on approval, If my brother hates it, it is returned and the transaction is complete.

1. Ikea Sells it, I buy it

2. I Loan it to my brother with the intention that he will sell it to his friend.

3. His friend buys it and pays my brother.

4. My brother pays me.

5. I send it to his friend and the transaction is complete.

1. Ikea Sells it, I buy it

2. I Loan it to my brother with the intention that he will sell it to his friend.

3. His friend buys it and pays Me.

4. I pay my brother a comission.

5. I send it to his friend and the transaction is complete.

1. After i have sold it to my brother he later sells it back to me

2. I sell it directly to his friend

There is more but you get the picture...

I suppose it is still a transaction but my record holds the information about multiple transactions so rationally the transactions themselves should be in a seperate transactions table and the table in question should sit between the Stock and the Transactions

Stock > "This Table" > Transactions

or may be it should be

Stock > Stock_Transaction > Transaction

or

Stock > Transaction > Transaction_Item

(but then the Transaction_Item is infact the Transaction.)

Still not sure any of these quite fit.

This is what i am rangling with and i suppose it is getting clearer but im not sure if i am quite there yet.

Is this clear?

Any thoughts?

Thanks again

Best Stuart

[comment]

Whoa, back up a bit. First of all, each transaction needs a type - e.g. Ownership/Loan/Lease. Next, intentions are not transactions. Third, payments are transactions of a class of their own (if you need to track them in detail, they may merit a dedicated table).

There is also the question of point of view: is this solution tracking YOUR assets, or is it tracking certain ASSETS, no matter how far they end up (so you should properly record the fact that IKEA manufactured the table in the first place)?

[Stuart Taylor]

Just a quick thanks to comment for assisting with this as i now have the answer to this question.

The model i presented here did not properly reflect my true solution model, and the answer was actually industry specific, so will not be useful to the community as a whole.

Thanks again

Stuart