Jump to content


  • Posts

  • Joined

  • Last visited


Profile Information

  • Gender
    Not Telling

Attilitus's Achievements


Newbie (1/5)



  1. 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.
  2. Also be aware of PHP timeouts which are normally set around 30 seconds.
  3. 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.
  4. 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.
  5. 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.
  6. 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?
  7. 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.
  8. There is a kind of mystique in being able to take a unique "case" dynamically manipulate parameters, and then "SET" it. You can throw everything you want into a properly coded class, check the information while it is still magically suspended in the object, and then finally send off the data to the nearest database. It is a cool concept... but it is also something that is basically useless abstraction. There is a significant performance difference when using objects... it is just a fact of life especially with PHP4. (Lets face it, in a language like PHP that is relatively robust and fast, objects just don't stand as tall as the language's array components). However, I still find myself using OOP practices in just about all my coding. I find that it takes about the same amount of time to get everything "written" and I can better debug the technical aspects of my code by having a self contained class who's separate components can be individually "checked" and "ran" separately. Ultimately, however, alot of this stuff is never going to be used again, and it is hardly "too complicated" to code procedurally. Are any others out there like me, and enjoy using OOP simply because of the way it allows you to "think through your code" and even more imporantly, easily debug the individual components of your script? I hear extensibility, maintainability... but really I just use OOP because I like it better and it is easier for me to write. Any thoughts?
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.