《VB2008从入门到精通(PDF格式英文版)》第177章

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