Forum Moderators: coopster
Could you give me some real advice on this situation. I have loads of tutorials & books on this, but I'll still need some guidance from developers. Let me briefly explain the situation...
The purpose of the site is to sell audio clips/tracks, that have been produced by my studio. Each audio file is 30 seconds long, and is in .mp3 & .wav format. As I cannot afford a merchant account at this time, all payments will be made either through PayPal, by cheque or by money order...
Here is the idea I had when creating this table. Can you tell me if I am in the right direction or what you would do differently?
COLUMN
--------------------------
ID
DATE_INPUT
INVOICE/REFERENCE NUMBER
LINK TO .MP3
LINK TO .WAV
LINK TO PRICE
LINK TO PURCHASE OPTIONS
* The purchase options link would extract the the price, invoice/reference #, and date input into the system to a checkout screen with an option for PayPal, cheque or money order.
1. What vital element(s) am I missing in the list above?
2. Is there any reason that I would want to use more than one table to
accomplish this? If so, what elements should be accounted for in each
table.
3. Since there is no actual invoicing system yet, do you suggest that I
randomly create an invoice # for each sample, or use the auto-incrementing
ID column to give each sample a reference # to order by?
I'm looking for the best options as this is a simple application, but one I do not have much experience.
Thanks, any and all help is appreciated.
M
2. one table should be just fine as long as all of the columns relate to the object they define. In this case it is your media file and all they need to function.
3. Having said the above, you need to decide how to do the invoicing. If you are going to buy something then you need only to store the absolute base data, though you will need to decide what that is.
You could also do all of the invoicing in this db also. You would probably need a table for user data and then a table invoicing. Invoice table could have an auto increment id that is used as your invoice number (seed this, you dont want your invoice ids starting at 1 ;)). You could also have the id's of the products and a user id.
Then you would need to see if you even needed a user table. Are users going to need to be logged in to make purchases?
something like that, nothing is absolute and you know your system best.
I was thinking of just creating an invoice# for each sample, for example, if it was the eighth new track loaded on January 1st 2005, I'd say the invoice# was 010105-8.
Seems like it would be easier to have the database create random invoice#'s or possibly generate new invoices by incrementing the values. But at least my arbitrary date invoicing system is logical.
Seems like it would make my life easier to put all of the data in one table, perhaps making a user table to collect customer information right before purchase
Any other thoughts on invoicing or using multiple tables for such a small app.
Also, say we wanted to list the same song writer 50 times, maybe the authors name should go in separate tables as to not have to repeat the same information over and over in the table...
though you may need a few data conversion scripts to do it.
You really need to think through what you need now and then also try to foresee what might be an option in the future. Then you can design now for ease of use in a small app and leave yourself avenues for expansion as it grows.
nothing is forever so don't drive yourself crazy trying to make it perfect. The beauty of the web, and the apps that live there, is it's fluidity things continue to change and grow. Just don't design yourself into a corner from the beginning.
