sh******@cs.fsu.edu wrote in
news:11*********************@j55g2000cwa.googlegro ups.com:
But what I'm wondering, is in the abscence of an index or primary
key, how does the DBMS find a particular record that a user is
updating via a form?
Does it have to do a sequential search for the record that matches
all fields, and then update it? This would be computationally
slow, but I don't know of any other search algorithms that would
work with an unordered set of data that has no indexing or
hashtable support.
Well, most database engines actually keep track of the data by its
location in the storage system (or the same thing virtualized in
memory), using offsets.
When you retrieve a particular record by choosing a value on a
field, Jet looks at the index for that record, and if it's a primary
key index, it's going to point to the relevant data page(s) in the
MDB file, and that's how it knows which record(s) to load.
The database engine actually doesn't give a rat's ass about the
content of your data, so for it, a PK really doesn't mean anything,
since each record is unique based on its starting point and length.
The difficulty for the programmer in a non-PK situation is how to
figure out how to tell the db engine which of those unique
offset/length combinations to retrieve.
It seems to me like you're making the problem more difficult than it
is. Think of it this way: if you had a spreadsheet with 5 rows, and
the data in all the rows was identical, you could still identify
each row by the row number. From a SQL point of view, though, you
couldn't, since SQL works with sets based on the actual data. But
SQL is only an interface to the database engines, not the db engines
themselves.
--
David W. Fenton
http://www.dfenton.com/
usenet at dfenton dot com
http://www.dfenton.com/DFA/