[SOLVED] Storing objects in MySQL

[NewBob]

Hi!

 

(not sure where to put this topic, here or in the "MySQL section)

 

Background: I'm trying to design a simple php game just to put my newfound OO Modeling and Design skills to the test.

Since I'm going OO all out there will be alot of classes and many objects will contain arrays of other objects which in turn have attributes that I will need to store somehow.

I've worked with MySQL and PHP before when creating a calender and a login system, but at that time I didn't even realise that PHP could be used as a OO language.

 

Problem: How do I store objects in a database that aren't of any primitive type.

How do I store objects that contain other objects?

 

I thought about giving each class a function called "storeMe" or something which returns an array or string of the attributes. That would require another function "restoreMe" to rebuild all the info again. However, I was hoping there would be an easier way.

Also, is it possible to store pictures in a MySQL database?

 

 

[trq]

You'll want to serialize prior to storage, then unserialize upon retrieval.

[Eric_Ryk]

You'll want to serialize prior to storage, then unserialize upon retrieval.

While that is an option, I don't think that's the way to go about it.

 

Rather than doing it like that, you should simply create a table FOR the object and put the properties as the fields. If it connects specifically to other objects, then you create a table for those objects properties and you add a field to link them.

[roopurt18]

I second the serialize / unserialize method.

 

First off, to the OP, you have the right idea about the storeMe and restoreMe methods; a similar mechanism has to be used in languages like C++ where you want to write an object to disk when the object is derived and has virtual methods and all that.

 

@Eric_Ryk, I certainly see what you're saying but that implementation depends on the task at hand.  By taking that approach you will need to modify your database structure every time your object structure changes, which can be quite frequently, especially at the early stages of development.  Second, you only need to store columns matching data that you plan to search over; so if you are storing properties in columns that you never use in your queries, you are just creating extra work for yourself.

 

I recently dealt with this issue myself.  I created a form that allows users to build a questionnaire with different question types: open-ended text, open-ended paragraph, multiple choice-select one, multiple choice-select many, and two types of rating scales.  Different question types require different stored data to reconstruct them and make sure the answers follow the appropriate rules.  I contemplating creating an overall table for the questions and their order and then another table for each question type to store this data.  In the end I decided it wasn't worth the trouble and used serialize and unserialize.

 

I do use tables with more appropriate columns to store the answers as I need to perform searches and analysis on them.

[NewBob]

Thanks for all the help!

 

Why don't you guys like the serialize/unserialize method?

By making my own store/restore functions it feels I'd be reinventing the wheel.

I tried the serialize function:

echo serialize($object);

which gave a string that looked a bit like I imagine the string from my functions would have looked like.

Is there some drawback I've missed.. or does "I second the serialize / unserialize method." not mean that you don't like it?

Hehe.. newb at both programming and english 

[roopurt18]

"I second the blah blah blah" means "I agree"

 

Both methods are viable strategies for what you want to accomplish.  It is up to you to determine the needs of your application and choose the best approach.  That is why I gave you the example of what I did in my own program; in that example I used both approaches, each where it was most appropriate.