I'm officially working with spaghetti code right now, and it's all because of the referencing forms, and I'm thinking of stopping that before it gets all too entangled.
I generally dislike discussing code particulars on this blog, but I won't stop myself this time. Currently, I have a working ForeignKeyField, that is actually committed to the repository. The good thing is that accessing it with PHP makes the Model 'on the other side' completely transparent. Hugely simplified, doing "$myModel->foreignKey->foreignTableName" would do what your intuition says it should do. The bad thing is, until you evaluate $myModel->foreignKey, there's no way of accessing foreignTableName. The upshot of this all is that you can't select a $myModel based on the values in the foreign table. You can't select a person (or a collection of persons) based on the color of her(/their) car(s), if Person and Car are two separate models, with a foreign key between them.
So, let's, just for a moment, assume that this is not a big deal. Sure, it's not all that common to select persons based on car colors. Let's assume that it's completely reasonable to look through each and every person and respective car's color. The complexity is still O(n). While respectable, noticeably worse than O(1) that we would get if we could 'look through the foreign key'.
The deal gets quite a lot bigger when many-to-many relations come to play. Pizzas have many toppings, and toppings are on several different pizzas. So you have Pizza, you have Topping and you have a table joining the two, saying which topping is on which pizza. Doing, Big-O is through the roof, and we have a O(n2) on our hands, if we can't see through foreign keys. We are forced to do $pizza->foreignKey->foreignKey->toppingName.
The problem, however, isn't here. $a->fk->b is simple enough to fix with a join, and it's very easy to expand it to how many intermediate foreign keys as the user wants. I've actually done that already. One model can already be selected with the help of a foreign table's values. The problem is how the SQL requests are returned. As I'm currently only working on MySQL, it might be a problem only with that (and even if it's only MySQL with this behavior, I need to do additional RDBMS-unification code). But, I get no indication which result is from which table. This makes populating the result values in the correct models and their respectively correct fields. If I have a "name" column in the result, but three models, how am I supposed to know where to put it?
Anyhow. That's what I've been up to. How about yourself? Nice weather, I've heard.
*psst* helping hands are still welcome
Tuesday, March 11, 2008
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment