[RESOLVED] Unserialize offset error

Staggy11

When unserializing an array from a MySQL database, I get the following error:

Notice: unserialize() [function.unserialize]: Error at offset 251 of 255 bytes in /www/htdocs/maptest.php on line 98

Does anyone have any idea why this is happening? is it something to do with the array becoming larger than the allowed size in the MySQL field?
I'm not sure what code I need to post, so just ask if you need to see certain parts.

Piranha

The problem is probably that you store arrays in a RDBMS. It is much better to normalize the database and store the information as separate posts. Unless of course there is some very special reason not to do this.

Staggy11

Ok, is there any way to determine whether or not I'm using a RDBMS? As far as I know, it's just a standard free MySQL database.

If it is a RDBMS, how would I go about normalizing it? Or is it a built in aspect? I had a search through Google and Wikipedia, but I must admit that most of it was gobbledegook to me.

As for specific reasons... I'm trying to create a base structure for a game, similar to Urban Dead, and each player has an array stored in a database that contains what they have heard, when they heard it, and who said it. Does this count as a special reason?

Piranha

RDBMS is short for Relationship Database Manager. More or less every database today is a RDBMS, including MySQL.

No, that is not a special reason. To give you an easy example, what if you want to see everything I have said? Lots of work with an array in the database, easy with a normalized database.

Try the article in phpbuilder about normalizing databases to understand it a little better. If you have specific questions after that please post them and I'll try to help you out.

Staggy11

Thanks for that link. The article was clear and useful.

Correct me if I'm wrong, but would the optimal system be to have 1 table for username, password, exp etc., another for email addresses (in case someone wishes to have multiple accounts under one email address) which would be linked to the first table via it's primary key ('emailID' or similar) and another table which would link to the first recording speech?

(Email table)-->[via primary key]-->(Main table)<--[via primary key]<--(Speech table)

I'm still unsure as to how I would then store speech in it's table. Would a serialized array, or an unserialized array, suffice? Speech is only recorded for people on the same 'square' as the speaker.

Piranha

You seem to understand the basics about database normalizing. What is right and what is wrong is up to how the information is going to be used, and how you decide to design everything. In your example with emails, will you allow only one email address or more? If you only allow one then it is perfectly ok to have it in the main table as well, if you want to allow more then it is correct to have another table to store it.

About the speech table I suggest not using an array. In the speech table you should have the information in different columns in the table, for example speech(what they said), when, who(a reference to the main table saying who said it). But one more question before designing it. Can more than one person hear what someone is saying? Like Staggy are saying something and I and Staggy11 can hear Staggy?

Staggy11

Yes. If you say something, then anyone and everyone on the same square as you can and will hear it. But only the people on that square will hear it, unless I implement a 'shout' feature or similar. So I guess that's another two columns, 'x' and 'y' to reference the location.

My main reason for storing speech as an array for each person was that each array could be purged of speech that had already been displayed for each player. But I guess that I could just remove any speech over, say, a week old every night.

So the table may look something like:

speechID|speech|time|who|x|y

Piranha

Well, it depends. What if a player move from one square to another. The things he heard before, would that be from the old square or the new square?

Staggy11

That's one of my worries. With the current system, the speech is added to everyone on the square at the time of speaking. Then, when someone who has 'heard' it refreshes the page, it is displayed. It didn't matter what square you were on when it was displayed, only what square you were on at the time of speaking.

Piranha

That's why the speach should not have anything to do with the square, it should have everything to do with the persons hearing it. By using a many-to-many relationship it is possible (and pretty easy) to get everyone to hear the same thing.

If you still need help please post the database design you have this far.

Staggy11

Okay, my design is as follows:

Table: Speech lists
Player.ID|Speech.speechID

Table: Speech
speechID|Time|Speaker|Text

Player contains the basic info about each user.
Speech lists contains, quite simply, a list of which player has heard which speech.
And finally, Speech contains the time something was said, who said it, and what it was that was said.

As far as I can see, this is normalized as much as possible.

Piranha

It seems to be normalized yes. And it seems like you get everything that you need as well with that design.

Staggy11

Thanks for the help. I'll set up the new system as soon as possible.