I am just started learn Web Application Programming and will appreciate any help.
I am using MVC 4 and the problem I trying to solve is:
I want to calculate total energy spent in daily activities.
I have 20 different categories of activities. Each of these categories has subcategories mapped into DB table.
I want repeatedly to select categories in the view. For selected category get data from table and select any number of subcategories and show them in the main view.
I solved this in a way which probably the worst (according to performance). I will appreciate any help.
Here is my approach:
I select a category in the View_1 and pass it into the View_2. I make selections in View_2 and submit them to controller C_2 , where selected items are accumulated in the TempData. I put all accumulated items at the final stage into a Model.
Related
I would like to create a simple app in Xcode with two UIPickerViews that reference a data set where the second UIPickerView is dependent on the first one. I want to create an app where the user can select the manufacturer of a vehicle; Chevrolet, Dodge, Ford, etc. Then, the user can select the vehicle based on the first choice. For example if "Ford" was selected in the first UIPickerView, then only Ford vehicles show up in the second - F150, Focus, Mustang etc. After selecting both values, the user can search for the average price where the prices are kept in a data set. I found many examples with one UIPickerView referencing arrays, but I want to reference a much larger data set. How would I go about doing this? I am fairly new to Xcode, but I write SAS and SQL code daily.
I am assuming you have all of records saved in the database. I did something similar with 250k+ records.
Do not fetch all of your models' full representation into memory, fetch only one property (string column needed for current picker) with a DISTINCT on it - both SQLite & CoreData allow this.
Your subsequent pickers (2nd, 3rd & so on) will automatically see less data becuase of the previous filter applied (only Ford vehicles possible options).
Rule #1 applies to all of your pickers, only the relevant field as String pulled into memory with right filters.
I had no issues at all with above approach with my dataset. Not sure how big your dataset is.
Okay so I'm making a app for fun to get a hang of things. This app is supposed to allow a user to input the number of times he or she has been paid from a client and which account/card number he or she used for the payment. The way I have this set up in CoreData is I have an entity for Client which contains:
details
name
entryId
sectionId
numberOfPayments
details is another cell type that I lets out in the picture that allows the user to input details about the client. I also have an entity for Payments that acts as a many to one relationship to Client that holds the amount and account number given that there can be many.
What I have trouble with is accessing the tableview to save all the data when the done button is hit. I was thinking about a nested for loop that would go through each section and for each row it will save the data accordingly like for Rob through an if statement it will know the first row is a part of the Client entity and every row after would be apart of the Payments entity as relationships. How would I access these individual cells? Is it possible to have this much flexibility with TableView or should I take a different approach.
I'm building a Rails application with a dashboard composed of a sorted collection of cells. The ultimate goal is to allow the user to arrange the cells and have that persisted to the database, but I'm unable to fathom the architecture required to make this happen.
I'm less concerned about the UI/UX of dragging and dropping cells, and more concerned about the models required to represent this in a SQL database with ActiveRecord.
Any help would be appreciated. Thanks!
This is a pretty solved problem, there are numerous gems that will handle this for you.
Typically you'd add a "position" integer column to the table, and sort by that when you select records. When you want to move an item A to a new position after item B, you first add 1 the position of all records that are sorted after B to make a new space for A, and then to set A's position to B.position + 1. This way, sorting involves only two writes.
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...
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).