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