MySQL Array

Easy.

Just concentrate the array into a single string separated with a certain character (like ; or : or some other shit) and then just split it up on the server side (use the explode function if you use php.)



[edited by - aftermath on December 27, 2003 12:32:25 AM]

Isn''t there a cleaner way to do it?

------------------------------------------------------------
TimothyBarnes.net loves you

I don’t know if there is a way to store arrays on a MYSQL database. I think MSSQL can do it ... but I will never try that crap.

Just do a good search for ``mySQL array.''

Most of the applications that I worked on do database arrays like this. This is not very dirty at all .. as one might not think.

Look at any other large-range software product that uses MySQL, they do it that way (and yes, I have looked.)

[edited by - aftermath on December 27, 2003 12:35:54 AM]

I''ll probably just end up using another table...

------------------------------------------------------------
TimothyBarnes.net loves you

(i''ve never done this)

...

Just crosslink tables.

In one table, have the identification (through ID integer) of a row in another table to where the array is.

And in that other table, you store the array data and have one column hold the ID of that array (cross-referenced from the original table.)

I hope you are using phpMyAdmin too.

phpMyAdmin doesn''t seem to work on 1and1.com for some reason. Anyway I''m thinking of doing it that way. If not, then I''ll stick to the array idea, but its way too unclean for the amount of data that I''m going to have.

------------------------------------------------------------
TimothyBarnes.net loves you

What I want to know is how the second guy assumed PHP ... MySQL can be used for many different things (such as my C++ proggy I''m making). Anyhow, look up enum, mysql has an enum type I believe.

#1 - PHP, MySQL and Apache is almost a single word.
#2 - Everyone knows I don''t use C++
#3 - aftermath was probably smart enough to have checked out my site and noticed the usage of PHP
#4 - PHP owns

------------------------------------------------------------
TimothyBarnes.net loves you

you're basically trying to create a multi-value attribute, which according to good dbms design is a big no-no. Use another table or I'll beat you.

so, you have a table, say it's USER, and each user has an IDNUMBER which is the key and *you* want to store the TRANSACTIONS (notice the plural, multivalued).

There is a concept in DBMS design called "1st normal form", in which you adhere to certain guidlines while designing your tables. There is also second, third and so-on normal forms, that represent gradually less strick guidelines. The lower the normal form, the less chance of data inconsitancies.

1st normal form includes having NO multivalued attributes.

You should have two tables, USER and TRANSACTION. USER with have a public key ID_NUMBER, and TRANSACTION will have an attribute VALUE and a foreign key USER_ID to USER.ID_NUMBER. You could also include a primary key TRANS_ID for transaction, but it's not necessary. If you don't include it, the primary key for TRANSACTION will be USER_ID + VALUE.

[edited by - capn_midnight on December 28, 2003 6:28:59 PM]

Programmer One == nes8bit?!?!?

quote:

---

Original post by Axiom
Programmer One == nes8bit?!?!?

---

that''s what I was starting to think....

haha there was just a close topic called ''goodbye nes8bit'' (or something like that) that proposed P1 and nes8bit were the same people. It was really old, though. So I''m starting to think...

quote:

---

Original post by circlesoft
haha there was just a close topic called 'goodbye nes8bit' (or something like that) that proposed P1 and nes8bit were the same people. It was really old, though. So I'm starting to think...

---

well, we know they are both tiberians. And they have the same signature. And they have their own communist icons.

btw, where in PA do you live?

[edited by - capn_midnight on December 28, 2003 6:47:12 PM]

quote:

---

Original post by nes8bit
#1 - PHP, MySQL and Apache is almost a single word.
#2 - Everyone knows I don''t use C++
#3 - aftermath was probably smart enough to have checked out my site and noticed the usage of PHP
#4 - PHP owns

---

Yeh .. PHP is freaking awesome.

Especially is its PHP, mySQL, PEAR::DB, and Smarty combined .. that is just plain sweetness eliteness man. I cannot express the feelings I have for PHP and the team. It''s thats amazing.

quote:

---

Original post by nes8bit
#1 - PHP, MySQL and Apache is almost a single word.
#2 - Everyone knows I don''t use C++
#3 - aftermath was probably smart enough to have checked out my site and noticed the usage of PHP
#4 - PHP owns

---

#1 - I guess so, they complement each other very well, but I wouldn''t go as far as refering to them by a single word.
#2 - I ... did not know that.
#4 - Indeed it does, I use it all the time for webdesign.

PHP!!



The damn image output function is so slow, though... pft...

quote:

---

Original post by capn_midnight
well, we know they are both tiberians. And they have the same signature. And they have their own communist icons.

---

I''ve seen them both there at once, so I doubt it...

I couldn''t tell you for sure though. I don''t spend much time there.

quote:

---

Original post by capn_midnight
you''re basically trying to create a multi-value attribute, which according to good dbms design is a big no-no. Use another table or I''ll beat you.

so, you have a table, say it''s USER, and each user has an IDNUMBER which is the key and *you* want to store the TRANSACTIONS (notice the plural, multivalued).

There is a concept in DBMS design called "1st normal form", in which you adhere to certain guidlines while designing your tables. There is also second, third and so-on normal forms, that represent gradually less strick guidelines. The lower the normal form, the less chance of data inconsitancies.

1st normal form includes having NO multivalued attributes.

You should have two tables, USER and TRANSACTION. USER with have a public key ID_NUMBER, and TRANSACTION will have an attribute VALUE and a foreign key USER_ID to USER.ID_NUMBER. You could also include a primary key TRANS_ID for transaction, but it''s not necessary. If you don''t include it, the primary key for TRANSACTION will be USER_ID + VALUE.

[edited by - capn_midnight on December 28, 2003 6:28:59 PM]

---

Heh...Well at least I know how to comply with the standard. This question will come up again because I know I''ll need to do something like this again on a much smaller scale.


cowsarenotevil:
silly cow, tiberia doesn''t exist. So stop talking about it, nobody wants to hear your stupid paranoid ramble about this "underground society"

------------------------------------------------------------
TimothyBarnes.net loves you