I am creating an application that lists local businesses and groups them by category, subcategory and keyword. Here are the rules for how businesses are sorted:
A business can belong to multiple categories and subcategories
A business can have multiple keywords
Not every category has subcategories, but those that do are only two levels deep (category -> subcategory)
A subcategory can belong to multiple categories
Also worth mentioning is that the client has given me the list of businesses in an excel document which is laid out as such:
Each category is a separate tab, or page
Each page contains the list of businesses, their addresses, keywords and subcategories
The business' subcategories are designated by an 'X' in a column with the subcategory's name
I have been attempting to solve this through pivot tables, but this has lead me to quite a few pivots (category_subcategory, business_keyword, business_category) and I’m afraid that this will have a substantial impact on performance do to the volume of queries that would be made to determine which businesses to show based on a filter.
I think I am on the right track, but I feel that there is a more optimal way to approach this.
If I read all that correctly, these are the tables I think you should make:
businesses
id, name, etc.
keywords
id, word, etc.
categories
id, name, etc.
subcategories
id, name, etc.
categories_subcategories
id, category_id, subcategory_id
businesses_categories
id, business_id, category_id
businesses_subcategories
id, business_id, subcategory_id
businesses_keywords
id, business_id, keyword_id
Proper way would be to have something like this:
1.Business(id (*PK), name,...)
2.Keyword(id (*PK), keyword,...)
3.Category(id(*PK), name, parent_category (*FK),...)
4.Bis_cat(bis_id (*FK), cat_id (*FK),...)
5.Bis_key(bis_id (*FK), keyword_id(*FK),...)
Where (*PK) are primary keys, and (*FK) a foreign keys.
In this model you would have unlimited subcategories, using recursion. You can also add referential integrities if you want to be 100% sure that you want have any errors but it's a very tight restriction on a db, so if you know how to do it put it in.
Related
How do I create a database which contains many different products of various categories?
They also have different attributes.
My idea is to create 3 tables:
Product (pid)
Category (cid, parentcategory)
Product_category (pid, cid)
I think this manages the categories, but how do i store the attributes efficiently?
If your products will not be in two or more categories, you don't need conenction table.
According to the comment section, I have a suggestion for you:
If and only if you decide to store category and sub_category then you have to implement it like this:
category(id, name)
sub_category(id, name, category_id)
product(id, name, sub_category_id)
With this method every products are aware of what is their subcategory. If we have the subcategory, then we are also able to determine the (main) category of every product.
I hope I could help you. Designing the scheme of the database is a very important step of developing an application.
I'm creating a system that has Groups. These can be thought of like Facebook Groups. Users can create new groups. Currently I have the following types of groups:
City Group - Groups based on a certain city. For example "London Buy and Sell Group"
School Group - Groups based on schools. For example "London University Study Group"
Interest Group - Groups that are not tied to a place. For example "Over 50's Knitting Group"
In the future more group types will be added. Each group can have different types of options, but all groups have the same basic data:
An ID
A creator ID
A name
An option description
I'm struggling on putting together a database design for this. My initial thought was to create different tables for the different groups.
For example have a single table called group. This table has an id, creator id, name, description, member count, timestamps.
Then have other tables to represent the other groups, and link them to group. So I have a city_group table that contains and id, group_id, city_id. And the same for the other group types.
The only problem I have with this is interest_group doesn't have any extra data that a normal group. But for the purpose of being able to query only Interest Groups I thought it might make sense to create an interest_group table. It would only have the following columns: id, group_id, timestamps ... which seems a bit wasteful to have a table just for this purpose.
Here's a diagram to make things easier:
Are there any issues with my solution, or any better ways to solve this design problem?
I've got an idea, which is a workaround basically: have another table like: group_type in which you have id(the PK) and then you have tablename (the full table name of the type).
Then, you should have a FK from your Group table linking to this group_type table.
id tablename
--------------------
1 School Group
2 Interest Group
After all this is done, you could build your queries based on the values from this table, as an example:
JOIN (SELECT tablename FROM group_type WHERE id=group.group_type_id) ON ..
I know there has been a few answer to a couple of questions similar to the one am asking. But their approach didn't look convincing.
My question is how would I structure a database for a category that can have books and a subcategory which can also have books?
I have already design a database, but am not convinced by the approach. So I would really appreciate if the guys with experience gave me some advice or improvement or a completely different approach.
This how my tables look like (bare in mind this is not the actual code)
TABLE Category
ID
user_id -- Foreign key from user
name
TABLE SubCategory
ID
user_id
category_id
name
The table for the book have the same design.
There's no reason to have more than one table for "categories", whether it be a top-level category or a sub-category. They're all just "categories".
So, have a single table called "categories", with a parent_id field:
// categories table
id
name
user_id
parent_id
When you want to pull all top level categories, just run your query against the categories table with a condition that parent_id is null.
Then, when you want to pull sub categories, just run the query against the categories table with a condition that parent_id = 123 (or whatever).
Not only does this keep everything a lot cleaner, but it also allows for expansion in case you want to continue adding sub-sub-sub-sub categories...etc.
Another option is to use CakePHP's TreeBehavior.
I personally just rather use the way I suggested above, but might just be because I haven't taken the time to really understand this behavior enough.
If parent_category is null then it is a top level. If it is non-null then it is a sub category.
TABLE Category
ID
name
parent_category
I understand - and have created - a self-referencing table that contains Categories & Subcategories. SO, you get a table that looks like this:
Categories Table:
id, primary Key autoNumber
category, text
parentID, foreign Key, number
categories.ID has a one-to-many relationship with categories.parentID
==Here is what I'm having a really tough time understanding==
I also have a Transactions table used to track a purchase, and two columns to record the Category and its Subcategory. Think "Automobile: Gasoline", or "Healthcare: Prescriptions".
Transactions Table:
id, primaryKey, autoNumber
payee, shortText
Category, foreign key, (number, comboBox)
Subcategory (number, comboBox)
categories.ID has a one-to-many relationship with Transactions.Category
I can't find the appropriate way to populate Category and Subcategory in the Transactions table.
So far, I was able to pull all distinct categories from the Categories Table with a SQL statement similar to the example below. (Any Category with a NULL parentID is considered a root category).
SELECT *
FROM Categories
WHERE (((Categories.[parentID]) Is Null))
ORDER BY Categories.category DESC;
My problem is finding a way to get Transactions.Subcategory to list only the subcategories associated with the chosen root category.
I don't know how to do this in Access.
Any tips, advice, etc., would be very much appreciated.
I want to store a list of book IDs for a wishlist in mysql; here's what the relevant tables look like:
User_Wishlists
user_id, list_title, list_id (PK)
Wishlist
list_id (FK), book_id (PK)
The issue is with the book_ID. Most users will have multiple books on their lists, but it seems strange to have that represented by book1_id, book2_id, etc. in the table. Is there a better way to store a list of these book_IDs in mysql? I need to be able to retrieve and display a user's wishlist for them.
You need to have an association table that joins users to wishlists. Remember the zero, one, or N principle of database design. Either you have no relationship, a one to one, or a one to many. Using things like book1_id is almost always a defective design.
You may find this is a better structure:
Wishlist
wishlist_id, user_id, ...
WishlistEntry
wishlist_id, book_id, ...
Associate the wishlist with the user directly, then use the WishlistEnry table to find which books are on which wishlist.