good table design...

[Erland Sommarskog]

Re: good table design...

David Portas (REMOVE_BEFORE_ REPLYING_dporta s@acm.org) writes:[color=blue]
> Identifying the keys is an essential part of the process of designing the
> logical model anyway.[/color]

And I say it again: that identification process could result in that you
realize that there is no real-world key which meets the requirements of the
relational model.

--
Erland Sommarskog, SQL Server MVP, esquel@sommarsk og.se

Books Online for SQL Server SP3 at

http://www.microsoft.com/sql/techinfo/productdoc/2000/books.asp

[David Portas]

Re: good table design...

Logically impossible. Any relation {A,B,C} represents a fact. If the fact is
representative of some quantity that you need to represent N times then you
can always add another attribute to represent the count of N: {A,B,C,n}. You
can therefore always record any set of facts without violating any key. In a
table that doesn't represent quantitative facts there is obviously no
problem at all - each fact need only be recorded exactly once.

The idea that a particular schema design is a consequence of Business
Process is a common falacy I believe. A relational schema *models* a
business process it is not *determined* by it. There are always choices to
be made in the design and business constraints are not an excuse for poor
design.

--
David Portas
SQL Server MVP
--

[Erland Sommarskog]

Re: good table design...

David Portas (REMOVE_BEFORE_ REPLYING_dporta s@acm.org) writes:[color=blue]
> Logically impossible. Any relation {A,B,C} represents a fact. If the
> fact is representative of some quantity that you need to represent N
> times then you can always add another attribute to represent the count
> of N: {A,B,C,n}. You can therefore always record any set of facts
> without violating any key. In a table that doesn't represent
> quantitative facts there is obviously no problem at all - each fact need
> only be recorded exactly once.[/color]

Yes, you might be able to add another attribute, but in the end you have an
attribute list which is long as the universe, and which have no practical
usage, and only serves to make the system more difficult to use and less
effecient.
[color=blue]
> The idea that a particular schema design is a consequence of Business
> Process is a common falacy I believe. A relational schema *models* a
> business process it is not *determined* by it. There are always choices to
> be made in the design and business constraints are not an excuse for poor
> design.[/color]

Real-world systems are built to solve business problems, not to appease
the ideas of relational theory. Just as always using an surrogate key is
poor design, it is also poor design to always define a natural key.

--
Erland Sommarskog, SQL Server MVP, esquel@sommarsk og.se

Books Online for SQL Server SP3 at

http://www.microsoft.com/sql/techinfo/productdoc/2000/books.asp

[cwepema]

Re: good table design...

toedipper wrote:[color=blue]
> Thanks for your reply.
>
> Totally of topic but what does 'sic' mean? I see this all over the place
> both on the web and in print.
>
> Thanks,
>
> TD.
>
>
> "--CELKO--" <jcelko212@eart hlink.net> wrote in message
> news:18c7b3c2.0 411251010.13393 2be@posting.goo gle.com...
>[color=green][color=darkred]
>>>>For the table design I am proposing a single column table with a[/color]
>>
>>field [sic] name called vehicle_type and this will contain the vehicle
>>type... Is this ok? <<
>>
>>Sure, if you remember to make the one column the primary key. It is
>>weird just hanging out there in space without anything in the schema,
>>but it is legal. And fields are not anything like column.[/color]
>
>
>[/color]
According to the dictionairy it (sic) means:
1. To set upon; attack.
2. To urge or incite to hostile action; set: sicced the dogs on the
intruders.

In sms language it means "As I See". I think.
Regards Kees

[James Goodwin]

Re: good table design...

sic1
adv.
Thus; so. Used to indicate that a quoted passage, especially one
containing an error or unconventional spelling, has been retained in its
original form or written intentionally.

Regards,
Jim

"cwepema" <cwepema@presys .nl> wrote in message
news:ZuWzd.1231 4$Sb5.3040@news fe01.lga...[color=blue]
> toedipper wrote:[color=green]
> > Thanks for your reply.
> >
> > Totally of topic but what does 'sic' mean? I see this all over the[/color][/color]
place[color=blue][color=green]
> > both on the web and in print.
> >
> > Thanks,
> >
> > TD.
> >
> >
> > "--CELKO--" <jcelko212@eart hlink.net> wrote in message
> > news:18c7b3c2.0 411251010.13393 2be@posting.goo gle.com...
> >[color=darkred]
> >>>>For the table design I am proposing a single column table with a
> >>
> >>field [sic] name called vehicle_type and this will contain the vehicle
> >>type... Is this ok? <<
> >>
> >>Sure, if you remember to make the one column the primary key. It is
> >>weird just hanging out there in space without anything in the schema,
> >>but it is legal. And fields are not anything like column.[/color]
> >
> >
> >[/color]
> According to the dictionairy it (sic) means:
> 1. To set upon; attack.
> 2. To urge or incite to hostile action; set: sicced the dogs on the
> intruders.
>
> In sms language it means "As I See". I think.
> Regards Kees[/color]

[--CELKO--]

Re: good table design...

How do think that Fed Wire and the other banking networks handle their
transactions? It ain't GUIDs and IDENTITY columns; it is very
intelligent keys that can be verified.

[Pero Periæ]

Re: good table design...

tzutrfi8t797to0 zh9ð'0uzjhð+u'0
"toedipper" <send_rubbish_h ere734@hotmail. com> wrote in message
news:30mdqgF31v 3mtU1@uni-berlin.de...[color=blue]
> Hello,
>
> I am designing a table of vehicle types, nothing special, just a list of
> unique vehicle types such as truck, lorry, bike, motor bike, plane,
> tractor
> etc etc
>
> For the table design I am proposing a single column table with a field
> name
> called vehicle_type and this will contain the vehicle type.
>
> Sot it will be
>
> vehicle_type
> car
> bike
> tractor
> plane
> truck
> van
> blah
> blah
> blah
>
> Is this ok? Or is there a better way to do it?
>
> Thanks,
>
> td.
>
>
>[/color]