It is my experience that Project Managers neither care, nor need to care, about creating new databases. They should hand you project specs with just enough functionality (formulas, etc.) that tells you want the business wants to get done. And it is your job as the developer to make sure it's accomplished.
Bottom line: They shouldn't be requesting new databases. Only developers, DBAs, data architects can or should be involved in the "we need a new database" decision.
That being said, if you're still going to let business people dictate your architecture, I would include the following:
Type of Database (reporting, warehouse, OLTP. Is it mainly read or write? This can affect # of files and file groups)
Where it Fits (is it in the DMZ, internal only, what apps will be connecting to it)
User / Security (if this isn't self-explanatory, let me know)
Collation Type & Other DB Options needed (if this isn't self-explanatory, let me know)
Initial Number of tables
Table Structures (this is where you need a database architect or a DBA pretending to be one)
Initial Expected Records for Each Table (this gives you starting size of the db)
Expected Growth Over X period of time (this gives you how much SAN / NAS / HD space you'll need)
Latency Expectations (if this is a warehouse or report server, how long can people wait between data updates)
Availability Expectations (24x7, 5 day business hours only? Determines Backup/Recovery strategy, maintenance windows, Disaster Recovery builds)
Data Loss Expectations (How much data can be lost in the event of a catastrophe - Determines Backup/Recovery strategy)
I'm sure there are more, but you get the idea. After all, if they're going to dictate, they should be able to dictate all of this stuff and not give you a blank look when you ask.
Brandie Tarvin, MCITP Database AdministratorLiveJournal Blog
, and Twitter
.Freelance Writer: ShadowrunLatchkeys: Nevermore
, Latchkeys: The Bootleg War
, and Latchkeys: Roscoes in the Night
are now available on Nook and Kindle.