Wiley Professional SQL Server 2000 Programming 978-0-7645-4379-1 User Manual

Product codes
978-0-7645-4379-1
Page of 20
SQL Server 2000 – Particulars and History
11
RDBMS systems
: Data for the masses, but with much better data integrity. These systems do
more than just store and retrieve data. They can be thought of as actually caring for the
integrity of the data. Whereas VSAM and ISAM databases typically store data very well, the
database itself has no control over what goes in and out (OK, Access has some, but not like a
true RDBMS). The programs that use the database are responsible for implementing any data
integrity rules. If five programs are accessing the data, you'd better make sure that they are all
programmed correctly. RDBMS systems, on the other hand, take the level of responsibility for
data integrity right down to the database level. You still want your programs to know about
the data integrity rules to avoid getting errors from the database, but the database now takes
some of the responsibility itself and the data is much safer.
Object-oriented databases
: These have been around for a while now, but are only recently
beginning to make a splash. They are really a completely different way of thinking about your data
and, to date, have only found fairly specialized use. Examples would be something similar to a
document management system. Instead of storing the document in several tables, the document
would be stored as a single object, and would have properties whose state would be maintained.
ODBMS
 systems often provide for such object-oriented concepts as inheritance and encapsulation.
RDBMS systems are clearly king these days. They are designed from the ground up with the notion that
they are not going to be working with just one table that has it all, but with data that relates to data in
completely different tables. They facilitate the notion of combining data in many different ways. They
eliminate the repetitive storage of data and increase speed in transactional environments.
The Evolution of Relational Databases
E.F. Codd of IBM first introduced the principles behind relational database structures and a Structured
English QUEry Language – or SEQUEL – back in the late 1960's (the name was later shortened to just
Structured Query Language
 or SQL). The concept was actually pretty simple – increase data integrity and
decrease costs by reducing repetitive data as well as other database problems that were common at the time.
Nothing really happened in the relational world as far as a real product was concerned until the mid to
late 70's, though. Around that time, companies such as Oracle and Sybase became the first to create true
relational database systems. It might surprise you to learn that these systems got their start in mainframe
– not client-server – computing. These systems offered a new way of looking at database architecture
and, since they ran on multiple platforms, they also often offered a higher potential for sharing data
across multiple systems.
In the 80's, the American National Standards Institute (ANSI) finally weighed in with a specification for
SQL, and ANSI-SQL was born. This was actually a key moment in RDBMS computing because it
meant that there would be better compatibility between vendors. That, in turn, meant that more of the
expertise built up in one RDBMS was also usable in a competing system. This has greatly aided the
process of trying to increase the number of developers in the SQL community. The ANSI specification
called for several different levels of compliance. Most of the major RDBMS products available today are
classified as being Entry-Level ANSI compliant (like SQL Server, for example). Entry-level ANSI
compliance means that a database meets the basic defined ANSI standards for the SQL syntax.
ANSI compliance is a double-edged sword. I'm going to encourage you to make use of ANSI
compliant code where feasible – it's particularly important if you may be migrating your code
between different database servers. But you also need to realize that many of the performance and
functionality features that each of the high performance database vendors offers are not ANSI
compliant. Each vendor extends their product beyond the ANSI spec in order to differentiate their
product and meet needs that ANSI hasn't dealt with yet. For example, SQL Server 2000 has
expanded on the basic SQL with its own additions, which are called T-SQL. This leaves you with a
choice – ANSI compliance or performance.