When building a core data app, should I design the data structure as a SQL DB or an OO design?
I've read the manual and saw some tutorial, but still, I do not understand this point.
If I use Core Data in my app, lets say I have an object that one of its properties (column in DB) is a type field. In SQL i would do another table开发者_Python百科 with types and do a many-to-one connection between them.
Now, In the tutorials they say that core data is not SQLite and i should regard it as a representation of an OOP objects.
So, should I do it the same why I would in SQL? types table and a field in the object table that is a foreign key for the types table or should I create a parent entity and inherit from it, creating a new entity (class) for each of the types I need?
SQL DB, as we all know, is a representation of a OOP schema, so I don't understand the benefit of doing it the hard way with inheritance. It is much nicer in my eyes to do it with a types entity, if possible...
Am i wrong about this?
Thank you, Erez
In my opinion, these are the hard things. You'll always want to return to database designing. It can be better to use a separate 'table', but you can also use subclasses. Maybe you have an Item
class, that can have different types. Then you can maybe create the subclasses CarItem
, HouseItem
... Each representing a certain type of the Item
class.
精彩评论