按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
winners； the table would need to be modified like this：
2000。05。31 nobody 5 6 13 23 25 37 43
2000。06。03 jack jill 7 10 11 18 32 41 5
2000。06。07 nobody 15 23 24 28 38 39 45
2000。06。10 jack 1 3 12 23 29 33 27
2000。06。14 nobody 2 4 13 19 39 45 26
2000。06。17 nobody 3 8 17 19 21 25 35
…………………………………………………………Page 396……………………………………………………………
374 CH AP T E R 1 4 ■ L E A R N I N G A B OU T R E L A TI O N AL DA TA B AS E D AT A
Here； another field indicates Jill as the second winner of the draw。 Adding another field
throws a monkey wrench into the entire table structure and makes processing much more
plicated； because the parsing routines will need to verify if another field is present。 This
breaks the nice grid structure and is plain wrong。
Another approach using the text file would be to create a third file that cross…references the
winners with the dates。 So the lottery file would go back to the original version：
2000。05。31 5 6 13 23 25 37 43
2000。06。03 7 10 11 18 32 41 5
2000。06。07 15 23 24 28 38 39 45
2000。06。10 1 3 12 23 29 33 27
2000。06。14 2 4 13 19 39 45 26
2000。06。17 3 8 17 19 21 25 35
And a winners table would be created：
2000。06。03 jack
2000。06。03 jill
2000。06。10 jack
The winners table is a grid of draw dates and winners on those dates。 Notice how there is
no entry for nobody； so only draw dates with winners are included。
■Note These three tables are an example of correctly normalized data。 When the data is well normalized；
each table contains unique data。 In this example； one table contains all of the lottery drawings； but who the
winners are is stored in another table。 Using database relations； the winners and lottery data are related； yet
neither table needs to know about the other table。
Now what happens if two different people named Jack are lottery winners？ The data might
look like this：
2000。05。31 nobody 5 6 13 23 25 37 43
2000。06。03 nobody 7 10 11 18 32 41 5
2000。06。07 nobody 15 23 24 28 38 39 45
2000。06。10 jack 1 3 12 23 29 33 27
2000。06。14 jack 2 4 13 19 39 45 26
2000。06。17 nobody 3 8 17 19 21 25 35
We know the two jack entries are not for the same Jack。 So now we have an additional
problem of uniqueness。 Uniqueness is not unusual when dealing with relational databases；
and the mon technique is to identify each Jack with a unique key。 For example； a unique
key could be jack_1 or jack_2。 The problem with using jack_1 and jack_2 is that you need to
search the database to see if there is a jack entry； and then find out the last jack entry。 Those
steps are resource…intensive and typically avoided。 Another solution is to use a database
provided field that generates a unique key； which could be a row number or globally unique
identifier （GUID）。 If the unique identifier were to be puter…generated； the table might look
as follows：
…………………………………………………………Page 397……………………………………………………………
C HA P TE R 1 4 ■ L E AR N I N G AB O U T R E L AT IO N A L D AT AB A SE D A TA 375
2000。05。31 1877_ds 5 6 13 23 25 37 43
2000。06。03 1877_ds 7 10 11 18 32 41 5
2000。06。07 1877_ds 15 23 24 28 38 39 45
2000。06。10 1023_ad 1 3 12 23 29 33 27
2000。06。14 1022_xy 4 13 19 39 45 26
2000。06。17 1877_ds 3 8 17 19 21 25 35
In the modified table； you would have no idea who the identifiers represent。 The way to
find out is to take a key and open its associated field—say 1877_ds and the file 1877_ds。txt。
Upon opening the file； you would know that the winner is nobody。 The process of finding out
who the winner is involves more steps； but a relational database knows how to manage these
types of relations quite effectively。
WHY THE THOUSANDS OF APIS； LIBRARIES； AND TECHNIQUES？
In the space of 12 years； the following data…access technologies have emerged： Open Database Connectivity
（ODBC）； Remote Data Objects （RDO）； the Jet Database Engine； Data Access Object （DAO）； ActiveX Data Object
（ADO）； Object Linking and Embedding； Database （OLE DB）； ADO； and Language Integrated Query （LINQ）。
This means that every 2 years； a new database technology is introduced。 Each database technology has libraries to
make it easier to write code。 The result is an amazing number of ways to access a piece of technology that is
nearly 40 years old。
So why do we have so many ways to access and manipulate the database？ Wouldn’t we； as developers；
get our act together and work toward a mon approach to manipulating a relational database？ I can’t give
a logical and accepted answer as to why there are so many data…access technologies。 But I can tell you what
I think。
For any real production application； it is not unmon to have tables that have 30 columns。 When
writing code to add； delete； and modify a row in a table that has 30 fields； you are； for the most part； trying to
figure out which field goes to which piece of data。 Thus； people try to automate the job。 After all； it is more
interesting to work through a threading bug than an incorrect…field…placement bug。
Another issue is a technology mismatch between a programming language and a relational database。 A
relational database treats data as a set。 There are no individual pieces of data in a relational database。 Programming
languages treat data as individuals。 Even in a collection class； you have an individual class managin