Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.databases.ms-sqlserver > #1689 > unrolled thread

Is it really any point to have a relation in this example

Started by"Tony Johansson" <johansson.andersson@telia.com>
First post2014-02-19 14:53 +0100
Last post2014-02-20 09:49 -0800
Articles 4 — 4 participants

Back to article view | Back to comp.databases.ms-sqlserver


Contents

  Is it really any point to have a relation in this example "Tony Johansson" <johansson.andersson@telia.com> - 2014-02-19 14:53 +0100
    Re: Is it really any point to have a relation in this example Erland Sommarskog <esquel@sommarskog.se> - 2014-02-19 21:13 +0100
      Re: Is it really any point to have a relation in this example rja.carnegie@gmail.com - 2014-02-19 13:43 -0800
    Re: Is it really any point to have a relation in this example Gene Wirchenko <genew@telus.net> - 2014-02-20 09:49 -0800

#1689 — Is it really any point to have a relation in this example

From"Tony Johansson" <johansson.andersson@telia.com>
Date2014-02-19 14:53 +0100
SubjectIs it really any point to have a relation in this example
Message-ID<le2d1u$ea1$1@dont-email.me>
Assume that we have many products for example flowers but we have only one 
warehounse where we plant and store
these flowers.
So one Inventory has many flowers but one flower can only exist in one 
warehouse.

In this example is it any point to create a separate table for warehouse.
Is it just as good to store information such as current quantity for each 
flower that exist in the product table.

I find it funny to have a table warehouse with just an Id without any more 
fields.

//Tony 

[toc] | [next] | [standalone]


#1690

FromErland Sommarskog <esquel@sommarskog.se>
Date2014-02-19 21:13 +0100
Message-ID<XnsA2D9D7EC34F93Yazorman@127.0.0.1>
In reply to#1689
Tony Johansson (johansson.andersson@telia.com) writes:
> In this example is it any point to create a separate table for warehouse.
> Is it just as good to store information such as current quantity for each 
> flower that exist in the product table.
> 
> I find it funny to have a table warehouse with just an Id without any more 
> fields.
 
Most likely the warehouse have other attributes like name, address, etc.

But even we assume something that only has an ID, which in this case must 
be a natural key, it should probably be a separate table, as a foreign-key
constraint to this table helps to restrict the possible values in the 
column. 


-- 
Erland Sommarskog, Stockholm, esquel@sommarskog.se

[toc] | [prev] | [next] | [standalone]


#1691

Fromrja.carnegie@gmail.com
Date2014-02-19 13:43 -0800
Message-ID<cbe80d14-a145-41f9-bcee-1662a30d1915@googlegroups.com>
In reply to#1690
On Wednesday, 19 February 2014 20:13:33 UTC, Erland Sommarskog  wrote:
> Tony Johansson (johansson.andersson@telia.com) writes:
> > In this example is it any point to create a separate table for warehouse.
> > Is it just as good to store information such as current quantity for each 
> > flower that exist in the product table.
> > 
> > I find it funny to have a table warehouse with just an Id without any more 
> > fields.
> 
> Most likely the warehouse have other attributes like name, address, etc.
> 
> But even we assume something that only has an ID, which in this case must 
> be a natural key, it should probably be a separate table, as a foreign-key
> constraint to this table helps to restrict the possible values in the 
> column. 

If it's a book exercise, maybe they would have put in other columns,
as you say, but they didn't bother to do it.

If the business expands, it may have more than one warehouse
(or greenhouse?)  I suppose that until then, if there is only
one, then you all know its address.  But your database design
is ready, except for not having those columns.

We've also used a table with only one row and one column to hold 
an ID that we don't want to have merely as a table's automatic 
identity, although this may be unwise.  I think it was about 
putting an exclusive lock on that until a transaction was complete.

[toc] | [prev] | [next] | [standalone]


#1692

FromGene Wirchenko <genew@telus.net>
Date2014-02-20 09:49 -0800
Message-ID<pofcg995jds15hnfds3fu341d2jtnlq0i2@4ax.com>
In reply to#1689
On Wed, 19 Feb 2014 14:53:51 +0100, "Tony Johansson"
<johansson.andersson@telia.com> wrote:

>Assume that we have many products for example flowers but we have only one 
>warehounse where we plant and store
>these flowers.

     This can be read as one warehouse in total and one for each type.
If the former, you might not need a warehouse column.

>So one Inventory has many flowers but one flower can only exist in one 
>warehouse.
>
>In this example is it any point to create a separate table for warehouse.
>Is it just as good to store information such as current quantity for each 
>flower that exist in the product table.
>
>I find it funny to have a table warehouse with just an Id without any more 
>fields.

  1) It makes the validation not be hard-coded.  If you add another
warehouse, you can just insert to the table.

  2) You can add warehouse columns, and I would be unlikely to create
a table with just a PK.  I would, at least, have a description.  As
time goes on, you might decide that there are other things about the
warehouse that you wish to track.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [standalone]


Back to top | Article view | comp.databases.ms-sqlserver


csiph-web