I have been looking over this suggested outline for a database. One of the requirements is as follows:
What is searched can be saved either on the users hard disk or floppy disk as desired in the form of text, database or HTML.
The bit about saving the results as a new database on a seperate file system sounds kind of strange to me.
I am considerng using a combination of MySQL and PHP to develope the DB. Using PHP it should be pretty easy to save query results as text or HTML files, but what about a database file?
Obviously they are talking about a database external to the one in use.
Is there such a thing as an universal database file format (i.e. a file format that can be read by any database? Is it possible to use PHP to produce such a file?
The DB should have the following functions: Add, Revise, Delete, Search by keyword, Turn page.
What is "turn page"? Is this a technical term commonly used by database developers? I have never heard of this one before.
Seems like saving a file to a user's disk as an actual database wouldn't make much sense - no way to know if the user has an appropriate front end to access it. But perhaps you could interpret it to mean the output could be saved in a tab or comma delimited file that a user could then import into any number of applications.
I don't know that Turn Page is a technical term; more than likely, that requirement means the user should be able to view results in pages of X records per page, with the option to move from page to page in the result set.
That's how I'd interpret those requirements, anyway. I'd actually double-check what was meant by 'saving as a database' as that might be a user wanting something that isn't feasible and/or not really the best idea.
I agree about making sure your client knows what they are saying. It is not uncommon for someone to misuse terminology.
But, If you need to actually save to another DB, then, you can actually script a "database-on-demand" stored procedure. With MSSQL, you can create a new DB with (perhaps with the name based on the SPID, like what happens with a #temp table), and do a cross-database insert statement from the sourcedb to your *newly created* destinationdb. Or, instead of creating a real DB, you can create a global ##temp table.
As for saving to another medium you might also want to look into XML. SQL server 2000 allows you to return results from sql queries in XML format by specifying the "FOR XML" clause after a select statement. It is pretty easy to get it to text (ie, csv, txt) from ASP, as well.
Finally, if the client just wants to be able to retrieve the results from an ad-hoc query at a later time, you can save the SQL statement and issue the command later on demand. Of course, the results will be different, unless you have a data warehouse, where data can be retrieved from a specific point in time.
Of course, your choice is contingent on how your client responds. Make sure they know what other options are avail. Because, creating a new db is quite a strange requirement.
As already mentioned your client is being a bit wishy washy in their requirments. If this is the Requirements specification get them to sort it or you will end up interpreting something one way and they will have meant another.
Do not try and apply common sense to a requirements spec, although you may be correct you are just as likely to be wrong. A lot of specs are written by people who are trying to describe what they want from other applications that they have used and hence the vague terminology. If I said I want to toggle between insert and command mode using an escape, for any vi/m users out there they will know what I mean but what about everyone else.