Results 1 to 5 of 5
  1. #1
    Join Date
    Aug 2013

    Saving objects into database

    I'm pretty new to the databases and i would like to know which is the best choice for saving object data. let's make an example:

    a recipe application - a simple application where i can write and save my fav recipes and edit them when i need.
    I have model class that rapresent recipe, ingredient.

    recipe class would have attributes like name ( string ), id ( int ) ingredients ( array(int) ), image ( string ), duration ( int ), level ( int )

    ingredient would have attributes like name ( string ), id ( int )

    which would be the best way to save the objects?
    I want to use sqlite instead of plist and core data

    if so, what would be best option for saving objects?
    should i save the objects using an archive? ( im using objective c, that use NSData or NSKeyedArchive system ) or should i just save the primitive data in tables? something like

    table recipe: recipeName(string), recipeID(int primarykey), recipeDuration(int), level(int)
    table ingredient: ingredientName(string), ingredientID(int primaryKey), ingredientImage

    which is the best way???

  2. #2
    Join Date
    Jan 2007
    In database land we don't have arrays. Instead what we would do is create a separate table for our "array" with a "pointer" to its parent.

    In your scenario we have two entities: recipes and ingredients.

    One recipe can have many ingredients.
    One ingredient can be part of many recipes.

    Therefore many recipes can have many ingredients i.e. a many-to-many (M:M) relationship.

    Unfortunately these are more complicated than one-to-many (1:M) relationships.
    Fortunately there's a very standard and simple way to break them down in to two 1:M relationships!

    To do this we create a 3rd, interim table, which for this example I will call recipes_ingredients. This table will consist of only 2 columns which together will make up the primary key of the table. Each column will be a foreign key to the "parent" tables i.e. recipe_id and ingredient_id.

    So our tables would become something like this (note how our first two tables don't change!):

    recipes(recipe_id, name, duration, etc)
    ingredients(ingredients_id, name, image, etc)
    recipes_ingredients(recipe_id, ingredients_id)

    Ok, I know I said only two fields in the recipes_ingredients table but that's not strictly true... Where would you hold "quantity"?

    We can't hold it in "ingredients" because then every recipe would have to have the same quantity of an item (e.g. if we said that eggs had a quantity of 6, then all recipes that used eggs would share this quantity.

    Therefore you can add the quantity to the recipes_ingredients table! That would keep the quantity of the item specific to the recipe and ingredient combination.
    Home | Blog

  3. #3
    Join Date
    Nov 2004
    out on a limb
    I forget, is it PostGRES that styles itself as an object orientated relational db?
    I'd rather be riding on the Tiger 800 or the Norton

  4. #4
    Join Date
    Feb 2004
    In front of the computer
    I typically use a serializer, patterned after Java Beans.

    In theory, theory and practice are identical. In practice, theory and practice are unrelated.

  5. #5
    Join Date
    Jun 2003
    Quote Originally Posted by stabilocode View Post
    a recipe application - a simple application where i can write and save my fav recipes and edit them when i need.
    Not to burst your bubble, but recipe applications are FAR from simple. They are actually very complex data models. You're heading down the rabbit hole if you decide to take on this project.
    If it's not practically useful, then it's practically useless.

    blindman "sqlblindman"

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts