Object Driven Databases?

[Attilitus]

Is there really any reason not to use an object driven database system? It is of course unfortunate that PHP does not permit full serialization of class methods (but a simple class in itself could easily remedy this problem).

 

What are your thoughts on object driven databases? I am curious as to whether or not anyone uses them.

[Jenk]

Do you mean Object Relational databases?

[Attilitus]

Ah, yes. My mistake on terminology.

[Jenk]

They do have setbacks. If your database (and it's tables) is used by multiple applications, you will stumble into compatability issues, where as an RDBMS maintains a standard interface (in MySQL's case.. SQL.)

 

Other issues involve efficiency, when using custom data types (i.e. your objects) it can be difficult to actually search for an object (if you don't use a standard type ID.) The quantity of data can sometimes be an issue, too. It will always require more space to store full objects than it will to store the properties of those objects in their own fields.

 

 

[Attilitus]

Hm, I thought about it for awhile, and I cannot see how there could be compatability issues when storing objects in the database.

 

The serialized object is simply text, I would imagine that any database framework that has compatability issues with accepted serialized text would have greater troubles than mere object storage.

 

Am I totally off base on this one?

[448191]

I don't think Attilitus is talking about an ORDBMS.

 

An ORDBMS simply allows custom data types, and allows 'joining' of tables in an OO way (that is if I understand the theory correctly, I don't have any practical experience with it).

 

He's talking about serializing objects and letting an ORM system handle their relations, something that could be made RDBMS independant using a DB abstaction layer.

[Jenk]

I think you're right.

 

I've always preferred robust object property management and DB design over just serializing objects.

[Attilitus]

Hm... so would a serialized object driven database (A relational database that inputs serialized objects) be a feasible and practical way of managing data storage? It would really open the door for some incredible power if it could be fully embraced.

[utexas_pjm]

I see alot of problems with storing data in this manner.

 

Consider the follwoing example:

 

I am working with widget objects.  Every widget has a name and a value.

 

In a traditional rdbms setup I can issue a query like this:

 

select name, value from widgets where value > 100 AND value < 1000

 

In the setup you're proposing you would have to run something akin to this.

 

<?php

//...

$sql = 'select id, object from widgets';
$rs = $db->query($sql);
while(!$rs->EOF)
{
  $obj = unserialize($rs->fields['object']);
  if($obj->getValue() > 100 && $obj->getValue() < 1000){
     $result[] = $rs->fields;
  }
} 

// ...

 

So you've just introduced an order of magnitude time complexity into your code.  Consider the case where you have n = 10^6 widgets, your search will be linear (O(n)) where as MySQL could return the result to you (assuming the value column was indexed) in something closer to O(log2(n)).

 

Perhaps I'm missing something here, but what benefit do you see from storing a serialized object in a database as opposed to creating these objects from resultsets a la...

 

<?php
// ...
$sql = 'select name, value from widgets where value > 100 AND value < 1000';
$rs = $db->query($sql);
while(!$rs->EOF)
{
  $obj = new($rs->fields['name'], $rs->fields['value']);
  result[] = $obj;
} 

// ...
?>

 

Best,

 

Patrick

[Attilitus]

Well what if you want to store in a user's username field that their name is Jim except on sundays when it is Suzy.

class username{
function outputusername($day){
if($day==sunday){
return $this->sundayname;}else{
return $this->otherdayname;}
function setname($day,$name){
if($day==sunday){
$this->sundayname=$name;}
}
//to output name
$date=fetchdate();
$username=$db->fetch_username($user['userid']);
echo $username->outputusername($date);

//setname
$_request['day']=$day;
$_request['name']=$name;

$usernamesettings=&new setname($day,$name);
$serializedusernamesettings=serialize($usernamesettings);
$db->set_username($user['userid'],$serializedusernamesettings);

 

Now this is a poorly coded pretty useless example. But what it does it changes the way you can store information in the database. No longer does the dynamic information need to be contained in the script, rather the storage of information itself can be dynamic. You can store "ideas" rather than the rote data.

 

I don't know... as I said I am not actively using this (yet), but it certainly seems pretty cool to me.

[utexas_pjm]

rdbms counter example:

 

tables:

 

user {userid}

day {dayid, dayname}

username {userid, dayid, username}

 

select u.userid, un.username FROM (user u LEFT JOIN day username USING (userid) ) LEFT JOIN day d USING (dayid) WHERE u.userid = '1' AND d.dayname = 'Sunday'

 

This works while still allowing you to make use of your database manger's query indexing.

 

Patrick

[Attilitus]

Although certainly you could do that (provided you had a cron script change the DAYID such tasks as that example are the conceptual reasoning that I am considering when thinking about storing objects. You could also just use IF statements throughout the script if you like.

 

Anything that you can do with objects in the database, you can do with regular relationally stored information, but sometimes you have to make significant workarounds in order to achieve it. For example in your case you would need a cron script to change the DAYID of the user field. A better way to relationally handle it would be to simply make the username field an array and select the date based on the # of the day. (Or just use lots of IF statements in your script )

 

There is nothing "simple" that would benefit from something like this... but imagine something more complex like saving an instanced event like a graphing calculator session. You could feasibly input a database field for the formula, the x,y positions, any settings that were activated, ect. However, then you need to start re-operating on it again under the same framework as before. You need to query all the settings for that one unique session, and then do (new classname) and somehow reassociate all that information (probably by making an array and making your class accept array values on initialization) back with the class.

 

It can be done, probably without "too" much pain. But why not, in that kind of situation, just serialize the object and call it back when it is wanted using:

 

$storedobj=db->select_object($id);

$obj=unserialize($storedobj);

 

This is only relavent with someone already using OOP coding practices, but it is a kindof cool way to "think" about coding itself. You make a "new session" and then store the entire session as a single entity.

[utexas_pjm]

I don't think I'm stating my point clearly.  I don't see anything wrong with serializing objects per se, however you gain absolutely nothing from storing serialized objects in a relational database.  Once you insert your objects into the database you are now the proud owner of a glorified hash table.  That is, you can access every object in the database in constant time, assuming you know the hash (in this case an id).  What happens the first time you want to access an object or a set of objects based on something other than the primary key?  You do this:

 

SELECT everything from the database. 

Iterate through every object and unserialize them.

Perform conditional check on each object's member data.

 

So let's examine an extreme case, you have 10^6 widgets.  You know nothing about the data.  3 of the widgets have a value greater 100.  You want to do something with these 3 widgets.  So you select 1million records from the database.  You un-serialize 1million objects, and you make 1million comparisons.  I would deem this kind of performance unacceptable.  If you insist on serializing all of you perisistant objects why not just store them all on your disk with their ids as filenames?  You will still have random access in constant time with out all of the overhead of a rdbms schema.

 

Please don't take this as an attack on your idea.  Object Oriented Databases (http://en.wikipedia.org/wiki/Object_database) have their place and under the right setup are very efficient.  The difference is, OO databases are constructed in such a way that they know something about the objects they're storing.  Where as in your example the rdbms is storing, from it's view point, arbitrary BLOBs.

 

Best,

 

Patrick

[Attilitus]

Ahhh, I see your perspective now, that is a significant limitation.

 

In my eyes the objects would be a complement, not a replacement for relational database fields. So there would be a normal database, simply with the occassional stored object (with an object reference to its primary key). I am just thinking that for some information (such as the aforementioned hypothetical calculator session), the complexity would make storing it as an object almost necessary.

[Jenk]

For example in your case you would need a cron script to change the DAYID of the user field.

No, he wouldn't.

 

<?php

$query = "SELECT * FROM `username` WHERE `dayid` = '". date('d', time()) . "' AND `userid` = " . $userid;

?>