Laconic2 wrote:

internally as a certain number of "clock-ticks" since an "epoch".

Then the question reduces itself as to how to represent the
instance of time which is "midnight" - 2400 hours or 0000 hours?

NPL

--
"It is impossible to make anything foolproof
because fools are so ingenious"
- A. Bloch

"Ja Lar" <ingen (AT) mail (DOT) her> wrote



I don't have a formal definition. I was just picking up on the term as I
saw it used in this newsgroup.


But maybe this will help: when I tried to distinguish between the "naive
comparator" and the "intelligent comparator"
my point was precisely that the naive comparator compares representations,
while the intelligent comparator compares values. Maybe "aware comparator"
would have been better than "intelligent comparator"

Thus the question 2004.11.11.24.00 =? 2004.11.12.00.00 is "no" when you
compare the representations, but "yes" when you compare the values. This
is why engines that allow user defined datatypes require the definer to
supply the comparator.

I don't think this is very educative, and there's probably a better way to
say it. But this is the best I can come up with.

Ideally, there is a 1 for 1 homomorphism between representations and values.
When it isn't 1 for 1 it behooves us to normalize, if a given value has
more than one representation, and it really behooves us to disambiguate if
a single representation stands for more than one value. Does this settle
the matter?

"Laconic2" <laconic2 (AT) comcast (DOT) net> skrev i en meddelelse
news:xJCdnVoISasXiwjcRVn-gA (AT) comcast (DOT) com...
you.
(but I don't care if, or not, there is a 1-1 between value and
representation - I know no case where that's the case! Do you have an
example?)

The "matter" was: what is a "type engine". You defined it (loosely) as a
feature that returns a representation of a value (of the type).
That surprises me- I would expect that it created a value of the type, or
(better) created a new type (as in CREATE DOMAIN).
Is it not the latter you in fact refer to in your statement: "this is why
engines that allow user defined datatypes..."?
I.e.: "type engine" = "engine that allows user defined datatypes", rather
than "type engine" = "engine that returns representation of values"

But now we are _really_ far OT in this thread. I'm inclined to leave it
here.

True in general, but not when using the one-table schema provided by
Mr. Celko. Please show how the current RM solution can work if two
towns are named the same (ie change name of town c to a).

Nick Landsberg wrote:
I've heard people say "twenty-four hundred hours."
I've never heard anyone say "zero hundred hours."

Maybe 00:00 is "midnight am," and 24:00 is "midnight pm."

--
frosty

frosty wrote:

Normal usage, as far as I can recall, is the "2400 hours"

However, I am not (recently) familiar with usage for
"one minute past midnight" ... I used to know it as
"zero, zero hours and zero one minutes"

NPL

--
"It is impossible to make anything foolproof
because fools are so ingenious"
- A. Bloch

"Neo" <neo55592 (AT) hotmail (DOT) com> wrote

First of all, towns almost never change names. The two that come to mind in
the last 50 years in the U.S. are Tucumcari, NM to Truth or Consequences,
NM, and Levittown, NJ to Willingboro, NJ. Anyway, there are several ways,
depending on what you are modeling, but let's assume we are modeling U.S.
towns. The table would be thus:

town PK
state PK
main_postal_code PK
(Every town and city has a "main" post office. In Philadelphia, PA, which
has, I don't know, maybe 52 zip codes, the main post office is 19104 (there
is a 19101, 02, and 03, but they are not the "main" post office)). So, the
data for Philadlphia, PA would be:

Philadelphia PA 19104

Huh? New information just in? There's suddenly another Philadelphia in PA
(Happens a lot with Springfield. Many states have more than one.)

Add a row

Philadelphia PA 18952

What's that you say? The 19104 town name has changed to Neodelphia so as to
not confuse you? Well, first, you may want to capture the date this
occurred, so I would add a column (or two, depending)

start_date
end_date

So, now, we'd have data something like:

Philadelphia PA 19104 6/1/1682 11/12/2004
Neodelphia PA 19104 11/12/2004 12/31/2999

There is no problem, as much as you would like to have one to solve. And,
no- storing PA twice is not redundant. It is part of the PK, and being so,
helps to uniquely identify the town, so is therefore critical information.

"Alan" <not.me (AT) uhuh (DOT) rcn.com> wrote


Just as an aside, towns do not change their name at will. At least not in
my state. Cities and towns are creations of the state. Their charter names
them. To change the name of a town requires state approval.

This makes it possible, at least in theory, for New Mexico to prevent the
occurrence of two cities or towns named, "Roswell".

Thanks for demonstrating that Mr. Celko original schema does not
handle two towns with the same name without schema changes.

Storing any thing (ie PA) twice is redundant. On way to prove
redundancy is to change the second PA and see if data is corrupted
(without triggers/code to synchronize them). Also, if a property is
added to PA, will you add it the first PA, second PA, or both? I won't
be agruing the above point any further in this thread (unless you
bring out a new point) as it was already discussed at length in OT "A
Normalization Question".

On 13 Nov 2004 11:03:13 -0800, Neo wrote:

(snip)
Hi Neo,

A computer represents PA as a string of bits - either 16 or 32 bits on
most modern computers. If you store PA twice, you have the same string of
bits in two locations.

If you store PA once, you'll have to replace PA in the above rows with a
pointer to that location. A computer represents a pointer as a string of
bits - either 16 or 32 bits on most modern computers. So even if you store
PA once, you still end up with the same string of bits in two locations.


Changes to the data should reflect changes in the reality. If PA state
boundaries are changed at the same moment that Philadelphia is renamed to
Neodelphia, changing the second PA would in fact even be required.

Changing PA when the state boundaries don't change will of course trash
your data, regardless of how you store it and how many times you store it.
Even if I had just one row of data and then change PA to IL, it'll still
be faulty.


You are -once again- showing your total lack of comprehension of
normalization. If a propert is added to PA, it should be added in a
seperate table.

Best, Hugo
--

(Remove _NO_ and _SPAM_ to get my e-mail address)