Re: Problems with querying date field
From: Steve Kass (skass_at_drew.edu)
Date: 03/30/04
- Next message: Andrew J. Kelly: "Re: Stop Changing My Original Data Vaues"
- Previous message: Vadim Tropashko: "Re: Recursive Query"
- In reply to: Joe Celko: "Re: Problems with querying date field"
- Next in thread: Joe Celko: "Re: Problems with querying date field"
- Reply: Joe Celko: "Re: Problems with querying date field"
- Messages sorted by: [ date ] [ thread ]
Date: Mon, 29 Mar 2004 21:43:22 -0500
Joe Celko wrote:
>
>A file is usually associated with a particular language -- ever try to
>read a Fortran file with a Cobol program? A database is language
>independent; the internal SQL datatypes are converted into host language
>datatypes.
>
>
>
A database is language or anything else-independent so long as you don't
want to do any more than imagine it and talk (or write) about it. If
you want to put a database somewhere for safekeeping, you'll be
hard-pressed to do it in a way that is independent of the particular SQL
implementation that created it. Your best bet is to export it to a flat
file, since flat files are probably the most portable of all existing
information storage formats, despite the various file systems and media
that can be used to create and access them. If you want data to be
language-independent, store it as ASCII or Unicode text in a file (NTFS,
FAT, OS-X, Unix, any one will do). Then you can write programs to read
it in your favorite language, be it Cobol, Fortran, SQL (well, no, I
guess you'd have to use another language, unless there is a "standard
SQL" way to interact with the real world that I'm not aware of), or Scheme.
I don't believe there has ever been a SQL standard for how to persist a
database - SQL isn't about persistence, though persistence is important
to many people and institutions. You may enjoy laughing at people who
care about this important issue, but you look very foolish to me.
>A field exists only because of the program reading it; a column exists
>because it is in a table in a database. A column is independent of any
>host language application program that might use it.
>
>
Unfortunately you can't keep those important columns in your locked desk
drawer though, like you can files with their quaint records and fields.
>In a procedural language, "READ a, b, c FROM FileX;" does not give the
>same results as "READ b, c, a FROM FileX;" and you can even write "READ
>a,a,a FROM FileX;" so you overwrite your local variable. In SQL,
>"SELECT a, b, c FROM TableX" returns the same data as "SELECT b, c, a
>FROM TableX" because things are located by name, not position.
>
>A field is fixed or variable length, can repeated with an OCCURS in
>Cobol, struct in c, etc. A field can change datatypes (union in 'C',
>VARIANT in Pascal, REDEFINES in Cobol, EQUIVALENCE in Fortran).
>
>A column is a scalar value, drawn from a single domain (datatype +
>constraints + relationships) and represented in one and only one
>datatype. You have no idea whatsoever how a column is PHYSICALLY
>represented internally; you never see it.
>
Some people need to see their data and save it in a non
implementation-dependent format. Unfortunately, SQL data storage is
entirely implementation-dependent.
>Look at temporal datatypes;
>in SQL server, DATETIME is a binary number internally (UNIX style system
>clock representation), but TIMESTAMP is a string of digits in DB2 (Cobol
>style time representation). When you have a field, you have to worry
>about that physical representation. SQL says not to worry about the
>bits; think of data in the abstract.
>
>
I'll try that line at my next job interview.
>Fields have no constraints, no relationships, and no datatype; each
>application program assigns such things and they don't have to assign
>the same ones! That lack of data integrity was one of the reasons for
>RDBMS systems.
>
>
Every existing RDBMS system is nothing more than a program based on
sequential files and sequentially byte-addressable memory that follows
some useful principles. An RDBMS isn't magic, and data integrity can
exist without one.
>Rows and columns have constraints. Records and fields can have anything
>in them and often do!! Talk to anyone who has tried to build a data
>warehouse about that <g>. My favorite is finding the part number "I
>hate my job" in a file.
>
>
At least part numbers exist somewhere after you turn the computer off.
>When new SQL programmers use IDENTITY, GUID, ROWID, or other
>auto-numbering vendor extensions to get a key that can be used for
>locating a given row, they are imitating a magnetic tape's sequential
>access. It lets them know the order in which a row was added to the
>table -- just like individual records went onto the end of the tape!
>
>
God forbid anyone should care to know which end is up, or want to store
data on a tape, or a disk, or a CD, or a file, or any physical format at
all!
>Dr. Codd defined a row as a representation of a single simple fact. A
>record is usually a combination of a lot of facts. That is, we don't
>normalize a file; you stuff data into it and hope that you have
>everything you need for an application. When the system needs new data,
>you add fields to the end of the record. That is how we got records
>that were measured in Kbytes.
>
>
Perhaps not for Codd and you, but for some people, theory has to meet
practice. When it does, you are usually not far from a file.
SK
>--CELKO--
> ===========================
> Please post DDL, so that people do not have to guess what the keys,
>constraints, Declarative Referential Integrity, datatypes, etc. in your
>schema are.
>
>*** Sent via Developersdex http://www.developersdex.com ***
>Don't just participate in USENET...get rewarded for it!
>
>
- Next message: Andrew J. Kelly: "Re: Stop Changing My Original Data Vaues"
- Previous message: Vadim Tropashko: "Re: Recursive Query"
- In reply to: Joe Celko: "Re: Problems with querying date field"
- Next in thread: Joe Celko: "Re: Problems with querying date field"
- Reply: Joe Celko: "Re: Problems with querying date field"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
