On Wed, 1 Oct 2008 14:10:39 -0700 (PDT), --CELKO-- wrote:

>>> Based on previous replies to similar questions, I expect Joe Celko to tell you to use a column active_date that stores the date (or even date and time) that the active status was achieved, and that is NULL if whatever is modeled in the table is not active. <<
>
>No, based on previous replies, you should have said I would advise a
>pair of columns to show duration of that status, more like this:
>
>CREATE TABLE Foobar
>(..
> foo_status CHAR(5) NOT NULL
> CHECK(foo_status IN (..)),
> start_date DATE NOT NULL,
> end_date DATE, -- null is current

Hi Joe,

True. You've got me there!

>>> (And he'll also blast you for using "field" instead of "column"). <<
>
>Yes. This is important if you are ever going to think in sets and not
>sequential files.

Trust me on this, Joe. It *IS* possible to use the terms "field" and
"record" and still think in sets.

"That which we call a rose, by amny other name would smell as sweet!"
-- Shakespeare, "Romeo and Juliet", 1594

>>> Of course, Joe will not care whether the business is actually interested at all in what time the widget became active. <<
>
>Can you think of a business that would not have such an interest when
>it involves a product or service they are libel for? Business is very
>temporal.

Who says that the original poster was modelling a product or service
they are libel for? Assumptions, my friend! They (together with good
intentions) pave the path to hell!

There are various situation where all information needed is whether some
FooBar is or is not active. To give just one example - when you have to
dispatch jobs to workers, you need a list of idle workers. You do not
need to know any history of when they were idle and when they were
active - you just need to send the task to an idle worker.

>>> Nor will he care that it might involve lots of extra work for the data entry department, maybe even severe changes in some business process, to track and enter this information (that the business doesn't even need). <<
>
>This usually involves adding a DEFAULT CURRENT_TIMESTAMP to a table
>declaration or a line in a stored procedure.

That does not one bit when someone flips the "active" status. A
DEFAULT doesn't do anything when you run an UPDATE.

>>> In fact, he'll also be blind to the fact that this will without any doubt result in fake dates being stored, as that's what always happens when some clowns from the IT department who are completely out of touch with the real work on the business floor dictate the storage of some uninteresting attribute. <<
>
>The time of an event for which the company is libel might not be
>considered an "uninteresting attribute" by management or the lawyers.

I think we already covered that. If the company were libel for the time
of the event, the table would already have been designed with a column
to store that time. Since it's not, we can safely assume that the
company isn't libel for said time (or, if you prefer to be cynical, that
the managers that pay the DBA's bills think they're not).

>Why would "fake dates" be stored?

Because that's what happens when idiots from the IT department add
mandatory attributes that the business never asked for. The data entry
people are presented a screen that demands some input that they can't
supply, so they just enter something and move on - after all, they got
their work to do!

>>> And when a few years down the road management invents a new business requirement that does involve tracking when the active state was reached, the poor chap tasked with the database will see this column, will of course assume that it holds the data required, and will then produce reports based on incorrect data. <<
>
>1) Why do you assume that if you record a fact (especially when the DB
>does it for you with CURRENT_DATE), it has to be wrong? Weird.

So you've never been in a situation where changes were entered in
advance, or after the fact?

>2) "Errors using inadequate data are much less than those using no
>data at all." --Charles Babbage

If Charles said that, he was wrong.

I think it'll be 20 years ago now that I took over maintenance for an
existing application (PL/1 on a mainframe, using an IMS/DB database;
aaah, the memories!). After a few days of studying the documentation and
comparing it to the actual source code, I knew of a way to greatly
improve the quality of the documentation in just a few minutes: I binned
all of the documentation! It was seriously outdated. The code had moved
on but the docs had not. If I had kept the documentation, I would have
wasted lots of my time, and run the risk of making incorrect changes by
relying on the outdated documentation. Binning the documentation ensured
that both I and all my successors should use the source as the only
trustworthy source of information, until finally budget was approved to
re-document the thing (which, of course, never happened).

