Re: A newbie paradox: is this a PK-FK (relationship) problem, or programming problem?

From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Sun, 23 Dec 2007 14:34:32 +0100
Message-ID: <476e6334$0$85787$e4fe514c_at_news.xs4all.nl>


Somehow the OP did not make it to the NNTP server.

David Portas wrote:

> raylopez99 wrote: 

>> I'm getting the hang of database architecture design I think, along
>> with easy to code, drag-and-drop Access 2003 forms programming--great
>> front end.

Divide and conquer.

When you write a piece of text, you think about what you are going to say before you lose yourself in formatting and layout difficulties. If you don't know what you are going to say, no amount of layout work wil rescue your piece. Same here. Think of what you want to be able to get out of your database without thinking of tables, forms or programming language constructs. If you cannot get that right, your database will suck, whatever high standard of quality your implementation tools are.

>> But I have a question about a form involving three tables--and I'm not
>> sure if this is a programming question or a database architecture
>> question, hence the crosspost.
>>
>> I have three tables to model a stock portfolio (buying and selling by
>> a single person having numerous accounts): Stock_Accounts (plural),
>> in a single table (red flag), which belong to a single individual,
>> then a stock table, Stocks, listing all the stocks owned by the
>> individual, then a stock transaction table, Stock_transactions,
>> listing all the buying and selling within the various accounts. FYI
>> the table "Stock_transactions" is a subform (depends on a parent) of
>> "Stocks", while Stocks is a subform (depends on a parent) of
>> "Stock_Accounts", meaning there's a one-to-many relationship from form
>> to subform.
>>
>> Everything works fine: everything is in first normal form with
>> primary and foreign keys, but one nagging problem: in the rare event
>> that this person owns the same stock in two different accounts, the
>> way I set up the tables will not allow the person to enter the same
>> symbol.

In order to give this problem clear boundaries or even make it completely dissappear, first you do some work to state what you want to get out of your database (an essential part of the requirements) in isolation i.e. without the implementation aspects.

Do not ask yourself what you should store, but ask yourself what you want to get out of it: your /information need/. Work from there.

>> Quick workaround: require a different symbol, say "IBM2"

Around what exactly?

...

>> Any thoughts?

> Please do yourself a favour and study a decent book on design theory. People 
> reading what you wrote probably have little chance of correctly 
> understanding what you mean and even less chance of guessing the right 
> solution. If guesswork is more valuable to you than your own ability to 
> solve the problem then you certainly need more help than you can get in 
> these newsgroups.

And that.

--
What you see depends on where you stand.
Received on Sun Dec 23 2007 - 14:34:32 CET

Original text of this message