Re: Problems with querying date field
From: Joe Celko (joe.celko_at_northface.edu)
Date: 03/30/04
- Next message: oj: "Re: What is the max number of columns in a table of a SQLXMLBulkLoad"
- Previous message: Quentin Ran: "Re: trigger problem"
- In reply to: Steve Kass: "Re: Problems with querying date field"
- Next in thread: Tibor Karaszi: "Re: Problems with querying date field"
- Messages sorted by: [ date ] [ thread ]
Date: Tue, 30 Mar 2004 14:56:41 -0800
>> If you want to put a database somewhere for safekeeping, .. best bet
is to export it to a flat file,.. store it as ASCII or Unicode text ..<<
Agreed, but I'd go with a CSV format to be really safe -- a human being
could then read it if they had to.
>> 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. <<
Unh? I cannot figure out the last sentence. SQL is a language spec and
says nothing about the physical storage media to be used. It also says
nothing about maintenance of code, which is rather important, but not
part of a language spec. Persistence of data is required in SQL (see
ACID properties); the method is not specified.
>> Unfortunately you can't keep those important columns in your locked
desk
drawer though, like you can files with their quaint records and fields.
<<
Unh? I cannot figure out the last sentence either. But I think you've
missed the trend in the trade. The move has been steadily away from
proprietary, very physical implementations for systems first to open
standards and portable tools. And to now to MDA (Model Driven
Architecture) which is pure abstractions.
>> Unfortunately, SQL data storage is entirely implementation-dependent.
<<
Then how do ODBC, SQL/CLI, JDBC, et al work? It sure looks like SQL
data is very accessible to standard programming languages and not just
to proprietary ones. Maybe all that work SQL/Access, X/OPEN, XJ2, and
the vendors did pay off after all!
>> [SQL says not to worry about the bits; think of data in the abstract]
I'll try that line at my next job interview. <<
If you can back up the claim with a certificate Model Driven
Architecture, you will start at over $50K and up to $75K. The "code
monkey" jobs are going overseas.
At the beginning of the 19th century, 80 to 90 percent of the population
in Western countries was employed in agriculture; today, it's about 2
percent to 3 percent. Ask yourself, do people in the West worry about
famine or obesity in the 21st century? We use machinery and technology,
not animal and human labor.
The same pattern holds for the 20th century — we have fewer people in
the manufacturing industries and a higher output than ever before. We do
the design work in America and ship the fabrication overseas.
I have had a few editorials in INTELLIGENT ENTERPRISE on this topic
lately.
http://www.intelligententerprise.com/showArticle.jhtml?articleID=1830010
9
http://www.intelligententerprise.com/showArticle.jhtml?articleID=1840150
8
>> Every existing RDBMS system is nothing more than a program based on
sequential files and sequentially byte-addressable memory that follows
some useful principles. <<
No. Teradata uses hashing that gets to data in one probe the majority
of the time and not more than two probes -- no sequential access.
Nucleus (Sand Technology) uses compressed bit vectors that perform
hundreds of logical operations in a few machine cycles -- no sequential
access and no physically contiguous storage of values. White Cross uses
a modified RAID storage system for parallel access. There are at least
a dozen more versions of SQL that are not using sequential, contiguous
storage of values.
>> An RDBMS isn't magic, and data integrity can exist without one. <<
True. If I had perfect users and perfect programmers, then all data
integrity could be done in application code. In fact, we tried that
before we had databases; it did not work. Big time :)
>> 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! <<
You've missed the whole point. God forbid that people think the *real*
value of a system lies in any particular physical implementation. We
need an abstract model of the data and the business ruels **before** we
store it a physical format. The more abstract the model, the more
powerful it is to us. The physical stuff is not that important or
valuable any more; it is cheap and fast.
At one point in history, shepherds in the Middle East kept track of
their flocks with physical clay tokens for each animal. Then we
developed numerals, a higher level of abstraction. Then we developed
place-valued notations, a still higher level of abstraction. Today, we
have modern mathematics.
Do you really feel that mathematicians are wasting time and we need to
get back to clay tokens (made with proprietary clay?) where primitive
nomadic shepherds are doing real work?
--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: oj: "Re: What is the max number of columns in a table of a SQLXMLBulkLoad"
- Previous message: Quentin Ran: "Re: trigger problem"
- In reply to: Steve Kass: "Re: Problems with querying date field"
- Next in thread: Tibor Karaszi: "Re: Problems with querying date field"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
