PointCounterpoint PLSQL code storage

Question:
A recent conversation with a DBA friend of mine turned into a debate on what is truly the "best practice" where PL/SQL code storage is concerned. I took the position that all PL/SQL should be stored in organized, subject-specific packages in the database. My DBA friend took the positiont that all PL/SQL code should be stored in text files in Unix and run through SQL*Plus when needed.
I debated that with the code in the database you gain efficiency, that the integrity of the code is maintained because of database dependencies causing your packages to go invalid upon database changes, and that I can easily search through code using simple SQL against user_source.
My DBA friend argued that code stored in the database does not handle failover well and that storing code in the database creates security holes.
Which side do you take in this debate?
Answer:
Rick, I will skip my opinion in this case and go right to my practice: I always work from files in the operating system. I will make changes to code in the database when I want to test out some ideas or do some quick tracing/debugging, but other than that, I am a "Files First" developer all the way.
Specifically, I store package specifications and bodies in separate files, using .pks and .pkb extensions. I can then use virtually any version control system to manage my code.
You make a great point about using SQL to query the data dictionary to extract information about your code. That can come in very handy, especially when checking the contents of a view such as ALL_DEPENDENCIES. The value of a query against ALL_SOURCE, however, is a bit less clear when compared to the capabilities of a professional programmer editor that lets you search through entire directories on disk and offers lots of search options.
Now, to be fair, one of the reasons I find myself relying on files and not the database for my "original" is that I generally write code to be distributed to programmers around the world. If I were writing an application that was used only internally (the modus operandi of many, perhaps most, programmers), the option of working from the database might be more attractive.
Of course, a key question in any development organization is how to manage change in the code base. You will almost certainly be using version control software, and this fact could easily force your hand as to where to keep the "original" of your code.