Duncan Lithgow wrote:
In response to some questions from a charity I do some work for I'm
writing a wikibook 'How to future proof electronic information'.
I'm stuck on several questions, but let me ask this one here.
An important is SQL - but sql is for working _with_ the dataset(s). What
is the format of the _actual data itself_? If I'm recommending selection
criteria for choosing a database I kinda need to understand this bit...
All major database engines represent data internally differently. They
also handle the disk files that hold the data differently. There is no
"right" or "standard" way. The designers make choices based on how they
want the database to work.
SQL stands for "structured query langage" and defines how you interact
with the SQL server, much the same as HTTP defines how your web browser
interacts with websites--be they Apache, IIS, Netscape, whatever and
regardless if it runs on Windows, Linux, Unix, BeOS, MVS, VAX/VMS or
some other operating system. As long as the website speaks HTTP, your
browser doesn't care.
Part of SQL's definitions are a number of data types (fixed point,
float, text, fixed text, timestamp, etc.) that are used to represent
your data, but it does NOT define how the server will _store_ the data.
As far as an application is concerned, what does it matter if the server
stores the data internally in EBCDIC, two's complement, excess-64, an
ASCII string or by having hundreds of thousands of people with abacii?
A properly written, fully compliant SQL program can "talk" to any SQL-
compliant database equally well--PostgreSQL, MySQL, Ingres, Oracle,
Informix, DB2...even MS SQL (gaaack!).
----------------------------------------------------------------------
- Rick Stevens, Senior Systems Engineer rstevens@xxxxxxxxxxxxxxx -
- VitalStream, Inc. http://www.vitalstream.com -
- -
- "I understand Windows 2000 has a Y2K problem." -
----------------------------------------------------------------------
