This sounds like a system I've been using for about 4 years. I have a abstract class "StoredObject" and then I subclass out my actual classes. StoredObject knows how to post to the DB (which decides if INSERTs or UPDATEs are needed), retrieve (by primary key of the requested object), and search (which takes any known data and retrieves the matching primary keys.
The constructors of the subclasses "register" table(s) and their columns into class variables. As it relates the primary key of each included table and the main primary key for the object it handles 1:1 satellite tables, 1:m, and m:m correspondences. I will admit that the search feature doesn't work for non 1:1 satellite table linkages at present.
sample code at
http://ballroom.mit.edu/compinabox/Publ ... t.inc.phps
http://ballroom.mit.edu/compinabox/Publ ... n.inc.phps
Reading/Writing Classes from/to a database
Moderator: General Moderators
>When you say "array of db tables" what exactly do you mean?
Sorry, my function descriptions are a little terse (intended just for myself at this point really). Each of them describes what the functions returns. So that function returns the list of tables as an array.
As I said, I want to "contain" the mysql resource types within this class, so that other calling classes need merely deal with (more conventional) arrays. So here, for example, I convert the query result resource to an array and just return that.
The resource types that Mysql deals with already, in my opinion, perform the job of encapsulation to a fair extent (especially the connection link id resource), so I don't feel the need (since I'm only dealing with the one db type at this point) to wrap a class around it. I don't have access to PHP 5, so for now I simply return error messages (again, from the link resource) if they arise and if the calling class/scripts requests it (typically after a FALSE return value from one of this class's functions.
>Your object is a connection object and an iterator object and an error >handler all in one.
>This needs some refactoring.
As I've said, if things get hairy enough I WILL separate out the object-handling part. It just works so closely with the db connection that for now I've got it integrated. I don't have a problem with the rest of it. For now, I'm just trying to get this baby off the ground..
You know, to some extent, I guess, I'm going back in my thinking to NeXTStep's "Enterprise Object Framework", which allowed programmers to use objects with databases without having to deal directly with the database itself. (Yes, I have been coding with oops for awhile...). That system now appears (along with Nextstep->OSX) as Apple's Webobjects.
NOT that I am attempting anything QUITE so ambitious or grandiose, MERELY the ability to (as I said in my original post) convert PHP objects into corresponding mysql tables. Is that REALLY such a complicated, abstract concept, (PatrikG)?
I'm not certain why you suggest the "decorator" (that just seems to be another way to sub-class, no?), PatrikG, (although I'm impressed with that patterns website!), but the DAO approach IS much closer to the mark. My naming convention in some of my functions might be confusing: several of them accept both objects OR arrays as arguments. I actually find it easier to parse (etc.) an object's vars by casting it to an array. But, as I say, the SPECIFIC issue I'm dealing with is that of writing/retrieving OBJECTS, which, of course, might themselves CONTAIN arrays. So I need a way to represent ("map") both types to tables (I'm finding arrays trickier than the objects, interestingly enough..).
Now Nielsene is on a similar track to me, I THINK..
But I think (need to study your code some more..maybe STEAL some of it!
) it MIGHT differ (and think I definitely differ from DAO) from the standpoint that I seem to be approaching it "backwards". By that I mean that DAO seems to concern itself with transforming a database into classes/objects by examining the tables (and relationships) and producing corresponding classes of objects. I'm going about this by letting the objects (not the database) drive the design. I can start with an empty database, begin passing it objects, and tables (and relationships, I'm hoping..) will be generated. So really I am letting PHP "drive" things (that should please you, PatrikG). I guess instead of DAO I'm OAD (not to mention ADD...) 
The challenge (or obstacle, possibly) might be generating tables and relationships that make sense for my class AND are useful within the mysql database/engine itself (hence I'm concentrating on db integrity, though it's starting to get a mite baroque).
If this thing works out, perhaps ultimately I could abstract it out enough that it could splice with objects such as, for example, the PEAR:DB class (which IS nice for the way it handles so many db types). I'm also awaiting the release (and my host's adoption of..) PHP5 to help streamline things a bit hopefully.
Thanks all,
Sander
Sorry, my function descriptions are a little terse (intended just for myself at this point really). Each of them describes what the functions returns. So that function returns the list of tables as an array.
As I said, I want to "contain" the mysql resource types within this class, so that other calling classes need merely deal with (more conventional) arrays. So here, for example, I convert the query result resource to an array and just return that.
The resource types that Mysql deals with already, in my opinion, perform the job of encapsulation to a fair extent (especially the connection link id resource), so I don't feel the need (since I'm only dealing with the one db type at this point) to wrap a class around it. I don't have access to PHP 5, so for now I simply return error messages (again, from the link resource) if they arise and if the calling class/scripts requests it (typically after a FALSE return value from one of this class's functions.
>Your object is a connection object and an iterator object and an error >handler all in one.
>This needs some refactoring.
As I've said, if things get hairy enough I WILL separate out the object-handling part. It just works so closely with the db connection that for now I've got it integrated. I don't have a problem with the rest of it. For now, I'm just trying to get this baby off the ground..
You know, to some extent, I guess, I'm going back in my thinking to NeXTStep's "Enterprise Object Framework", which allowed programmers to use objects with databases without having to deal directly with the database itself. (Yes, I have been coding with oops for awhile...). That system now appears (along with Nextstep->OSX) as Apple's Webobjects.
NOT that I am attempting anything QUITE so ambitious or grandiose, MERELY the ability to (as I said in my original post) convert PHP objects into corresponding mysql tables. Is that REALLY such a complicated, abstract concept, (PatrikG)?
I'm not certain why you suggest the "decorator" (that just seems to be another way to sub-class, no?), PatrikG, (although I'm impressed with that patterns website!), but the DAO approach IS much closer to the mark. My naming convention in some of my functions might be confusing: several of them accept both objects OR arrays as arguments. I actually find it easier to parse (etc.) an object's vars by casting it to an array. But, as I say, the SPECIFIC issue I'm dealing with is that of writing/retrieving OBJECTS, which, of course, might themselves CONTAIN arrays. So I need a way to represent ("map") both types to tables (I'm finding arrays trickier than the objects, interestingly enough..).
Now Nielsene is on a similar track to me, I THINK..
But I think (need to study your code some more..maybe STEAL some of it!
The challenge (or obstacle, possibly) might be generating tables and relationships that make sense for my class AND are useful within the mysql database/engine itself (hence I'm concentrating on db integrity, though it's starting to get a mite baroque).
If this thing works out, perhaps ultimately I could abstract it out enough that it could splice with objects such as, for example, the PEAR:DB class (which IS nice for the way it handles so many db types). I'm also awaiting the release (and my host's adoption of..) PHP5 to help streamline things a bit hopefully.
Thanks all,
Sander
I would propose you the following db structure for arrays:
Code: Select all
create table array(
arrayID int unsigned, // id of the array this entry belongs to
type enum('number', 'string', 'array', 'object', .... and so on) // type of the entry
subtype varchar(128), // class of the object
value blob // for objects it would be id of the corresponding entry in object tables, for arrays - id of the contained array
// for scalar values it would be the value itself.
}Yes, THANK YOU, Weirdan!
(Belatedly, but I am plagued by a VERY flaky cable modem/connection here in Mexico..).
Finally, somebody who GETS IT, AND helps to specifically answer my initial question (which, by now, frankly, I've pretty well answered myself...).
It's NEARLY working (I'm just working on this in fits and starts), and it seems that the objects can simply be "fed" into the system with only two requirements:
1. They need to contain an "id" numeric variable.
2. The first time one is entered, all its vars must be "typed" (i.e. cast), even if null, so that the correct db column types can be assigned.
I guess the the class definition files might do this (set all the vars to default--if null--values). I will implement a separate user-called function (REALLY looking forward to PHP's "private" functions) to explicitly do the conversion (in addition to simply doing so the first time such an object is passed), if sent such a "fully specified" object. I'm trying to do all this conversion stuff as transparently as possible, but the need for an "id" field seems unavoidable (I guess its the database equivalent of the memory address pointed to by a "live" variable's name..).
No need for fancy configuration/definition files, although I might implement this as an option for fine-tuning table column types, and possibly for defining more complex data relationships..
Thanks,
Sander
(Belatedly, but I am plagued by a VERY flaky cable modem/connection here in Mexico..).
Finally, somebody who GETS IT, AND helps to specifically answer my initial question (which, by now, frankly, I've pretty well answered myself...).
It's NEARLY working (I'm just working on this in fits and starts), and it seems that the objects can simply be "fed" into the system with only two requirements:
1. They need to contain an "id" numeric variable.
2. The first time one is entered, all its vars must be "typed" (i.e. cast), even if null, so that the correct db column types can be assigned.
I guess the the class definition files might do this (set all the vars to default--if null--values). I will implement a separate user-called function (REALLY looking forward to PHP's "private" functions) to explicitly do the conversion (in addition to simply doing so the first time such an object is passed), if sent such a "fully specified" object. I'm trying to do all this conversion stuff as transparently as possible, but the need for an "id" field seems unavoidable (I guess its the database equivalent of the memory address pointed to by a "live" variable's name..).
No need for fancy configuration/definition files, although I might implement this as an option for fine-tuning table column types, and possibly for defining more complex data relationships..
Thanks,
Sander
This is the clearest description of what it is that I've yet seen, but it can be translated as looking at the Object as a hierchal structure and mapping that to a database.xandor wrote: NOT that I am attempting anything QUITE so ambitious or grandiose, MERELY the ability to (as I said in my original post) convert PHP objects into corresponding mysql tables. Is that REALLY such a complicated, abstract concept, (PatrikG)?
In short, I don't feel it's worth the effort with the approach you are taking. There are allready ODBMS's and ORDBMS's that do just this. A relational database is not designed to model data in this way. It can be done, but the overhead is astronomical and the performance is terrible. A number of people (my last employer included) have tried to build applications with this idea, but how close they come to success first has something to do with how much knowledge of the topic they have starting off.
I was looking into a number of different ERP packages for my last employer (before I got smart and escaped from that nightmare!) and found that many of those companies are using just this approach. That of looking at and dealing with data in a heirchal fashion as oppossed to a relational one. Allmost all of them have some funkmaster scheme of storing and munging data in memory because it's too slow othewise. And they were using object databases!
Now I'm not saying you're stupid or ignorant, but I'd stop right now and start doing some research on the topid of ODBMS/ORDBMS's. I'd also look into data structures like trees. An object and it's data could easily be looked at / realized as a tree. It's this same idea that object database work on.
Going further, a multi-dim array can model a tree and one can traverse that array and all it's nodes using a recursive function.
Also do some reading on 'impedance mismatch' and OR mapping. And lastly, read some stuff by Fabian Pascal.
Just for the record, I think the relational model is just fine. While it may make it difficult to abstract away as much as we like, I don't see it going away until the O(R)DBMS vendors figure out something that works a lot faster than what they presently have.
Cheers,
BDKR
The "clearest description of what it is that I've seen" is, as I said, what I originally described in the beginning of this thread (if by "it" you mean the problem with which I am grappling)!
Actually, I don't really know a hell of a lot about object-oriented databases, apart from the fact that they seem to have been a bit of a fad a few years ago and have since faded out. "Conventional" relational databases seem to have established themselves as a standard for the forseeable future, and I have no problem with that, since, as I've also said, I am comfortable (within my own limitations) with that approach. At the same time, obviously, in the programming world, by now OOPS has established itself as the au courant de facto programming standard, and, since I "like" both, I am attempting to integrate both of them. And no, I am cetainly not attempting anything as ambitous as an "ERP" package either. Don't you see that the whole (well, part of the idea) of this is to NOT have to have all the data "IN MEMORY"--that's where the power of the rdms excels! I need only "instantiate" the needed objects as required!
I don't know that it's necessary to resort to an arguably now-obscure database model such as ODBMS/ORDBMS's just because I want to figure out a way to store objects into the now-ubiquitous relational databases! In other words, I agree with you that that "the relational model is just fine"! At the same time I believe that the object oriented programming method is just fine (don't you?)! Do you think it's impossible to have BOTH?
Well, perhaps it is, and perhaps I'm in the process of discovering the proof of that! Unfortunately, I'm not yet convinced, fool that I yet may be! My God, is this some kind of a quest for a holy grail for which I have embarked? And here I thought I was treading down a well-worn path!
I HAVE done some reading on mapping (and "impedance mismatch"). I think you are quite correct that representing objects (particularly those containing arrays and objects) translates to a hierarchical structure. I'm not convinced that hierarchical structures cannot be modeled ("mapped") in the relational model (one->many: mightn't that be taken as hierarchical?). Acually, I was under the impression that ISAM, etc. ALREADY made use of such structures. Whether they are at a "deeper" level (e.g. for indexes, etc. )that is of no to my particular needs might be germane, admittedly.
I've "looked into" trees for god's sakes--years ago, yes I went to skool-- and might have to "arbitrarily" limit the depths of nodes just for sanity's (if I can remember what THAT is!) sake. OK, so maybe you WON'T be able to have classes that have arrays of objects containing arrays of arrays of objects.... I just might require arbitrary limits..
But, hey, the proof is certainly in the pudding! I may yet just fall down flat on my face! Then you can have your (deserved, presumably) laughs. If I achieve a modicum of success, however, I shall gladly share it with this forum.
Enough "discussing", back to coding...in the morning...
Regards,
Sander
Actually, I don't really know a hell of a lot about object-oriented databases, apart from the fact that they seem to have been a bit of a fad a few years ago and have since faded out. "Conventional" relational databases seem to have established themselves as a standard for the forseeable future, and I have no problem with that, since, as I've also said, I am comfortable (within my own limitations) with that approach. At the same time, obviously, in the programming world, by now OOPS has established itself as the au courant de facto programming standard, and, since I "like" both, I am attempting to integrate both of them. And no, I am cetainly not attempting anything as ambitous as an "ERP" package either. Don't you see that the whole (well, part of the idea) of this is to NOT have to have all the data "IN MEMORY"--that's where the power of the rdms excels! I need only "instantiate" the needed objects as required!
I don't know that it's necessary to resort to an arguably now-obscure database model such as ODBMS/ORDBMS's just because I want to figure out a way to store objects into the now-ubiquitous relational databases! In other words, I agree with you that that "the relational model is just fine"! At the same time I believe that the object oriented programming method is just fine (don't you?)! Do you think it's impossible to have BOTH?
Well, perhaps it is, and perhaps I'm in the process of discovering the proof of that! Unfortunately, I'm not yet convinced, fool that I yet may be! My God, is this some kind of a quest for a holy grail for which I have embarked? And here I thought I was treading down a well-worn path!
I HAVE done some reading on mapping (and "impedance mismatch"). I think you are quite correct that representing objects (particularly those containing arrays and objects) translates to a hierarchical structure. I'm not convinced that hierarchical structures cannot be modeled ("mapped") in the relational model (one->many: mightn't that be taken as hierarchical?). Acually, I was under the impression that ISAM, etc. ALREADY made use of such structures. Whether they are at a "deeper" level (e.g. for indexes, etc. )that is of no to my particular needs might be germane, admittedly.
I've "looked into" trees for god's sakes--years ago, yes I went to skool-- and might have to "arbitrarily" limit the depths of nodes just for sanity's (if I can remember what THAT is!) sake. OK, so maybe you WON'T be able to have classes that have arrays of objects containing arrays of arrays of objects.... I just might require arbitrary limits..
But, hey, the proof is certainly in the pudding! I may yet just fall down flat on my face! Then you can have your (deserved, presumably) laughs. If I achieve a modicum of success, however, I shall gladly share it with this forum.
Enough "discussing", back to coding...in the morning...
Regards,
Sander
Well said! And sorry if I stepped on your toes.
Anyway, just to clear up a little thing here or there.
But how does someone come up with an effecient scheme here without sacrificing integrity? Remeber what you asked in the first post?
When we encountered these problems, my suggestion as a possible solution was to have a different process that would take snapshots of the data in the database and generate hierchal structures (snapshots if you will) that were either stored in memory or serialized to a table. As opposed to what the system was doing, which was going through the elaborate process of constructing that data for each request. That process could either run at a regular interval, or when some data somewhere in the system had been changed.
But I think that this is exactly what some of the other caching schemes are doing too?
Anyways, IMHO you are on a well worn path. However, I don't know you as a person or thinker in gerneral so there is no reason to doubt that you may find a better way.
Cheers,
BDKR
Anyway, just to clear up a little thing here or there.
Actually, I do believe you can do it. But the approach you take here is prolly the most crucial part of the design. I think a lot of people get into trouble right here but don't realize how borked (perhaps I should just say ineffecient?) the approach is until some time deeper into the development process. Normally about the time it hurts the most.I'm not convinced that hierarchical structures cannot be modeled ("mapped") in the relational model (one->many: mightn't that be taken as hierarchical?).
Well of course I understand this and agree with you completely. The whole idea going into these 'in memory' caching schemes was to overcome the performance defecit at the database level, whether it be Object hiearchies mapped into a relation db (which REALLY needs it) or an object DB.Don't you see that the whole (well, part of the idea) of this is to NOT have to have all the data "IN MEMORY"--that's where the power of the rdms excels! I need only "instantiate" the needed objects as required!
Not really. I just don't believe it's that efficient. However, if you come up with an effecient scheme, and considering the fact that processors are going to continue to get faster and faster for some time, then I an easily see this approach finding more use into the future.Do you think it's impossible to have BOTH?
But how does someone come up with an effecient scheme here without sacrificing integrity? Remeber what you asked in the first post?
This is the part that is responsible for the bulk of the overhead correct? Running back and forth to this table containing foreign keys is where I think the bulk of the systems time will be. And as you pointed out, without this exercise, you are compromising integrity.This is more-or-less working, but I am toying with how to best implement the situation(s) described above without compromising rdbms integrity and without resorting to too much kludginess. At this point I'm thinking I could just have a separate table for arrays containing foreign keys from the object (or array) and its variable containing them..
When we encountered these problems, my suggestion as a possible solution was to have a different process that would take snapshots of the data in the database and generate hierchal structures (snapshots if you will) that were either stored in memory or serialized to a table. As opposed to what the system was doing, which was going through the elaborate process of constructing that data for each request. That process could either run at a regular interval, or when some data somewhere in the system had been changed.
But I think that this is exactly what some of the other caching schemes are doing too?
Anyways, IMHO you are on a well worn path. However, I don't know you as a person or thinker in gerneral so there is no reason to doubt that you may find a better way.
Cheers,
BDKR