>>> Wouldn't you much rather have a design with just the is_active column and no active_date, so that you know to tell upper management that this new requirement involves changes to the database and can only be tracked for new widgets? <<
>
>No, hell no! In the real world, new requirements almost always have a
>temporal component. See another posting of mine about the drinking
>age changing in the US. Before the laws changed, Sally was a
>perfectly bartender when I hired her at 18. The next week, I have to
>take her off the bar and put a wrist band on her (to mark underage
>servers). If I "flip her flag" without the history, I have destroyed
>information -- was I engaged in criminal activity with a minor or did
>I overpay her for the bartending she could not have been doing?

You get to pick your examples, I get to pick mine.

Imagine a DB app that calls a webservice to check address against postal
code (I believe you call that ZIP code). Since webservices are not 100%
reliable, a list of available webservices is kept in a table. When an
address has to be checked, one of them is called. If the call results in
an error or timeout, the webservice is marked as not in use, and another
webservice is called instead. Once or twice a month, an employee will
check webservices marked "not in use", find out if the problem is
permanent or temporal and mark the service as "in use" once a temporal
problem is resolved, or remove it completely if the problem is
permanent. Management decides not to store when exactly these services
started or stopped being in use, as they are just using some service
provided for free by some third parties.

Three months later, it turns out that one of the services used isn't
free after all, but requires a monthly fee. If I had followed your
advice, I might see a status of "in use" from Jan 1st until March 13th,
"not in use" from March 13th until March 16th, and "in use" from March
16th until now. That's almost three full months use - quite a hefty
bill. But in reality, the service was never called until March 13th,
when some other service failed. This service failed too (turns out one
parameter was misconfigured), so it was also given status "not in use".
Three days later, the parameter was repaired and the status was set to
"in use" once more, after which we actually started using it.

With your table, management would probably get a report saying that the
service has been used for three months, with a three day outage.
Grudgingly, they'd pay the bill for three months (with a small discount
for the outage).
With my table, I'd have to report to management that there is no easy
way to figure out the actual use of that particular service. Not very
good, but at least better than the lies you'd tell them. And I'd then
have to try to dig up the information on the actual use in some other
way. Maybe we'd eventually even end up examining the logs from the
service provider. But we would not pay for the months that the service
was not actually used.

--
Hugo Kornelis, SQL Server MVP
My SQL Server blog: http://sqlblog.com/blogs/hugo_kornelis

