Principle of Orthogonal Design

#1

I was wondering what your current stances towards the principle of
current design is cdt - info about the POOD is actually pretty sparse
on google, which has not helped my own understanding. I gather that
Date has realigned his opinion - although what to I know not - and
that Darwen rejected the original POOD paper outright given that
McGovern posits that:

R1 { X INTEGER, Y INTEGER }
R2 { A INTEGER, B INTEGER }

violates the principle, whatever the relations' attribute names.
Instinctively it does seem rather odd that a predicates such as:

* on Day:X the shop had noCustomers:Y
* on Roll:A, the dice showed the Number:B

cannot share the same database. Have I interpreted the debate
correctly? Any insights or corrections are, as ever, appreciated -
POOD is certainly thought provoking, and the concept that an update
need not require specifcation of a table name is an interesting one.

#2

On 9 jan, 02:51, JOG <j... (AT) cs (DOT) nott.ac.uk> wrote:

Quote:

I was wondering what your current stances towards the principle of
current design is cdt - info about the POOD is actually pretty sparse
on google, which has not helped my own understanding. I gather that
Date has realigned his opinion - although what to I know not - and
that Darwen rejected the original POOD paper outright given that
McGovern posits that:

R1 { X INTEGER, Y INTEGER }
R2 { A INTEGER, B INTEGER }

violates the principle, whatever the relations' attribute names.
Instinctively it does seem rather odd that a predicates such as:

* on Day:X the shop had noCustomers:Y
* on Roll:A, the dice showed the Number:B

cannot share the same database. Have I interpreted the debate
correctly? Any insights or corrections are, as ever, appreciated -
POOD is certainly thought provoking, and the concept that an update
need not require specifcation of a table name is an interesting one.

My understanding is that the debate centers around typing.

Date advocates strong typing: ie X is of type "shop number" and A is a
"roll number", both represent different aspects of the UOD so they
have a different type (I disregard subtyping here for simplicity),
*even if* the actual underlying representations (e.g. natural numbers)
would be the same. Having different types, means the type engine can
distinguish them.

DM Unseen

#3

On 9 jan, 02:51, JOG <j... (AT) cs (DOT) nott.ac.uk> wrote:

Quote:

I was wondering what your current stances towards the principle of
current design is cdt - info about the POOD is actually pretty sparse
on google, which has not helped my own understanding. I gather that
Date has realigned his opinion - although what to I know not - and
that Darwen rejected the original POOD paper outright given that
McGovern posits that:

R1 { X INTEGER, Y INTEGER }
R2 { A INTEGER, B INTEGER }

violates the principle, whatever the relations' attribute names.
Instinctively it does seem rather odd that a predicates such as:

* on Day:X the shop had noCustomers:Y
* on Roll:A, the dice showed the Number:B

cannot share the same database. Have I interpreted the debate
correctly? Any insights or corrections are, as ever, appreciated -
POOD is certainly thought provoking, and the concept that an update
need not require specifcation of a table name is an interesting one.

My understanding is that the debate centers around typing.

Date advocates strong typing: ie X is of type "shop number" and A is a
"roll number", both represent different aspects of the UOD so they
have a different type (I disregard subtyping here for simplicity),
*even if* the actual underlying representations (e.g. natural numbers)
would be the same. Having different types, means the type engine can
distinguish them.

DM Unseen

#4

On 9 jan, 02:51, JOG <j... (AT) cs (DOT) nott.ac.uk> wrote:

Quote:

I was wondering what your current stances towards the principle of
current design is cdt - info about the POOD is actually pretty sparse
on google, which has not helped my own understanding. I gather that
Date has realigned his opinion - although what to I know not - and
that Darwen rejected the original POOD paper outright given that
McGovern posits that:

R1 { X INTEGER, Y INTEGER }
R2 { A INTEGER, B INTEGER }

violates the principle, whatever the relations' attribute names.
Instinctively it does seem rather odd that a predicates such as:

* on Day:X the shop had noCustomers:Y
* on Roll:A, the dice showed the Number:B

cannot share the same database. Have I interpreted the debate
correctly? Any insights or corrections are, as ever, appreciated -
POOD is certainly thought provoking, and the concept that an update
need not require specifcation of a table name is an interesting one.

