Places and their PlaceCategories

Question

I'm going to start small here because I actually have several questions but I'll go one at a time.

In the app I am making to better learn Java/Android/SQL/OOP, I have a page where a user can define Places (e.g. "New York City", "Seattle", etc). You could add made-up stuff if you wanted, too, doesn't matter. The user can perform basic CRUD operations on these Places.

Each Place also has a PlaceCategory, which is also user-defined elsewhere in the app in a separate list. So maybe I associate NYC and Boston with "The Northeast" and so if I click the filter dropdown and select "The Northeast," then NYC and Boston remain and the rest disappear (until I remove the filter again).

This is my SQL for the PlaceCategory table:

private static final String STRING_CREATE_TABLE_PLACE_CATEGORIES =
        "CREATE TABLE PLACE_CATEGORIES ("
                + "ID INTEGER PRIMARY KEY AUTOINCREMENT, "
                + "CATEGORY_NAME TEXT UNIQUE NOT NULL)";

And for the object:

public class PlaceCategory implements Comparable<PlaceCategory> {
    private long mId;
    private String mName;

    public PlaceCategory() {
        mId = -1;
        mName = "";
    }

    public PlaceCategory(long id, String name) {
        mId = id;
        mName = name;
    }

    public long getId() {
        return mId;
    }

    public void setId(long id) {
        mId = id;
    }

    public String getName() {
        return mName;
    }

    public void setName(String name) {
        mName = name;
    }

    @Override
    public int compareTo(PlaceCategory another) {
        return mName.compareTo(another.getName());
    }
}

And now for Places:

private static final String STRING_CREATE_TABLE_PLACES =
        "CREATE TABLE PLACES ("
                + "ID INTEGER PRIMARY KEY AUTOINCREMENT, "
                + "PLACE_CATEGORY_ID INTEGER NOT NULL, "
                + "PLACE_NAME TEXT NOT NULL, "
                + "PLACE_DESC TEXT NOT NULL, "
                + "FOREIGN KEY("
                    + "PLACE_CATEGORY_ID) REFERENCES "
                    + "PLACE_CATEGORIES(ID) ON DELETE CASCADE, "
                + "UNIQUE("
                    + "PLACE_CATEGORY_ID,"
                    + "PLACE_NAME))";

And the object:

public class Place implements Comparable<Place>{
    private long mId;
    private long mCategoryId;
    private String mName;
    private String mDesc;

    public Place() {
        mId = -1;
        mCategoryId = -1;
        mName = "";
        mDesc = "";
    }

    public Place(long id, long categoryId, String name, String desc) {
        mId = id;
        mCategoryId = categoryId;
        mName = name;
        mDesc = desc;
    }

    public long getId() {
        return mId;
    }

    public void setId(long id) {
        mId = id;
    }

    public long getCategoryId() {
        return mCategoryId;
    }

    public void setCategoryId(long categoryId) {
        mCategoryId = categoryId;
    }

    public String getName() {
        return mName;
    }

    public void setName(String name) {
        mName = name;
    }

    public String getDesc() {
        return mDesc;
    }

    public void setDesc(String desc) {
        mDesc = desc;
    }

    @Override
    public int compareTo(Place another) {
        return mName.compareTo(another.getName());
    }
}

My questions:

1. Should I be using long or Long for the ids in general? I used long because I don't think I need the null-ability of Long but I am unsure what the accepted practice is here.

2. Should I be storing the Category as an object in the Place, as opposed to an id like I am currently doing? My concern with storing only the id is that I would have to query the database for the category details whenever I wanted more detail. I don't know if this is considered a good idea. On the other hand, it is easier to query/generate Places when their members are primitive datatypes that can be ripped straight out of the table.

3. Are the ways my tables set up normalized properly? Do they make sense?

4. Anything else that stands out?

Answer 1

#3 Normalization

What will you do if a place belongs to more than one category? For example, I might categorize Boston as New England as well as The Northeast. But you only have one place category ID per place.

If the category is always a region, you might call the table Regions instead. That's more specific than category or even place category.

I would expect something called place categories to know to what place it belonged. But in this case, one place category has many places. This is part of why I don't like the name. It feels wrong to me.

#2 Object vs. ID

Hibernate is an Object-relational Mapping tool (ORM). It always includes related tables as objects, but it doesn't necessarily bother loading them unless needed. I.e. it has a lazy loading option. It's application specific which way you do it. If you normally need it, perhaps load it aggressively. If you normally don't need it, perhaps you only load it lazily.

Note that place categories are rather light weight. It would be easy enough to load all of them and assign them as you load places. That's a good pattern if you have to load all the categories in order to make your drop down.