Re: OT: Canadian Tax Database - Mailing list pgsql-general

From Jeff Davis
Subject Re: OT: Canadian Tax Database
Date
Msg-id 1173833882.23455.249.camel@dogma.v10.wvs
Whole thread Raw
In response to Re: OT: Canadian Tax Database  (omar <omar2@omnicode.com>)
List pgsql-general
On Fri, 2007-03-09 at 19:40 -0800, omar wrote:
> below.) This behavior is a feature, not a bug. A database is suppose to
> store and retrieve data and it should not matter to the database what
> format that data is in. The strong typing system found in most other SQL

In my opinion, this is the most important -- and most misguided --
statement that you quoted.

Storing and retrieving arbitrary (string,binary) data is the most
ancient form of a database. Relational databases are much more.

Let me make a comparison --

In SQLite you:
* store variable A in database with key X.
* store variable B in database with key Y.
* ask for some data with key X, and put it in a variable C
* make assumptions about what the data is; i.e. part of a string, an
int, or another key
* do something useful with variable C (don't look in the database for
key C if C is a color and not a key) and put the result in variable D
* store variable D in database with key Z and keep track of key Z so
that you can find it when you need it later

In Assembly Language you:
* store register A in memory at address X.
* store register B in memory at address Y.
* ask for the data at address X, and put it in a register C
* make assumptions about what the data is; i.e. part of a string, an
int, or another key
* do something useful with register C (don't look in the memory at
address C if C is a part of a string and not a memory address) and put
the result in register D
* store register D in memory at address Z and keep track of address Z so
that you can find it when you need it later

See? They're both "simple." But at some point programmers decided they
wanted the "complexity" of data types, constraints, etc. And it's
actually more important with a database because the data is persistent,
and you will end up converting and rewriting the on-disk data to support
each new feature that requires a minor difference in data layout.

I could go on, but there is a lot of good info out there already. Look
for books by Chris Date, a.k.a. C.J. Date.

These links might help:

http://en.wikipedia.org/wiki/Relational_database
http://en.wikipedia.org/wiki/Relational_algebra
http://www.postgresql.org/docs/8.2/static/index.html

Regards,
    Jeff Davis


pgsql-general by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: orphaned PGDATA/base/ subdirectories
Next
From: "Jasbinder Singh Bali"
Date:
Subject: Exception handling in plperl