Page 1 of 1
Object -> Table(s), Table(s) -> Object
Posted: Sat Jul 10, 2004 10:59 am
by xandor
I'm playing with the concept of writing objects to (mysql) tables, and vice-versa. Curious to see how this has been done by others, and having trouble finding examples. Note that this is not to merely archive the objects ((un)serialize() with files would easily do that), but to actually use them dynamically within the database as well as within my code (as objects).
E.g. I have a DBObject which manages the database connection resource (etc.) and I've written the beginnings of a "storeObject( $anObject) " function which creates the table with appropriate columns, etc. Gets tricky when "anObject" contains, say, an array of objects or, (maybe worse) an array of arrays. I want to maintain the sql design integrity as much as possible.
As I say, just curious to see examples of implementation (must be several..).
Posted: Sat Jul 10, 2004 12:16 pm
by Weirdan
Seems like the new wave of the OODBMS implementation attempts....
Posted: Sat Jul 10, 2004 12:25 pm
by xandor
No, I think an oodbms is another animal altogether.
I'm talking about a plain, vanilla, sql database (as I said, Mysql in my case), and how to best represent objects within it.
There must be plenty of geeks who have done this already, no?
Posted: Sat Jul 10, 2004 12:26 pm
by kettle_drum
I really dont see how you could ever manipuate them while they are in the database when using serialize to store them as it just flattens the instant variables into a single string which you cant really manipulate - and with good reason too. The class that the object is created from should be built to handle modification/setting/retreiving of the instant variables - its the whole point of the object - to surround the data and handle access to it.
If you want to store an object in a database then you can, as long as you retrieve it and use it to re-create the object.
If your trying to manipulate an object in the database, then your just manipulating the instant variables of that object:
Code: Select all
some_database_table (
var
var2
var3
var4
)
Which is just the same an manipulating any other data, so i dont see why you need it to be stored as an object. You can just make a class that grabs the data from the database and you can then create an object thats data has been stored in the database.
Back to storing objects now. If you want to manipulate the data in the database you need to make your own version of serialize that uses get_object_vars() to get an array of all the variables in a given object and then you can store these values in the database.
Does that make sense or help?
Posted: Sat Jul 10, 2004 12:46 pm
by xandor
No, as I said, I am NOT using serialize for precisely the reasons you mentioned. Like serialize(), I of course need to have the object definitions available before I attempt to re-generate the objects from the db.
And I am indeed using the same track you're referring to ( using gettype() ). Basically, I have a table named after the object class created with each of its columns named (and typed) for each of its variables. This I have already created the code to accomplish. The tricky part I am wrestling with currently, specifically, is how to handle arrays or other objects contained WITHIN an object (I'm not talking about inheritence here, BTW). I have a few ideas, but I'm curious as I say to see how others have approached it.
I'm beginning to wonder if my assumption about many others having already wrestled with this being incorrect. Seems like a pretty obvious need, though...
Posted: Sat Jul 10, 2004 1:03 pm
by kettle_drum
Well i would just have one table with an id and text field. Then any object data you want to store you give an id to and then store the data as a long string in the text field like so:
var_name=data_type="value"|var_name=data_type="value"|var_name=data_type="value"|
Then instead of a value you can referece another record in the table:
var_name=data_type=REF#34|var_name=data_type="value"|
Posted: Sat Jul 10, 2004 1:22 pm
by xandor
Yes, I was thinking of something similar to that, but since I want to maintain database integrity, I wouldn't want to store a bunch of variables as a string.
I was thinking along the lines of an intermediary linking table that would contain the id of the (main) object along with id's of any enclosed objects or arrays (each of which might be in a separate table).
I appreciate your input, kettle_drum, but wonder whether YOU might know of any examples of this that people have actually done!
Posted: Sun Jul 11, 2004 3:50 am
by kettle_drum
I dont know any examples of it in php, but what you doing should work fine so just carry on doing it.
Maybe by making all classes inherit from a single class: objectManager, things could be better controlled as one table in the database would be the root for all objects. objectManager would just need to hold the references to any object that is its child, and then all classes below would just need to hold the data and 2 extra fields for parent and child. You should then be able to easily be able to do it.