Get involved with the development process

I recently was involved with a production database performance problem that was narrowed to a problem with some code that had just been implemented days before. It seems that new records placed into a certain table go through a process where a five-digit alphanumeric 'unique' key is generated, then the table is searched to see if the 'unique' key already exists. If it does, an new 'unique' key is generated and searched for again. This process happened 800-2000 times for each record. With about 200 users in the system, you can see how quickly this ridiculous process became unmanageable. This process is so illogical, that even non-DBA's shook their heads when it was described to them.

No DBA, no matter how unseasoned, would allow code like this into a production environment without questioning it. How about using a database sequence to generate truly unique keys? Or using the dbms_random procedure? It became apparent that no DBA was involved in the development process. The lesson here is that if the application is placed on top of a database, there needs to be a DBA resource involved in the development process from the beginning. If you are a DBA in this situation, get involved or learn to spend most of your time cleaning up messes like this.