Dynamism and Database Referential Integrity

Hung Jung Lu hungjunglu at yahoo.com
Tue Jan 8 19:32:16 CET 2002


With languages like Python, we have learnt that dynamism can be a good
thing. By dynamism I mean that the data is not strong-typed: you can
add/remove attributes to a Python object at runtime.

Programmers with C++/Java background frequently complains about
Python, because it does not enforce type-checking. In particular, you
don't have Java interfaces, you don't have polymorphic methods, etc.
And in Python when you type 'spam.eggs', you don't have "compile-time"
checking that 'eggs' is a member of 'spam'. Anyway, these complains
are seen frequently in comp.lang.python, yet Python has been
time-tested and has proven itself to be a viable programming language.
So dynamism seems to offer a large number of advantages over static
type checking.

I have a question on databases. If you ask a database
designer/administrator, most of them will tell you that referential
integrity is a must. However, I can't help but drawing parallel with
Python's dynamism. Sure, if you asked C++/Java programmer that have
never seen Python/Perl, they'll tell you that type-checking is a good
thing, that type-safety helps to eliminate tons of bugs during compile
time. All that may be true. But, in practice, a dynamic language like
Python is time-proven to show the fallacy that a strong-typed language
is a must. Can the same be said about database referential integrity?

I say it because I've been involved in a project with a few database
veterans that, to my surprise, dropped all referential integrity
requirements: no foreign key constraints. The dynamism achieved is
that you can version your data much more easily in the complex entity
relationships: your program can work with versioned data: if a client
submits old data, you work the old way, if client submits new data,
you work the new way, and the database tables achieve more longevity,
because versioning is built-in. New columns can be added...
relationships can be added/removed in future versions, and the program
will still work with the old versions, etc. Well, things seem to have
worked out pretty well.

So, could it be that database referential integrity (that is, things
like foreign key constraints) are there more like a tradition, like
type-safety idea of the strong-typed languages? Or is it jumping out
of this paradigm in favor of dynamism too drastic? Has anyone had
similiar experience/opinion to share?


Hung Jung

More information about the Python-list mailing list