I believe I need a database, but how do I start the process?

Are there standard questions that a competent db programmer will ask me?

[Webwork]

Since this is a request for "generic guidance" the subject matter for the database could be real estate, jobs listings, equipment for sale, event info, directory listing, etc. Assume that I can craft the HTML, CSS, graphics, site nav, etc. and that I'm "only" asking for guidance about the "interactive programming" issues, if that makes sense. ;) (If not, say so.)

I assume I need provide the following information to a database programmer:

• List of the data I wish to retrieve/store (name: first, last, middle initial; street address, etc.)
  
• List of "types of searches" I wish to enable (search by price, State, etc.)
  
• Security processes (password protection)
  
• Data expiration and storage upon expiration (archive?) requirements
  
• Payment processing info (if paid listings)

Beyond the above list I really don't know what basic or essential information I should have available to make the database programmer's job easier.

Is there information, common to the creation of most databases, that a database programmer needs to start the process? What is common?

For website development purposes are most/many database programmers able to not only craft the backend database but also the user interface? SQL + ASP.Net? PHP + SQL?

What information should I assemble before seeking the assistance of someone to develop a database driven website? Field names, queries, what?

Are there "frequently overlooked issues", that non-dbprogrammers fail to consider, when they first seek to "set up a database driven site"? (My non-expert way of describing what I have in mind.)

Forgive the multiple questions or several versions of the same. I really know little about what I'm asking for when it comes to asking a programmer to develop a database for me. ;(

So, I ask: How do I make myself a resource, not a hindrance, to the db developer?

Have all my questions already been answered or all the issues already addressed here: [webmasterworld.com...]

[linear]

One thing I want to throw in that I haven't seen come up yet: you should be prepared to discuss the usage patterns with the database guy. Some examples may help.

You say:
"This system is primarily driven by commercial transactions. It needs to handle an average load of 20 transactions per minute, and may peak to ten times that volume. The users are expecting instantaneous confirmation of transactions, so response time is a consideration."

The database guy hears:
"The usage pattern is biased toward INSERTs. INSERT performance under load will be a critical performance metric."

You say:
"This system is mainly for content management. A team of six authors will add articles on a relatively infrequent basis using a set of screens built for the purpose. Catalog pages and articles will be built out of the database dynamically."

The database guy hears:
"Usage biased toward SELECT statements. INSERT will be comparatively rare and not performance-critical since it's not public-facing."

You say:
"We import between ten and twenty thousand customer records each night from a different system. That system finishes its batch job between midnight and oh two hundred most nights. Users expect the system to be up by oh seven hundred. Once a quarter we update all 1.2 million customer records with a different batch feed. We can run that job over a weekend, but we have to lock users out of seeing their balances until it's done."

The database guy hears:
"Batch loading performance is normally important but not critical, and may be a problem for the quarterly loads. This has specific index implications for the tables holding the relevant data."

You say:
"We need to keep a five year history of all transactions for regulatory reasons. We aren't allowed to aggregate those. The users expect to be able to query aginst history with reasonable performance, but it isn't something they do daily."

Database guy hears:
"At least one table is going to grow absurdly large. Without careful attention to the history queries, performance is headed for the dumpster. Backups and restores will take forever."

...and so on. The main thing is that you need to be able to describe patterns of usage, and service level expectations. The database individual should be recommending specifics based on those requirements. Anyone who's been at this a while will have fallen into a lot of traps and be eager to avoid them in the future.

[imstillatwork]

Mysql will do most of what one needs and the query language, though not as powerful, is easily learned and even, dare I say, mastered.

Getting much, much, much better with every release.

subqueries are pretty much not an issue with MySQL anymore now either.

[AranhaHunter]

Hmmm just out of curiosity, how would one implement that DATABASE ADMINISTRATION GUI in the real world? I remember in class, we had a "secret" page where we granted permission the administrators that logged in (and they also saw different pages depending on their status, with more or less privileges). I'm just wondering if in the real world, it'd be the same way