|
|
|||||||||
|
|||||||||
|
|||||||||
| |
|||
| |||||||||
![]() |
|
|
«
Previous Thread
|
Next Thread
»
|
Thread Tools | Search this Thread | Display Modes |
|
|
|
Stay one step ahead of the competition. Evaluate and give feedback
on some of the hottest web development tools on the market today.
Make your opinion heard! Click
Here
|
|
#1
|
|||
|
|||
|
Arrays in MySQL
Im currently setting up a database in which there are users, and then each user can have any number of codes. These are two seperate tables, each with private keys. I recently found out that it is impossible to store arrays in tables however (which would be the simple way to do this; an array of code keys in each user record)
The only other way I can think of to do this is to put a user key in the code records to represent the owner. However, this seems to complicate things a little. Is there any other way? |
|
#2
|
||||
|
||||
|
If you mean:
[table1] uid / user [1] user1 [2] user2 [table2] user_id / code [1] code1 [1] code2 [1] code3 [2] code4 [2] code5 [...] then you're ok. The only way to store arrays in one field is by using delimiters, ie: [1] code1,code2,code3 but you'll need more php to admin this, so go with relational. Check out the JOIN syntax. |
|
#3
|
||||
|
||||
|
It's true that one field can't really hold multiple pieces of data nicely, but I wouldn't say it's impossible to store arrays. You just need to handle the data a little bit differently.
Humanetainit has a great example above.
__________________
Daryl's Homepage | My Blogroll | My Profile | Firefox supporter! DevArticles Forum Moderator "The net is a waste of time, and that's exactly what's right about it." -- William Gibson |
|
#4
|
|||
|
|||
|
Quote:
yea, thats what Im currently doing. I was wondering if there was a simpler way, since this is pretty confusing. heres another problem Im having: I have an album table and a song table. each album has multiple songs and each song can be in multiple albums. Its a many to many relationship. Whats the best way to connect these? Currently, I have a string in each album that is a list of all the song ids in the album. |
|
#5
|
||||
|
||||
|
Administration of a normalized db is much easier, but SELECTs get more complicated and slower. The most important thing is to keep SELECTs as simple and fast as possible on the client (visitor) side. If this means that administrators need multiple UPDATEs or DELETEs, so be it.
Personally, I use heavy recursive functions containing SELECTs, something you can only do on a production server if you write the outcome to a file (server side caching). You might even use a database cache: copy your data to a database that is optimized for SELECTs, but administrate the normalized one... I've never tried it, could be a pain. Whatever you do, minimize database queries for your visitors. |
|
#6
|
||||
|
||||
|
Quote:
To satisfy the many-to-many relationship you are portraying... I would use a database structure similar to the following. Code:
ALBUMS ------ id, title SONGS ----- id, title, artist ALBUM_SONG ------------- album_id, song_id |
![]() |
| Viewing: Dev Articles Community Forums > Databases > MySQL Development > Arrays in MySQL |
| Thread Tools | Search this Thread |
| Display Modes | Rate This Thread |
|
|
|
|