| |
 |
|
SQL Server
Tips by Burleson |
Early SQL and Contiguous
Storage
The early SQLs were based on existing file systems. The data was
kept in physically contiguous disk pages, in physically contiguous
rows, made up of physically contiguous columns — in short, just like
a deck of punch cards or a magnetic tape. You located data by
counting its position in the deck, starting at the front.
Physically contiguous storage is only one way of building a
relational database and it is not always the best one. But aside
from that, the whole idea of a relational database is that user is
not supposed to know how things are stored at all, much less write
code that depends on the particular physical representation in a
particular release of a particular product.
One significant error is the IDENTITY column in the Sybase family
(SQL Server and Sybase). If you are not familiar with this
"feature," it is assigned to a column as its data type with the
limitation that a table can have only one such column. The database
engine assigns a sequential integer in this column to every row in
the table as it is inserted.
People actually program with this "feature" and even use it as the
primary key for the table! Now, let's go into painful details as to
why this thing is bad.
This is a book excerpt from:
Advanced SQL Database Programmer Handbook
Donald K. Burleson, Joe Celko, John Paul Cook, Peter Gulutzan
ISBN: 0-9744355-2-X
http://www.rampant-books.com/ebook_dbazine_SQL_prog.htm
|