Hugo Kornelis wrote:
> On Wed, 1 Oct 2008 14:10:39 -0700 (PDT), --CELKO-- wrote:
>
>>>> Based on previous replies to similar questions, I expect Joe Celko to tell you to use a column active_date that stores the date (or even date and time) that the active status was achieved, and that is NULL if whatever is modeled in the table is not active. <<
>> No, based on previous replies, you should have said I would advise a
>> pair of columns to show duration of that status, more like this:
>>
>> CREATE TABLE Foobar
>> (..
>> foo_status CHAR(5) NOT NULL
>> CHECK(foo_status IN (..)),
>> start_date DATE NOT NULL,
>> end_date DATE, -- null is current
>
> Hi Joe,
>
> True. You've got me there!
>
>>>> (And he'll also blast you for using "field" instead of "column"). <<
>> Yes. This is important if you are ever going to think in sets and not
>> sequential files.
>
> Trust me on this, Joe. It *IS* possible to use the terms "field" and
> "record" and still think in sets.
>
> "That which we call a rose, by amny other name would smell as sweet!"
> -- Shakespeare, "Romeo and Juliet", 1594

And thus wallow in willful ignorance?

You are, of course, technically correct, you can call a rose a sewer
if you wish. But likely you will not find too many people willing to
tour your sewage garden. I would suggest that if you want to be a poet
you change your profession. In ours it matters.
--
Daniel A. Morgan
University of Washington
damorgan@x.washington.edu (replace x with u to respond)

On Sat, 04 Oct 2008 14:02:48 -0700, DA Morgan wrote:

>Hugo Kornelis wrote:
(snip)
>> Trust me on this, Joe. It *IS* possible to use the terms "field" and
>> "record" and still think in sets.
>>
>> "That which we call a rose, by amny other name would smell as sweet!"
>> -- Shakespeare, "Romeo and Juliet", 1594
>
>And thus wallow in willful ignorance?
>
>You are, of course, technically correct, you can call a rose a sewer
>if you wish. But likely you will not find too many people willing to
>tour your sewage garden. I would suggest that if you want to be a poet
>you change your profession. In ours it matters.

Hi DA,

If you use Google groups to check some (or even all) of my posts, you'll
note that I do always call rows rows, and columns columns. But, unlike
Joe, I do see that many people in the current world use the terms field
and record for these same things. It is clear, from their messages, that
they MEAN "row" and "column", and that they have probably never worked
with an ancient application that reads records from a sequential files
and uses various redefines to define the fields.

Times change. Language evolves. Or to throw in another ancient quote:
Panta rhei. We can attempt to fight it, but we can't stop it. I do try
to stop the change of the meaning of these two words, by gently using
the correct terms even if the question was using the other words. But
(unlike Joe!) I will not slap someone in the face for using these terms,
since I am fully aware that for most people, the words field and record
no longer have their original meaning, but are instead synonyms for
column and row.

(Oh, and by the way, The American Heritage Dictionary of the English
Language, Fourth Edition, has this as one of its definitions for field:
"An element of a database record in which one piece of information is
stored", and this for record: "_Computer Science_ A collection of
related, often adjacent items of data, treated as a unit").

--
Hugo Kornelis, SQL Server MVP
My SQL Server blog: http://sqlblog.com/blogs/hugo_kornelis

Hugo Kornelis wrote:
> On Sat, 04 Oct 2008 14:02:48 -0700, DA Morgan wrote:
>
>> Hugo Kornelis wrote:
> (snip)
>>> Trust me on this, Joe. It *IS* possible to use the terms "field" and
>>> "record" and still think in sets.
>>>
>>> "That which we call a rose, by amny other name would smell as sweet!"
>>> -- Shakespeare, "Romeo and Juliet", 1594
>> And thus wallow in willful ignorance?
>>
>> You are, of course, technically correct, you can call a rose a sewer
>> if you wish. But likely you will not find too many people willing to
>> tour your sewage garden. I would suggest that if you want to be a poet
>> you change your profession. In ours it matters.
>
> Hi DA,
>
> If you use Google groups to check some (or even all) of my posts, you'll
> note that I do always call rows rows, and columns columns. But, unlike
> Joe, I do see that many people in the current world use the terms field
> and record for these same things.

You are correct they do. It would also be correct to state that there
are people that rob banks, steal chickens, and don't know how to merge
into traffic. Each and every one of them should be taken to the
proverbial woodshed too.

We are the only "profession" where sloppiness is accepted. You won't
find physicians, surgeons, pharmacists, attorneys, accountants, or
engineers tolerating such nonsense. I am in full agreement with Joe:
Se need to start acting like we are worth our salaries.
--
Daniel A. Morgan
University of Washington
damorgan@x.washington.edu (replace x with u to respond)

DA Morgan (damorgan@psoug.org) writes:
> You are correct they do. It would also be correct to state that there
> are people that rob banks, steal chickens, and don't know how to merge
> into traffic. Each and every one of them should be taken to the
> proverbial woodshed too.

Obviously you are seriously in need of a holiday if you equate using
records and fields in place of rows and columns to robbing banks.

--
Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se

Links for SQL Server Books Online:
SQL 2008: http://msdn.microsoft.com/en-us/sqlserver/cc514207.aspx
SQL 2005: http://msdn.microsoft.com/en-us/sqlserver/bb895970.aspx
SQL 2000: http://www.microsoft.com/sql/prodinf...ons/books.mspx

Erland Sommarskog wrote:
> DA Morgan (damorgan@psoug.org) writes:
>> You are correct they do. It would also be correct to state that there
>> are people that rob banks, steal chickens, and don't know how to merge
>> into traffic. Each and every one of them should be taken to the
>> proverbial woodshed too.
>
> Obviously you are seriously in need of a holiday if you equate using
> records and fields in place of rows and columns to robbing banks.

Of course I don't equate them. But equally true I don't find value
in the argument that "other people do it too" which was the excuse
made: It is a poor one and I was highlighting its weakness.
--
Daniel A. Morgan
Oracle Ace Director & Instructor
University of Washington
damorgan@x.washington.edu (replace x with u to respond)
Puget Sound Oracle Users Group
www.psoug.org

On Sun, 05 Oct 2008 12:35:39 -0700, DA Morgan wrote:

>Erland Sommarskog wrote:
>> DA Morgan (damorgan@psoug.org) writes:
>>> You are correct they do. It would also be correct to state that there
>>> are people that rob banks, steal chickens, and don't know how to merge
>>> into traffic. Each and every one of them should be taken to the
>>> proverbial woodshed too.
>>
>> Obviously you are seriously in need of a holiday if you equate using
>> records and fields in place of rows and columns to robbing banks.
>
>Of course I don't equate them. But equally true I don't find value
>in the argument that "other people do it too" which was the excuse
>made: It is a poor one and I was highlighting its weakness.

Hi DA,

You obviously misunderstood me. The excuse made was not that "other
people do it to". The excuse (if you insist on calling it that) was
rather that it's a long-proven fact that language evolves over time, and
that correct use of language is ultimately decided by the people using
it.

I also noticed that you did not in any way address my finding that the
American Heritage (as far as I, not being a native English speaker, can
tell, an authorative English dictionary) includes meanings for both
record and field that you, me, and Joe would personally rather see only
attached to row and record. Can you really keep clinging to the idea
that records and fields are reserved for non-relational storage if even
the dictionary says otherwise?

--
Hugo Kornelis, SQL Server MVP
My SQL Server blog: http://sqlblog.com/blogs/hugo_kornelis

Hugo Kornelis wrote:
> On Sun, 05 Oct 2008 12:35:39 -0700, DA Morgan wrote:
>
>> Erland Sommarskog wrote:
>>> DA Morgan (damorgan@psoug.org) writes:
>>>> You are correct they do. It would also be correct to state that there
>>>> are people that rob banks, steal chickens, and don't know how to merge
>>>> into traffic. Each and every one of them should be taken to the
>>>> proverbial woodshed too.
>>>
>>> Obviously you are seriously in need of a holiday if you equate using
>>> records and fields in place of rows and columns to robbing banks.
>> Of course I don't equate them. But equally true I don't find value
>> in the argument that "other people do it too" which was the excuse
>> made: It is a poor one and I was highlighting its weakness.
>
> Hi DA,
>
> You obviously misunderstood me. The excuse made was not that "other
> people do it to". The excuse (if you insist on calling it that) was
> rather that it's a long-proven fact that language evolves over time, and
> that correct use of language is ultimately decided by the people using
> it.

Absolutely correct that language evolves over time. But this isn't about
language. This is about verbiage coded into the ANSI standard. This is
about keywords in the product documentation. This is about being able to
communicate with a world-wide audience with clarity.

If you want to say "Whatsup" or "Kool" knock yourself out. But to
claim that "table" communicates clearly when the question might
relate to whether it is a "heap table" or a "working (temp) table"
is quite another matter.

I am with Joe on this one and you'd not pass my class if you didn't
know the difference between a row and a record, a column and a field.

Does it matter? Look at all of the failed and terrible implementations
of software that plague our industry: Yes it matters.
--
Daniel A. Morgan
University of Washington
damorgan@x.washington.edu (replace x with u to respond)

>> Trust me on this, Joe. It *IS* possible to use the terms "field" and "record" and still think in sets.

"That which we call a rose, by any other name would smell as sweet!"
-- Shakespeare, "Romeo and Juliet", 1594 <<

Is this an argument for doing math with Roman Numerals, since they are
the same Integers? Words are mind tools. Common people also confuse
an engine and a motor, meteors, meteoroids and meteorites, guns and
pistols. ships and boats, etc.

But it does make a difference to the trained professional whose skill
domain makes use of exact words.

What I have found is that if you can get the concepts into a student
and cut him loose from his old mindset, he learns much faster, much
better. Let me do another quote I like:

It was beautiful, complex and wrong. In 150 AD, Ptolemy of Alexandria
published his theory of epicycles--the idea that the moon, the sun and
the planets moved in circles which were moving in circles which were
moving in circles around the Earth. This theory explained the motion
of celestial objects to an astonishing degree of precision. It was,
however, what computer programmers call a kludge: a dirty, inelegant
solution. Some 1,500 years later, Johannes Kepler, a German
astronomer, replaced the whole complex edifice with three simple laws.
-- The Economist

>>Binning the documentation ensured that both I and all my successors should use the source as the only trustworthy source of information, until finally budget was approved to re-document the thing (which, of course, never happened). <<

There is another great Babbage quote which I cannot find right now,
but the flavor of it that verification is an inseparable part of a
database (he did not have that word, of course). The reason he had
designed his difference engine was provide the British Navy with
accurate navigation tables. The tables in those days were full of
errors and even the errata had errors.

The same principle applies to documentation and your predecessors had
failed completely to maintain as a part of the system. Nothing should
have been allowed to modify the system without changing the
documents. And management who did not make that part of the system
failed their job.

DA Morgan (damorgan@psoug.org) writes:
> Absolutely correct that language evolves over time. But this isn't about
> language. This is about verbiage coded into the ANSI standard. This is
> about keywords in the product documentation. This is about being able to
> communicate with a world-wide audience with clarity.

And therefore you must be able to use "fields" and "records" everyonce
in a while. After all, these terms are usually more clear and precise
than "rows" and "columns". (Is that a "column" in a database table, or
is the author referring to a column in the table on the next page of the
book?)

Even Joe knows that. As testified by the fact that he has been heard to
use "record" (or if it was "field") in his presentations.

--
Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se

Links for SQL Server Books Online:
SQL 2008: http://msdn.microsoft.com/en-us/sqlserver/cc514207.aspx
SQL 2005: http://msdn.microsoft.com/en-us/sqlserver/bb895970.aspx
SQL 2000: http://www.microsoft.com/sql/prodinf...ons/books.mspx

On Oct 4, 8:11pm, DA Morgan <damor...@psoug.org> wrote:

> We are the only "profession" where sloppiness is accepted. You won't
> find physicians, surgeons, pharmacists, attorneys, accountants, or
> engineers tolerating such nonsense. I am in full agreement with Joe:
> Se need to start acting like we are worth our salaries.

I am quite sure that Garbage Collectors, Janitors, Landscapers, and a
number of others tolerate a certain level of "sloppiness", as you term
it. And perhaps you've heard the term "Good 'nuff for gov'ment work."

The key to language is that one uses a term that is understood by the
audience that one is speaking to. If I say "field" when I mean
"column," then its quite OK, so long as folks understand me. I am
quite sure many doctors have told patients that they have a "cold."
Ah ha! Sloppiness!! They ought to be telling their patients that
they have "acute viral nasopharyngitis!" The patient is not cold at
all--they might even have a fever. From my work in medical software,
I am quite confident that the official medical record shows a
diagnosis of a "cold." Is this sloppiness? Not at all. Everyone
knows exactly what is meant.

For persons who are quite so dead-set on accuracy of language, and
consistency, it is interesting to see so many typos!

On Oct 1, 5:10 pm, --CELKO-- <jcelko...@earthlink.net> wrote:
> Can you think of a business that would not have such an interest when
> it involves a product or service they are *libel* [sic] for? Business isvery
> temporal.

libel - v - print slanderous statements against; "The newspaper was
accused of libeling him"
liable - n - subject to legal action; "liable to criminal charges"

On Oct 1, 5:10 pm, --CELKO-- <jcelko...@earthlink.net> wrote:
> The "<verb>_<adjective>" naming convention is not ISO-11179, but at
> least it clearly shows that the data element is not scalar as required
> by RDBMS. It *lkooks* [sic] like OO programming. The flag does not measure
> the quality or quantity of an attribute, but answers a meta-data
> question about existence. Instead of a specific "how much", "how
> many", etc., we have a generalized "is" meta-question.

lkooks - unknown. perhaps an attempt to spell "cooks"?

On Oct 4, 8:11 pm, DA Morgan <damor...@psoug.org> wrote:
> *Se* [sic] need to start acting like we are worth our salaries.

se - abbr - selenium: a toxic nonmetallic element related to sulfur
and tellurium
SE - abbr - South East
..se - the Internet country code top-level domain (ccTLD) for Sweden
se - n - an ancient Chinese plucked zither (string instrument)
se - French - Third-person reflexive pronoun

On Oct 4, 5:02pm, DA Morgan <damor...@psoug.org> wrote:
> You are, of course, technically correct, you can call a rose a sewer
> if you wish. But likely you will not find too many people willing to
> tour your sewage garden. I would suggest that if you want to be a poet
> you change your profession. In ours it matters.

I am generally not very excited about sewer gardens, but I do enjoy
several other types of gardens:

Flower Gardens
Perennial Gardens

On Mon, 06 Oct 2008 10:23:15 -0700, DA Morgan wrote:

>Hugo Kornelis wrote:
>> On Sun, 05 Oct 2008 12:35:39 -0700, DA Morgan wrote:
>>
>>> Erland Sommarskog wrote:
>>>> DA Morgan (damorgan@psoug.org) writes:
>>>>> You are correct they do. It would also be correct to state that there
>>>>> are people that rob banks, steal chickens, and don't know how to merge
>>>>> into traffic. Each and every one of them should be taken to the
>>>>> proverbial woodshed too.
>>>>
>>>> Obviously you are seriously in need of a holiday if you equate using
>>>> records and fields in place of rows and columns to robbing banks.
>>> Of course I don't equate them. But equally true I don't find value
>>> in the argument that "other people do it too" which was the excuse
>>> made: It is a poor one and I was highlighting its weakness.
>>
>> Hi DA,
>>
>> You obviously misunderstood me. The excuse made was not that "other
>> people do it to". The excuse (if you insist on calling it that) was
>> rather that it's a long-proven fact that language evolves over time, and
>> that correct use of language is ultimately decided by the people using
>> it.
>
>Absolutely correct that language evolves over time. But this isn't about
>language. This is about verbiage coded into the ANSI standard. This is
>about keywords in the product documentation. This is about being able to
>communicate with a world-wide audience with clarity.

Hi DA,

If it's about communicating with the world-wide audience, then why not
rely on the dictionary to set the standards rather than cling on the
verbiage in a standard that is only used by a fraction of the total
world population?

Also, "field" IS defined in the ANSI standard. See ISO/IEC 9075-1:2003
(E), 4.4.5.3 on page 17 (in the late draft that I have; the newest
version I found for free on the internet):

4.4.5.3 Fields
A field is a (field name, data type) pair. A value of a field is a value
of its data type.

The term is further used heavily throughout the standard.

I do agree that "record" is not defined in the ANSI standard.

But alll the above is irrelevant. Whether or not row, column, field, and
record are defined in any standard - the world has moved on; the meaning
of the words has evolved. If I have to make a guesstimate, I'd say that
over 70% of all people professionally involved with database programming
consider the terms field and column and the terms row and record to be
100% synonyms. Fighting this just because it comes from the ultimate
evil named MS-Access is (a) useless, and (b) a fine wayy to show oneself
off as a dinosaur.

>If you want to say "Whatsup" or "Kool" knock yourself out. But to
>claim that "table" communicates clearly when the question might
>relate to whether it is a "heap table" or a "working (temp) table"
>is quite another matter.
>
>I am with Joe on this one and you'd not pass my class if you didn't
>know the difference between a row and a record, a column and a field.

There's a huge gap between "not knowing the difference" between terms,
or "occasionaly using the wrong term" or even "using the wrong term on
purpose since that will resonate better with the audience and the
difference is not really relevant in the context".

When modeling an EAR diagram, do you also religously stress the word
type in the terms "entity type", "attrbiute type", and "relationship
type" all the time, or do you just go with the flow and use the terms
"entity", "attribute", and "relationship" even though you are aware that
these terms actually describe a single instance rather than the
generalization?

>Does it matter? Look at all of the failed and terrible implementations
>of software that plague our industry: Yes it matters.

Ah, and those implementation would all have been great if noone had ever
used the words "field" or "record" in a relational context?

If that's you analysis of why projects fail, than you'd better prepare
yourself for many more failed implementations.

--
Hugo Kornelis, SQL Server MVP
My SQL Server blog: http://sqlblog.com/blogs/hugo_kornelis

On Mon, 6 Oct 2008 10:35:52 -0700 (PDT), --CELKO-- wrote:

>>> Trust me on this, Joe. It *IS* possible to use the terms "field" and "record" and still think in sets.
>
>"That which we call a rose, by any other name would smell as sweet!"
> -- Shakespeare, "Romeo and Juliet", 1594 <<
>
>Is this an argument for doing math with Roman Numerals, since they are
>the same Integers? Words are mind tools. Common people also confuse
>an engine and a motor, meteors, meteoroids and meteorites, guns and
>pistols. ships and boats, etc.
>
>But it does make a difference to the trained professional whose skill
>domain makes use of exact words.
>
>What I have found is that if you can get the concepts into a student
>and cut him loose from his old mindset, he learns much faster, much
>better.

Hi Joe,

What you appear to be forgetting is that most people out there are not
dinosaurs like you and me. They have never ever worked with file storage
or other sequential I/O. The *only* times they see the terms record and
field is in the context of a relational database. So these words
describe the same concepts to them as the words row and column describe
to us.

(snip)
>The same principle applies to documentation and your predecessors had
>failed completely to maintain as a part of the system. Nothing should
>have been allowed to modify the system without changing the
>documents. And management who did not make that part of the system
>failed their job.

Exactly!

--
Hugo Kornelis, SQL Server MVP
My SQL Server blog: http://sqlblog.com/blogs/hugo_kornelis

>> What you appear to be forgetting is that most people out there are not dinosaurs like you and me. They have never ever worked with file storage or other sequential I/O. The *only* times they see the terms record and field is in the context of a relational database. So these words describe the same concepts to them as the words row and column describe <<

While I grant that there are only a few of us here who remember punch
cards and mag tapes, even the newbies with their new-fangled C#, Java
and VB have used files that come with those languages.

I am making shadow boxes for the house. So far I have put my old
slide rulers on exhibit, and have the collections of abaci and
astrolabes ready to go up next. But I cannot find a punch card !

On Thu, 9 Oct 2008 07:41:15 -0700 (PDT), --CELKO--
<jcelko212@earthlink.net> wrote:

>While I grant that there are only a few of us here who remember punch
>cards and mag tapes, even the newbies with their new-fangled C#, Java
>and VB have used files that come with those languages.

You continue to think strictly in terms of bit IT operations. While
you weren't paying attention over the last 20 years or so that has
become only a fraction of the IT industry as much of the growth has
been in companies and in systems that are entirely divorced from the
world of big iron.

>I am making shadow boxes for the house. So far I have put my old
>slide rulers on exhibit, and have the collections of abaci and
>astrolabes ready to go up next. But I cannot find a punch card !

Alas, I seem to have discarded all my punch cards too. However I do
have a five gallon glass water cooler bottle just about full of punch
chips and the dots from teletype.

Roy Harvey
Beacon Falls, CT

--CELKO-- wrote:

> I am making shadow boxes for the house. So far I have put my old
> slide rulers on exhibit, and have the collections of abaci and
> astrolabes ready to go up next. But I cannot find a punch card !

I have a couple 80 column cards on my desk. Want one?
Trade you for a 10MB hard disk. <g>
--
Daniel A. Morgan
University of Washington
damorgan@x.washington.edu (replace x with u to respond)

>> that has become only a fraction of the IT industry as much of the growth has
been in companies and in systems that are entirely divorced from the
world of big iron. <<

You might want to look at a recent issue of Dr. Dobb's on COBOL. Big
iron might not have much glamour, but it still does most of the work
in the commercial world.


>> Alas, I seem to have discarded all my punch cards too. However I do have a five gallon glass water cooler bottle just about full of punch chips and the dots from teletype. <<

LOL!! The correct term is "chad" -- Actually remember that!! And the
strip of paper with the holes for feeding continuous form is called
"perf" when you tear it off. Another "Golden Oldie" -- I have a McBee
card punch and sorting needle but no cards.

On Thu, 9 Oct 2008 18:42:52 -0700 (PDT), --CELKO--
<jcelko212@earthlink.net> wrote:

>>> that has become only a fraction of the IT industry as much of the growth has
>been in companies and in systems that are entirely divorced from the
>world of big iron. <<
>
>You might want to look at a recent issue of Dr. Dobb's on COBOL. Big
>iron might not have much glamour, but it still does most of the work
>in the commercial world.

Most of the work in the Fortune 100 is done by SAP or equivalent, and
from what I have seen that mostly runs on UNIX. You might be able to
call those UNIX boxes Big Iron, but SAP sure doesn't fit the COBOL way
of life. Yes, there is still plenty of COBOL and mainframes, for a
specialized set of very large applications. But the rest of the pie
has grown exponentially while that slice, as a proportion of the
whole, has only grown smaller.

Roy Harvey
Beacon Falls, CT