Search the Community
Showing results for tags 'architecture'.
-
Right now I'm working on a website for a record label. I need to write a script that switches between bands and pops band info based on user selection. If it was just PHP, the fields would be: string (band photo; url src to an img), an array of strings (streaming music; multiple url src to mp3 links), string (duration; this one is actually two dates that represent a span of time), array of strings (players; key & value pairs that represent band members and what they do in the band, i.e. drummer, bassist, etc.), string (band bio; it will need to be a couple paragraphs). Since I need to store this information in a database, I am first planning the structure for the table(s) that I will need to create for this. For now, I have three areas of concern. 1. Regarding the arrays, if the absolute max number of key/value pairs is ten, is it okay to store those in a single field? Or should I create another table and make a compound key to reference the main band table? 2. I plan to use either blob or text field for band bio. Any tips you would like to offer about those two data types would be helpful, though I will be doing plenty of reading about them regardless. 3. As for duration, can anyone think of any reason I should actually break that into two date fields? I don't think there will ever be a reason to run any calculations on how long they have been together, so I am thinking a string will be fine. If you disagree with that assessment, I wouldn't object to hearing your reasoning. Any input you can offer would be greatly appreciated!
- 6 replies
-
- architecture
- best practices
-
(and 1 more)
Tagged with: