<p>I am currently creating a master ddl for our database.  Historically we have used backup/restore to version our database, and not maintained any ddl scripts.  The schema is quite large.</p>

<p>My current thinking:</p>

<ul>
<li><p>Break script into parts (possibly in separate scripts):</p>

<ol>
<li>table creation</li>
<li>add indexes</li>
<li>add triggers</li>
<li>add constraints</li>
</ol></li>
<li><p>Each script would get called by the master script.</p></li>
<li>I might need a script to drop constraints temporarily for testing</li>
<li>There may be orphaned tables in the schema, I plan to identify suspect tables.</li>
</ul>

<p>Any other advice?</p>

<p>Edit: Also if anyone knows good tools to automate part of the process, we're using MS SQL 2000 (old, I know).</p>

What you have there seems to be pretty good. My company has on occasion, for large enough databases, broken it down even further, perhaps to the individual object level. In this way each table/index/... has its own file. Can be useful, can be overkill. Really depends on how you are using it.
@Justin
By domain is mostly always sufficient. I agree that there are some complexities to deal with when doing it this way, but that should be easy enough to handle.
I think this method provides a little more seperation (which in a large database you will come to appreciate) while still making itself pretty manageable. We also write Perl scripts that do a lot of the processing of these DDL files, so that might be an option of a good way to handle that.