I don't maintain a table-create script

Monday, June 5. 2006

I don't maintain a table-create script

I've never had the intention to question whether must we maintain a master copy of table-create script for database until I have to in charge for it. When I was assigned the role as a DBA for the project I'm working on now, I intended to gather all the developers on the team and make the centralized control of database schema modification process known to everyone of them. But somehow I hesitated to do so, I decided to seek for professional advices before defining any procedure. Finally, I got this advice which I couldn't agree more from a DBA (a real DBA) at U.S. who's maintaining and administering a set of large scale databases:

Table definitions are stored in the database, so as long as you have a good backup of the database, no reason you really need to maintain table-create scripts

He told me this via IM and has unknowingly given me a big relief. Of course he also guided me with some useful built-in functions like dbms_metadata.get_ddl to help me to achieve my goals.
Since then, I've decided to rely on what Oracle's already offering rather than performing the schema control manually by myself. So that I would have more time to do something more meaningful like performance tuning when necessary.

Posted by Steven Yong in computer at 15:05 | Comments (5) | Trackbacks (2)

...

Trackbacks

Trackback specific URI for this entry

Why do you upgrade your DB?
Just had a little chat with the database administator I mentioned in previous post and we discussed about the reason of upgrading Oracle DB, generally from 7 to 8i or from 8 to 9i. I told him that I did not actually use any new features of the newer ver

Weblog: Steven Yong's Weblog
Tracked: Jul 08, 00:45

I don't maintain database scripts, part 2
In previous post I talked about how to use the DBMS_METADATA.GET_DDL() function to obtain the data definition of tables and indexes. But as you know there are a few more types of object which are considered as important as table, like user-defined funct

Weblog: Steven Yong's Weblog
Tracked: Jul 10, 12:19

Comments

Display comments as (Linear | Threaded)

Good point.

The only time I did a table create script was when I had to package a software in a installable (i.e. off-the-shelf-software) where you will need to at least create the database and tables first before loading in the data.

Otherwise, database backup would suffice.

#1 Angie Tan (Homepage) on 2006-06-05 19:43 (Reply)

I look at this similar to the argument between having design doc and source code. Everything is inside the source code and is always the latest, then why you still want to maintain the design doc ? You already have the database, why still need the script ?

So it all depends on who is looking at it from which angle. No right or wrong answer.

#2 MK on 2006-06-09 13:11 (Reply)

MK, the target audience of design doc is developers and it is (somewhat) necessary, but i couldn't think of any audience for the db script.

#2.1 steven (Homepage) on 2006-06-10 16:04 (Reply)

Well, the user actually will have for the DB Script included in the User manual... Instead, they will ask for more... They even want ER Diagram with cardinality...

Prepare for that for UPM...

#3 Eric on 2006-06-12 16:26 (Reply)

For a DBA, a db would suffice. However, what if someone joins in tomorrow and he needs to look at the table structure to understand the application?

What if another DBS comes in? Scripts are tedious, complicated, a bore to maintain etc etc etc, but one cant deny that they do come in useful at times.

#4 Veena (Homepage) on 2006-06-15 18:25 (Reply)

Add Comment

Name
Email
Homepage
In reply to
Comment	Enclosing asterisks marks text as bold (word), underscore are made via _word_. Standard emoticons like :-) and ;-) are converted to images.
	Remember Information? Subscribe to this entry