My understanding is that the debate centers around typing.

Date advocates strong typing: ie X is of type "shop number" and A is a
"roll number", both represent different aspects of the UOD so they
have a different type (I disregard subtyping here for simplicity),
*even if* the actual underlying representations (e.g. natural numbers)
would be the same. Having different types, means the type engine can
distinguish them.

DM Unseen

#5

On 9 jan, 02:51, JOG <j... (AT) cs (DOT) nott.ac.uk> wrote:

Quote:

I was wondering what your current stances towards the principle of
current design is cdt - info about the POOD is actually pretty sparse
on google, which has not helped my own understanding. I gather that
Date has realigned his opinion - although what to I know not - and
that Darwen rejected the original POOD paper outright given that
McGovern posits that:

R1 { X INTEGER, Y INTEGER }
R2 { A INTEGER, B INTEGER }

violates the principle, whatever the relations' attribute names.
Instinctively it does seem rather odd that a predicates such as:

* on Day:X the shop had noCustomers:Y
* on Roll:A, the dice showed the Number:B

cannot share the same database. Have I interpreted the debate
correctly? Any insights or corrections are, as ever, appreciated -
POOD is certainly thought provoking, and the concept that an update
need not require specifcation of a table name is an interesting one.

My understanding is that the debate centers around typing.

Date advocates strong typing: ie X is of type "shop number" and A is a
"roll number", both represent different aspects of the UOD so they
have a different type (I disregard subtyping here for simplicity),
*even if* the actual underlying representations (e.g. natural numbers)
would be the same. Having different types, means the type engine can
distinguish them.

DM Unseen

#6

On 9 jan, 02:51, JOG <j... (AT) cs (DOT) nott.ac.uk> wrote:

Quote:

I was wondering what your current stances towards the principle of
current design is cdt - info about the POOD is actually pretty sparse
on google, which has not helped my own understanding. I gather that
Date has realigned his opinion - although what to I know not - and
that Darwen rejected the original POOD paper outright given that
McGovern posits that:

R1 { X INTEGER, Y INTEGER }
R2 { A INTEGER, B INTEGER }

violates the principle, whatever the relations' attribute names.
Instinctively it does seem rather odd that a predicates such as:

* on Day:X the shop had noCustomers:Y
* on Roll:A, the dice showed the Number:B

cannot share the same database. Have I interpreted the debate
correctly? Any insights or corrections are, as ever, appreciated -
POOD is certainly thought provoking, and the concept that an update
need not require specifcation of a table name is an interesting one.

My understanding is that the debate centers around typing.

Date advocates strong typing: ie X is of type "shop number" and A is a
"roll number", both represent different aspects of the UOD so they
have a different type (I disregard subtyping here for simplicity),
*even if* the actual underlying representations (e.g. natural numbers)
would be the same. Having different types, means the type engine can
distinguish them.

DM Unseen

#7

On 9 jan, 02:51, JOG <j... (AT) cs (DOT) nott.ac.uk> wrote:

Quote:

I was wondering what your current stances towards the principle of
current design is cdt - info about the POOD is actually pretty sparse
on google, which has not helped my own understanding. I gather that
Date has realigned his opinion - although what to I know not - and
that Darwen rejected the original POOD paper outright given that
McGovern posits that:

R1 { X INTEGER, Y INTEGER }
R2 { A INTEGER, B INTEGER }

violates the principle, whatever the relations' attribute names.
Instinctively it does seem rather odd that a predicates such as:

* on Day:X the shop had noCustomers:Y
* on Roll:A, the dice showed the Number:B

cannot share the same database. Have I interpreted the debate
correctly? Any insights or corrections are, as ever, appreciated -
POOD is certainly thought provoking, and the concept that an update
need not require specifcation of a table name is an interesting one.

My understanding is that the debate centers around typing.

Date advocates strong typing: ie X is of type "shop number" and A is a
"roll number", both represent different aspects of the UOD so they
have a different type (I disregard subtyping here for simplicity),
*even if* the actual underlying representations (e.g. natural numbers)
would be the same. Having different types, means the type engine can
distinguish them.

