On 4/22/05, Rick Stevens <rstevens@xxxxxxxxxxxxxxx> wrote: > 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." - > ---------------------------------------------------------------------- > I believe part of the OP's question is in regards to the ability of future systems to access archived data, not the format in which it is stored. One of the biggest problems with future-proofing electronic data is that mechanisms may not be available to access the medium/media on which the data was stored. If an organization were to store data on a DVD-ROM there is no guarantee that 5 years later the organization will have retained the capability to retrieve the data. For example, how many people have working drives for 9-track tape, 8-inch floppy (hard or soft sectored), 5-1/4 inch floppy, or Syquest cartridges. Compared to paper electronic inofrmation has a very short life span. That is why I recommend that the OP check with what the Library of Congress is doing.
