On 2009/10/25, at 00:38, Tavis McDevitt wrote:
I've a question though. In your EoModelerBasics show, you made a to-one relationship from a Person entity to a Cadency entity (a title, like Jr or Sr). I get it. You also made the inverse to-many relationship from Cadency to Person. I don't get that. If I assume that I will never traverse an inverse relationship (I will never want to know what people have a Jr in their signature), do I have to model the inverse relationship? I've been skipping that.
Both your questions end up answering each other in a way. :)
One-to-many relationships exist in both ways. Say, an account has many emails, and an email belongs to an account. So, conceptually, it makes sense to model both. This way, EOF will be smart enough to handle both sides of the relationship, and will avoid things like going to the database to see to what account a given email belongs to if the account object is already in memory. Otherwise, a fetch spec would have to be used, as EOF had no way of knowing.
So, you should always model both sides of the relationship. Unless... to many really means to many, in the sense that one object is related to many (thousands) of other objects. In that situation, and due to some current EOF limitations, you might have serious performance penalties if you model the one-to-many side of the relationship. A good example is the situation where you create a new email and addObjectToBothSidesOfRelationship with the account. By doing this, EOF will fetch ALL the objects of the relationship to memory, to check if the object you're adding is not already there. That takes time and memory. So, you should not model that side for performance reasons if you expect a relationship to have a lot of objects. Otherwise, both sides should be modeled.
One more question while I'm at it. What's the best way to model a linked list? I've thought of putting list items in a table with an inbred relationship that links to other list items. My concern is that to retrieve the list at once I'd have to have many trips to the database, because in a single fault I will only know the root item in the list, and after each succesive fetch will only have a reference to one more item. I don't know much about stored procedures; can one be written to fetch the entire list?
Despite EOF being a really nice ORM, don't forget that, in the end, your data is stored in a relational database, so your modeling depends on that. A linked list is, in practice, a relationship. In my example, you would model a list of the emails in an account simply by creating a normal one-to-many relationship from account to email. If you need to establish some kind of order, simply use an integer, a timestamp or something that can easily be sorted. As you said, applying the linked list model to a relational DB will result in disaster.
I find it very rare to have the need of some pre-built order. Usually, you sort stuff depending on what you want to do on the fly (imagine a table where the user may order the rows using any of the columns as the sorting criteria, so you would create and apply a NSSortOrdering to your fetch spec). But if you really need to, add an integer or timestamp and the necessary constraints to the database to avoid repeating the same number.
Yours
Miguel Arroz