I am building an inventory tracking tool to help people track either unique items (one-offs - say a vintage T-Shirt) or groups of items (a T-shirt design where I have a quantity). The data structures will be very similar, so that:
**Item**
Title
Status (sold, for sale) <- right now this is a simple array
Location <- this is a relationship to a diff model
etc...
**Item Group**
Title
Quantity
Status ([quantity] sold, [quantity] for sale) <- this should be an hstore??
Locations ([quantity] location1, [quantity] location2) <- not sure about this yet!
etc...
I'm expecting to use different forms to gather this information, as too much complexity on the form to accommodate these differences will add difficulty for my user group.
So my questions are as follows:
What is the best data solution for this? Do I want to have two models/controllers or try to extend the Item model? How do people usually handle this sort of issue?
I do have the requirement that I need to show the user all of their inventory (items and groups) at once, but this seems the smaller task to me.
Reduce your headaches and don't differentiate between unique items and non-unique ( ie, all items have a quantity ).
Then you want a "purchace" model, and then a "item_purchace" model to act as a join table.
Following the layout here: guides.rubyonrails.org...
Related
This is complicated and difficult to explain, but here it goes. I have created a db that works just fine. It is a time saver, but not efficient for the user. I have a form for the merchandise where the user selects a paper type from a combobox. They are presented with two choices. They must also select a print size from another combobox. They are presented with 5 choices. I have VBA code that creates a SKU number based on these selections.
An art piece can use both paper types and be available in all 5 sizes. What I am trying to figure out is how I can offer all the possible choices on this form, allow the user to select options for that piece. As an example, the user chooses both paper types and all print sizes. This would create 10 SKU numbers for one art piece. Below is a copy of the form in it's current view:
Is this possible to do from one form? If so, how can this be accomplished in the most efficient way? I feel that it can. In VBA, this would be an IF nest nightmare, especially when concatenating the SKU variables. Either Select statements or another method that I am unaware of, could be the solution.
Thanks in advance for any and all suggestions and assistance.
EDIT: I hope this helps clarify. I would prefer to use this form
to complete the task. The checkboxes are not in an option group so they could all be checked if the user requires it. For the purposes of this question, let's assume the user has checked all the boxes. This would equal 10 total combinations.
I run this sub to generate a SKU based on the paper type and the print size:
Private Function UpdateArtwork()
Me.MerchandiseSKU = Me.cboArtworkID_A5A.Column(5) & _
Me.cboPrintTypeID_A5A.Column(2) & Me.cboPaperTypeID_A5A.Column(0) & _
Format(Me.cboPrintSizeID_A5A.Column(0), "00")
Call UpdateArtworkPic
End Function
I am trying to figure out how to write the code for the new form that allows all 10 SKU numbers to be generated and create 10 new records for Artwork_ID (Artwork table).
I think that the best way of doing this would be to create a new table, called tblArtworkSKU, which has the following fields:
ArtworkSKU_ID - Autonumber, primary key;
Artwork_ID - number, foreign key from the Artwork table;
PrintSize_ID - foreign key from the PrintSize table;
PrintType_ID - foreign key from the PrintType table;
ArtworkSKU - text.
You would then create a small continuous form based on this table, with PrintSize_ID and PrintType_ID selected through combo boxes. When you place this form onto the main form that you have, Access should automatically let you join on Artwork_ID to create a one-to-many relationship.
You could then use the AfterUpdate events of each combo box to create the SKU.
Regards,
Im second guessing how I have modeled my data for a buy/sell app. Each Entity is stored as a node, which contains a list of that entity specified by unique id's.
users -> userId -> [name: "joe", age: 21].
where it gets interesting is the way I store Items. First, I have an items node designed just like the example above. This way I can easily search for any item, or all items. This is handy because I can load all items and add business logic to to display items that can be categorized as Recently Added, Local, Trending etc. These are not nodes in the database.
Now, a user needs access to items they are personally involved with. This kind of item has its own node like so:
selling -> userId -> itemId -> [title: "shoes", size: 11].
Other categories like buying, bought selling, sold liked, archive follow this pattern.
It seems taxing to make changes/searches at so many locations in db when something happens. For instance, if a user wins an item(theres bidding), I have to remove from buying add to bought, add to archive, remove from all items, and for the user who sold the item do the inverse pretty much.
Is it normal to execute this many queries, or should items be more tightly related?
I'm using Firebase by the way. Thanks for your time
Is it normal to execute this many queries, or should items be more tightly related?
Since Firebase doesn't have server-side joins, it is quite common to do joins from the client. This is in itself not always a performance problem, since Firebase pipelines the requests over a single connection.
But it's also quite common to duplicate some of the data to prevent/reduce the number of joins. You'll require a strategy to (or event whether) to keep the duplicated data in sync.
A final alternative is to preload certain data. While that likely doesn't apply here, it can be quite common if the list where you look up from is relatively short, e.g. the list of categories for items.
In my e-commence app (for café/restaurants) I currently have the following database structure.
The cart is the shopping cart, in which you can add products, a temporary place before the products/an order is sent to the server. The ProductCart is a line item, many products (could be the same) with the different quantities, sizes, frying levels etc. When a order is sent, the cart is cleared and the products in the cart is transfered to the ProductOrder entity (an Order).
I now want to extend this further, with the ability of the products having ingredients and this is where it gets tricky and too complex for my head and database skills :-). As well as the (same) products can have different sizes and frying levels (hence the line item) a product should have the ability to have many different ingredients (add ons) for example a pizza, where you could choose the topping. This is what I have tried so far:
But I am not sure if this is the right structure or way to do it?
This is my suggestion.
Remove ProductOrder and Order entities. They are the same as ProductCart and Cart.
Now ProductCart should have an attribute like synchronized that is 1 or 0 based if it has been sent to server or not.
Through this you should simplify a lot your model. About Ingredient… entities they seem ok to me.
There is something fundamental you have not grasped about Core Data. Your ProductOrder entity is essentially a join table. This is completely unnecessary if you are not tracking additional attributes in this table.
Instead, you should have a many-to-many relationship between Order and Product.
It might seem that ProductCart satisfies my condition above that in this case a join table makes sense. But no - you should simply add the orders to your cart and track all the information in the Order entity.
I'm programming a website that allows users to post classified ads with detailed fields for different types of items they are selling. However, I have a question about the best database schema.
The site features many categories (eg. Cars, Computers, Cameras) and each category of ads have their own distinct fields. For example, Cars have attributes such as number of doors, make, model, and horsepower while Computers have attributes such as CPU, RAM, Motherboard Model, etc.
Now since they are all listings, I was thinking of a polymorphic approach, creating a parent LISTINGS table and a different child table for each of the different categories (COMPUTERS, CARS, CAMERAS). Each child table will have a listing_id that will link back to the LISTINGS TABLE. So when a listing is fetched, it would fetch a row from LISTINGS joined by the linked row in the associated child table.
LISTINGS
-listing_id
-user_id
-email_address
-date_created
-description
CARS
-car_id
-listing_id
-make
-model
-num_doors
-horsepower
COMPUTERS
-computer_id
-listing_id
-cpu
-ram
-motherboard_model
Now, is this schema a good design pattern or are there better ways to do this?
I considered single inheritance but quickly brushed off the thought because the table will get too large too quickly, but then another dilemma came to mind - if the user does a global search on all the listings, then that means I will have to query each child table separately. What happens if I have over 100 different categories, wouldn't it be inefficient?
I also thought of another approach where there is a master table (meta table) that defines the fields in each category and a field table that stores the field values of each listing, but would that go against database normalization?
How would sites like Kijiji do it?
Your database design is fine. No reason to change what you've got. I've seen the search done a few ways. One is to have your search stored procedure join all the tables you need to search across and index the columns to be searched. The second way I've seen it done which worked pretty well was to have a table that is only used for search which gets a copy of whatever fields that need to be searched. Then you would put triggers on those fields and update the search table.
They both have drawbacks but I preferred the first to the second.
EDIT
You need the following tables.
Categories
- Id
- Description
CategoriesListingsXref
- CategoryId
- ListingId
With this cross reference model you can join all your listings for a given category during search. Then add a little dynamic sql (because it's easier to understand) and build up your query to include the field(s) you want to search against and call execute on your query.
That's it.
EDIT 2
This seems to be a little bigger discussion that we can fin in these comment boxes. But, anything we would discuss can be understood by reading the following post.
http://www.sommarskog.se/dyn-search-2008.html
It is really complete and shows you more than 1 way of doing it with pro's and cons.
Good luck.
I think the design you have chosen will be good for the scenario you just described. Though I'm not sure if the sub class tables should have their own ID. Since a CAR is a Listing, it makes sense that the values are from the same "domain".
In the typical classified ads site, the data for an ad is written once and then is basically read-only. You can exploit this and store the data in a second set of tables that are more optimized for searching in just the way you want the users to search. Also, the search problem only really exists for a "general" search. Once the user picks a certain type of ad, you can switch to the sub class tables in order to do more advanced search (RAM > 4gb, cpu = overpowered).
I am trying to work out the best way to store my daat using mongodb and mongomapper.
I have category and each category can be described by many attributes so length in mm, weight in kg etc.
I want each user to be able to create their own attributes to descibe a category of products.
So forexample:
user A wants to store his category "cars" with number of wheels and length of car in mm
user B wants to store his category "cars" with number of wheels and length in mm and weight in kg.
The categories are the same for everyone but attributes can be different.
Should i be storing this as category collection then each cateogry contains and array of users each containing a hash of attribute anmes and units ?
Or should i be breaking this up into multiple collections somehow ?
Or is there a better way anyone can think of ?
Is it a problem with deep nesting ?
thanks alot in advancfe for help and advice.
rick
Lets start with the easy answer. Store the attributes as fields in the items document. This is why one uses a schema-less data store.
Now, about which witch attributes to put with which item. Short answer: Any of the ways you describe will work; all have some trade-offs in terms of efficiency.
I think your model goes like this:
There is a collection users
There are many collections of items called categories
each item is a member of a category
each user has many items
every item in a category has many potential attributes depending on the user
some users will share attributes
I would have the following collections: users, *categories(e.g. cars, boats, houses, etc...), attributes.
The attributes collection would list a category(e.g. cars), and attribute of items in that category (e.g. fuel mileage), and a list of user_ids who use that attribute.