old, but imho, still valid: http://lawgon.livejournal.com/10240.html
Interesting read :-) Of course the statement ``writing huge amounts of extra code to do by myself what the rdbms is supposed to do" is quite extreme because of a simple reason - we do NEED databases and relational databases. In fact legacy systems had faced many problems because everything was hardcoded and flat files(and nothing else) were the order of the day. This is where reading things for basic concepts makes a difference. In fact when i was studying databases in college there was a ton of database theory to be read, it REALLY annoyed me because i thought if i could write SQL i knew databases. Only when i got assosciated with live projects that i understood what an idiot i had been for taking them(database theory and concepts) for granted. In the light of your article, the introduction chapter in Korth, Sudarshan, Silberschatz makes a ton of sense(yet again). Also, i've learned one thing our database thinking MUST be product agnostic. As in - DFD's, ER-diagram's, and EER-diagram's have nothing to do with which DB/SQL you use. A join is a join(be it of any type) after you decide how it must happen, you refer to your DB product manual and figure it out :-) Regards, - vihan -- http://mm.glug-bom.org/mailman/listinfo/linuxers
