Referential integrity is needed to keep the entity as a particular and the database as a whole in synchronized state. If a primary key value of a particular table is deleted or tampered with, either the corresponding key value of the foreign table should be deleted (known as cascade) or a message should be generated and the delete operation should be stopped. If none of these steps are carried out, the database goes for a toss rendering itself completely useless.
Sounds as a simple rule in databases, right? But when applied to a larger entity called ‘life’, the database definitions start getting more complex. A column which is the primary key of a given table has necessarily undergone the polling session when it was appointed as the primary key of that table at the first place. So, that means everyone (including the table and the key selected to be the primary key) knows its importance in the bigger role and the bigger world. All the further transactions and definitions of some of the larger database tables, now depend on the definition of this table. Various static and dynamic definitions are executed and various objects are created and altered accordingly in order to fit the integrity of this entity into the whole database. There are many new entities (smaller as well as larger, some even as critical as life itself) based on the current definition of this entity.
But, when this key in being deleted (for whatever reason) from the entity, referential integrity rule should, ideally, be applied right? That means, even the other primary key values should be deleted (in a cascaded manner) or a (strict) message should be displayed that this delete operation cannot (could not is too lenient a term for database errors ) be performed. But this does not happen and the key is deleted without taking into consideration any warnings or messages or even the possible threat of a complete database crash. This ultimately results in a complete disaster leaving the database in a totally unsynchronized manner and sometimes even crashes it rendering it completely useless. Only use of this database, then would be to query junk and some reference data.
Thus it is vividly clear that even though referential integrity is a small and simple concept in databases but when it comes to a larger entity called life, it is not that simple as we/people think.
Very interesting analogy dude :)
ReplyDeleteThanks man ....;-)
ReplyDeleteplus,there is no concept of "backup and recovery" in "life" :(
ReplyDeleteYes, only 'commit'. And if that is screwed up, the entire database is screwed up.
ReplyDeletesumtimes the dbase shd be crashd n rebuilt, and whn u do so, bild ur dbase on oracle platform n not sql (aka the microsoft platform). luks like all d issues r due to ur (may be ovr) reliance on the "msoft" platform..get rid of it.. not worth it..
ReplyDeleteThanks buddy ... i know its high time to rebuild the database, more stronger and more safer ... and yeah the problem of untimely crashing .... and over here not even a reboot is helping :-) anyways ... cant say whether worth it or not .. coz experience counts ... and it was once upon a time a very reliable platform ... good old days you see
ReplyDeleteabsltly, exprnce counts..u betr learn frm tht exprnce and build ur new dbase btr :-), rmmbr bird has flown out of the nest..has seen n lrnt much more..so unlikely, will rtn, and evn if rtns..no grntee it will sty bk..ur life..ur rules..so tk care.. ;-)
ReplyDeleteYeah, my life my rules ... but there is something called as commitment. When you give a word, a promise it has to be kept unbroken. Did it mean nothing then that it just flew off in a flick of a flare?
ReplyDelete