DM Unseen

#8

On 9 jan, 02:51, JOG <j... (AT) cs (DOT) nott.ac.uk> wrote:

Quote:

I was wondering what your current stances towards the principle of
current design is cdt - info about the POOD is actually pretty sparse
on google, which has not helped my own understanding. I gather that
Date has realigned his opinion - although what to I know not - and
that Darwen rejected the original POOD paper outright given that
McGovern posits that:

R1 { X INTEGER, Y INTEGER }
R2 { A INTEGER, B INTEGER }

violates the principle, whatever the relations' attribute names.
Instinctively it does seem rather odd that a predicates such as:

* on Day:X the shop had noCustomers:Y
* on Roll:A, the dice showed the Number:B

cannot share the same database. Have I interpreted the debate
correctly? Any insights or corrections are, as ever, appreciated -
POOD is certainly thought provoking, and the concept that an update
need not require specifcation of a table name is an interesting one.

My understanding is that the debate centers around typing.

Date advocates strong typing: ie X is of type "shop number" and A is a
"roll number", both represent different aspects of the UOD so they
have a different type (I disregard subtyping here for simplicity),
*even if* the actual underlying representations (e.g. natural numbers)
would be the same. Having different types, means the type engine can
distinguish them.

DM Unseen

#9

On 9 jan, 02:51, JOG <j... (AT) cs (DOT) nott.ac.uk> wrote:

Quote:

I was wondering what your current stances towards the principle of
current design is cdt - info about the POOD is actually pretty sparse
on google, which has not helped my own understanding. I gather that
Date has realigned his opinion - although what to I know not - and
that Darwen rejected the original POOD paper outright given that
McGovern posits that:

R1 { X INTEGER, Y INTEGER }
R2 { A INTEGER, B INTEGER }

violates the principle, whatever the relations' attribute names.
Instinctively it does seem rather odd that a predicates such as:

* on Day:X the shop had noCustomers:Y
* on Roll:A, the dice showed the Number:B

cannot share the same database. Have I interpreted the debate
correctly? Any insights or corrections are, as ever, appreciated -
POOD is certainly thought provoking, and the concept that an update
need not require specifcation of a table name is an interesting one.

My understanding is that the debate centers around typing.

Date advocates strong typing: ie X is of type "shop number" and A is a
"roll number", both represent different aspects of the UOD so they
have a different type (I disregard subtyping here for simplicity),
*even if* the actual underlying representations (e.g. natural numbers)
would be the same. Having different types, means the type engine can
distinguish them.

DM Unseen

#10

On Jan 8, 6:51*pm, JOG <j... (AT) cs (DOT) nott.ac.uk> wrote:

Quote:

I was wondering what your current stances towards the principle of
current design is cdt - info about the POOD is actually pretty sparse
on google, which has not helped my own understanding. I gather that
Date has realigned his opinion - although what to I know not - and
that Darwen rejected the original POOD paper outright given that
McGovern posits that:

R1 { X INTEGER, Y INTEGER }
R2 { A INTEGER, B INTEGER }

violates the principle, whatever the relations' attribute names.
Instinctively it does seem rather odd that a predicates such as:

* on Day:X the shop had noCustomers:Y
* on Roll:A, the dice showed the Number:B

cannot share the same database. Have I interpreted the debate
correctly? Any insights or corrections are, as ever, appreciated -
POOD is certainly thought provoking, and the concept that an update
need not require specifcation of a table name is an interesting one.

I'm sure you've run across this exchange (since it seems to be the
source of the example cited), but: http://www.dbdebunk.com/page/page/3010532..htm

From Pascal, addressing McGovern: "It is quite possible that the
difference between you and CJD stems from the difference between his
header/body view of a relation, which you (and recently me) do not
espouse, and therefore differing definitions of a tuple."

Regarding the example you gave above, it seems the disagreement may be
stemming, as you indicate, from a confusion over whether the types for
the relations' attributes are declared from a syntactic domain or from
a semantic domain. The example looks, to me, like the former. I would
expect if it were the latter, domain names would more closely reflect
that.

TroyK